Precision of Matching Concept on Red Flags

The concept of identifying red flags seems relatively simple until the fraud auditor factors into the equation the following types of matches:

• Exact match. The two data elements are an exact match. An easy example is invoice date. Two invoices from the same vendor are dated July 24. From an address field, two or more vendors have the same street address; city, state, and postal code are an exact match.
• Close match. The data elements are in close proximity to another transaction. Two invoices from the same vendor are within three days of each other. From an address field, two or more vendors have the same city, state, and postal code, but different street address in the street field.
• Related match. The data elements are within close proximity but exceed the close match test. From an address test we would focus on postal code or all postal codes within a geographic radius.

As a guideline, the fraud data analytics should start with exact match followed by close match. The related match tends to be used for high sophistication of concealment or a specific allegation of fraud. The allegation allows the data analytics to reduce the population of entities and transactions, which allows data interpretation strategies to be more effective.

Specific Identification of a Data Element or an Internal Control Anomaly

The design of the test is exactly as it sounds; it focuses on identifying a specific data pattern. The process starts with a fraud scenario and then specific data pattern that is associated with the fraud scenario. The following fraud scenario illustrates the concept:

• A real supplier overbills the company by intentionally overcharging within the payment tolerances for matching a purchase order to an invoice in the accounts payable system, resulting in the loss of company funds.

The specific identification is all supplier invoices that exceed the original purchase order amount within the tolerance levels. The frequency analysis would highlight those suppliers committing the fraud scenario with a higher frequency versus a pattern that occurs with a low frequency.

The following types of data interrogation tests are usually associated with the specific identification strategy:

1. The specific identification strategy focuses on the following types of tests for entity data:
   1. Match: searches two different databases for the same data element. The matching concept is also used in the internal control avoidance.
   2. Duplicate: searches within one database for the same data element in two different entities. The data analytics should use data elements that are more difficult to conceal or would cost the perpetrator money—i.e., telephone number or email address.
   3. Missing: searches for a data element that should exist in the data file. With missing searches it is the totality of the missing information versus a missing data element.
   4. Changed: searches for a change to a data field through examination of the change file or comparing two database files at the beginning and end of the scope period.
   5. A specific anomaly in a specific data field.
   6. Address and bank accounts tend to be critical data fields because the transfer of funds requires an electronic transfer or the mailing of funds. If both data fields are blank, this is an example of a specific data anomaly.
2. The specific identification strategy focuses on the following types of tests for transactional data:
   1. The identification process starts with a specific fraud scenario.
   2. A specific pattern in the data—i.e., a sequential pattern of vendor invoice numbers.
   3. A group of transactions that can be identified based on a specific data criterion—i.e., excessive overtime or invoices applied to a dormant purchase order.
   4. Missing: invoices with no purchase order.
   5. Change analysis should focus on a transaction being changed, deleted, or voided—i.e., an employee's time report changed by a supervisor or payroll supervisor.
   6. Duplicate transactions. Supplier invoices with a duplicate invoice number or two invoices with the same date and amount.
   7. Manual transactions. These are transactions that are not created through the automated systems and are instead recorded through a manual process.
   8. Data anomaly in a specific data field that correlates to a fraud scenario or a concealment strategy.
   9. Data anomaly associated with your company's normal business practices—i.e., speed of payment is searching for a vendor that is paid faster than normal company payment terms.
3. Specific identification tends to be more effective by starting with a cluster pattern and then using specific attributes to refine the selection process. The use of multiple criteria reduces the number of false positives.

Illustrative Examples of Specific Identification Strategy:

1. Employee that is missing a user ID for access to the building.
2. Employee that is missing emergency contact information.
3. Employee with a change to bank account near termination date.
4. Two employees with different last name, same bank account for direct deposit.
5. Employee's name matches a contract employee name in the vendor file.
6. Employee claiming exemption from income taxes and the gross wages would indicate the employee could have a tax liability if there is no tax withholding.
7. All employees with no voluntary withholding for fringe benefits, such as 401(k) plan and health insurance.

Guidelines for Use of Specific Identification Strategy:

1. The specific identification is used when the concealment of the fraud scenario is at a low level.
2. The focus of the strategy for entity information is to locate false entity scenarios.
3. The focus of the strategy for transactional information is to identify specific data pattern associated with a fraud scenario.
4. To illustrate, I would use the specific identification strategy to identify open purchase orders with multiple invoices, or I would identify all invoices that are greater than the original purchase order.
5. Obviously, a vendor invoice being greater than the purchase order is not a reason to call in the investigators. However, history has also taught us that override or change orders are associated with fraud scenarios.
6. Do not have a myopic view of the test words. Missing can be used in many different ways for testing purposes. Missing could mean internal controls require the data element to be populated or may simply mean that the data field is blank.
7. The goal of the test is to identify a specific entity or a set of transactions that link to a specific entity that meets the specific identification criteria.

Consider the Following Scenario

Budget owner causes an employee who terminates employment (employee stops going to work) not to be removed from the payroll system, and the budget owner submits time and attendance records in the name of the terminated employee for a temporary period of time, causing the diversion of funds.

Since the statement indicates the scenario is temporary, we can identify all terminated employees as our first specific identification test. The reason for selecting all terminated employees is based on the temporary criteria and the fraud that the budget owner is committing over a period of time.

The second test is based on payment method. If the employee is paid with direct deposit, then through our data analytics we could identify all terminated employees that had a bank account change during their employment period. Since the scenario could not occur without a change to bank account, the analysis provides a sample that has a higher probability of being consistent with the specific fraud scenario.

If the employee is paid through a manual check, then the specific identification identifies a group of employees that fit the profile but requires manual examination of records to see if red flags exist on the endorsement side of the check.

The Fundamental Strategies for Internal Control Avoidance

1. Avoidance of the dollar levels:
   1. Structuring transactions to avoid a control level. This is the process of splitting one transaction that would exceed the control level into two or more transactions to avoid a control level. The tests are designed to locate duplicate transactions or to identify multiple transactions in the aggregate that exceed a control level. This concept goes by many different names, such as split transactions.
   2. All transactions are below a control level. All transactions associated with a specific entity are below the control level. The aggregate dollar volume with the transaction is a key criterion in the selection process.
2. Off‐period transactions:
   1. Creating or changing an entity during non‐business hours or days.
   2. Creating, changing, voiding, or deleting transactions during non‐business hours or days.
   3. Creating, changing, voiding, or deleting transactions from a remote location.
   4. Create or change a transaction that originated from someone who did not typically process the transaction. The controller recorded the invoice versus the accounts payable function.
   5. Create or change a transaction by someone that is absent from work due to some form of personal leave.
   6. Create or change a transaction by someone responsible for the custody of an asset.
3. Illogical order of transactions; every business system has a logical flow of documents. In purchasing, there should be a requisition, followed by a purchase order, a receipt transaction resulting in a vendor invoice. Comparing the purchase order date to invoice date would indicate the transaction that avoided the purchasing internal controls.
4. Reclassification, changes, transfers, reversals, voids that occur within a short duration after the initial recording of the transaction or occur in two different operating periods.
5. Speed of transaction; the transaction is processed more quickly than policy or normal business practice. The technique compares the date of one transaction to the date of another transaction. A simple example is comparing the vendor invoice date to the payment date, searching for vendor invoices that are paid faster than normal terms.
6. Use of aged documents or system codes that provide open authority.
7. Manual transaction is a transaction that is created and processed external to the automated system and then is recorded manually in the database.
8. Override transactions; many systems have codes that allow a transaction to bypass computerized controls for logical business reasons. These override features allow a perpetrator to circumvent internal controls. A manual transaction can also be viewed as override transaction.

Illustrative Examples of Internal Control Avoidance

1. Requesting a vendor to split an invoice so that both invoices only require one approval but in the aggregate would have required two approvals.
2. A dormant vendor's address is changed on Saturday night at 11:00 PM from a remote computer that links to the controller.
3. Purchase order is created after the receipt of the vendor's invoice.
4. Payroll manager issues two payroll checks to herself; the first is through the automated system, the second is a manual payroll check.

Guidelines for Use of Internal Control Avoidance Strategy

1. The internal control avoidance strategy is used when the concealment of the fraud scenario is at a medium level.
2. The false entity has limited linkage to the perpetrator's identity.
3. Locating false entities can still occur at this level when we have identified a person or a group of persons who are the focus of the data analytics.
4. The frequency number must be established for each test.
5. The pattern recognition is based on the design of the internal control.
6. All off‐period entity transactions should be selected. With business operating 24/7, the design of this test becomes more challenging.
7. Retrospective analysis of a contract or bid is an effective method to detect corruption.
8. The concepts of exact match, close match, and related match are critical to assess internal control avoidance.
9. The goal of internal control avoidance is to identify a transaction that has the appearance of avoiding an internal control.
10. The difference between specific identification and internal control avoidance is sometimes a blurred line. I encourage the reader to stay focused on the intent of strategy.

Consider the Following Scenario

Budget owner in collusion with a supplier splits invoices to stay below a control level for the purpose of overbilling the company based on price, resulting in the diversion of company assets (impact statement) or budget owner receives a kickback from the supplier (conversion statement).

In contrast, this scenario involves a real entity; therefore, entity testing is not relevant. The transaction testing will start with exact match on vendor invoices based on invoice number and date. The second criterion is based on the aggregate amount of the invoice match exceeding the control amount. While a frequency of one split transaction is sufficient for sample selection, a regular frequency of the invoice splitting for one vendor or one department would improve the odds of establishing intent. The next test would be to compare the selected transactions from the first test to the line items on the invoice to previous transactions for the same line item, searching for a pattern of price increases.

If no transactions are identified in the exact match test, the second level of testing would use a close match on invoice number and invoice date.

Guidelines for Use of Data Interpretation

1. The data interpretation strategy is used when the concealment of the fraud scenario is at a high level.
2. In my opinion, high concealment generally exceeds the requirements of an audit but would be included in fraud investigation. I also believe that data interpretation would be included in a whistle blower allegation in which the corporation has deemed the allegation to have merit. My comment is based on audits providing reasonable assurance versus absolute assurance.
3. The first step is identifying which fraud scenarios are included in the audit scope due to high concealment.
4. The selection of the fraud scenario could occur simply because the auditor is conducting a fraud audit or the fraud risk assessment has rated residual risk as high.
5. The advantage of planning at the high concealment is that it creates the opportunity for locating all fraudulent activity related to the fraud scenario.
6. The disadvantage of not planning at the high level is the opportunity for false negatives. In essence, the auditor missed the fraudulent activity because the perpetrator was more sophisticated than the audit procedure.
7. Once the fraud scenarios are identified, the process starts with identifying the population of data that relates to the fraud scenario. The transactions should be summarized in a high‐level format. The inclusion/exclusion theory is the next step.
8. The exclusion is intended to eliminate the lines, whereas the inclusion is the lines being considered within the data interpretation strategy. The key is to document your judgment for both the exclusion and inclusion. Since the process is judgmental, the decision process will also be high‐level explanations.
9. The exclusion theory is to exclude those records or lines that are not consistent with the fraud theory that links to the specific fraud scenario.
10. The goal of the exclusion step is to reduce the size of the report requiring manual review.
11. The last step is the inclusion theory, or the basis for selecting a line for audit examination.
12. For expenditure or revenue audits, I typically use a format that summarizes transactions by aggregate dollars, aggregate record, maximum record, minimum record, and average record. Depending on the analysis, the report should include data from entity file that will assist in the review. I have found entity creation date to be useful.
13. For payroll, I typically summarize the payroll transactions: number of payroll payments, gross payroll, and net payroll. I find the grade level or job description to be useful.
14. The goal of the visual review of the report is to reduce the size of the report through the use of data‐extraction routines that filter out those lines that are not consistent with the fraud theory associated with the fraud scenario. This is a critical step in making the process a success. Imagine a 100‐page report with each page having 50 lines, which would require the auditor to examine 50,000 lines of data. Clearly, this is not a practical approach.
15. Using the data fields I have summarized, we make judgmental decisions about the inclusion/exclusion process. Using the columns of summarized data, we make judgments that are based on fraud theory and the mechanics of the fraud scenario. These judgments are not based on scientific studies but, rather, auditor judgment is based on experience.
16. We also use other external databases or Internet searches to support our decisions in selecting an entity for audit examination.

Consider the Following Scenario

Budget owner acting alone or in collusion with a direct report/causes a shell company to be set up on the vendor master file/processes a contract and approves a fake invoice for goods or services not received/causing the diversion of company funds (Figure 3.5).

Using the report of summarized data, we ask questions about the data to exclude certain vendor lines to reduce the report size to a number of lines that can be reviewed through visual examination:

Basis for Exclusion:

1. Aggregate number of records. Using the frequency concept we would ask how many false invoices the budget owner would submit in a one‐year period. Using the frequency of 52, we would exclude all vendor lines with greater than 52 records. The number 52 correlates to once a week.
2. Aggregate dollar value. In this exclusion process, we would first focus on eliminating small‐dollar vendor lines. I must caution that the perpetrator might use multiple shell companies to keep a low visibility. I also caution that you do not make any judgments in which you will not be able to eliminate any lines, which defeats the purpose of the process.
3. Maximum dollar amount. The budget owners typically do not want to submit a fake invoice to their supervisor. Therefore, we could exclude any vendor line when the maximum amount would require the approval of the budget owner's supervisor.
4. Minimum dollar amount. The exclusion factor for the minimum is more of a judgment than on the maximum dollar amount. I believe most auditors would see the logic in the exclusion factor. As a starting point, we could say, if the minimum is a negative number, denote a credit; we could exclude those vendor lines. What if the minimum is $2.49; would that indicate a real or a false invoice? One perspective is that the perpetrator would submit a low‐dollar invoice amount to allow the vendor to be set up. Another perspective is that a budget owner committing a false billing scheme would not submit an invoice for $2.49. Remember, I said the strategy is based on auditor's judgment.
5. Average amount. Once again, the exclusion factor is judgmental. Typically, the smaller the average, the more likely we would eliminate the vendor line.

Basis for Selection:

1. The report after applying the exclusion theory provides a listing of vendor lines that meet the high‐level criteria of our fraud data profile for the fraud scenario.
2. One selection theory is that all perpetrators have a risk comfort level. The level might be high or low, depending on the perpetrator's fear of detection. Therefore, as the gap between the maximum amount and the average amount gets closer, it is one indicator of the perpetrator comfort zone for the dollar amount of the fake invoices. It may also indicate a perpetrator who has a predictable pressure for an income stream.
3. Whatever the selection criteria, the fraud auditor needs to identify the selection criteria before reviewing the report.

Guidelines for Using the Number Anomaly Strategy

1. In the number anomaly analysis, the data analysis starts with the data anomaly of the test, a pattern, and frequency of an even amount or recurring amount that links to one entity. The fraud auditor then needs to use data interpretation skills to determine which fraud scenario is most likely occurring.
2. The strategy is the least impacted by the sophistication of concealment.
3. The strategy does not work when the perpetrator continually changes the amount field.
4. The anomaly is the frequency of even numbers or a recurring number to one entity. The contra number is the anomaly.
5. The strategy is highly effective in locating false entity schemes based on the theory that a real vendor would normally have invoices of varying amounts.
6. The strategy is also useful in searching for pass‐through schemes involving equipment rental. Since rental amounts are often the same, the drill‐down review on the amount field would easily identify vendors.
7. In one project, a vice president created three shell companies and submitted invoices for $1,100 six times for each shell company.
8. In one project, a project manager created a shell company called BR Equipment. All the invoices were for $5,500.
9. In one project, the controller was concealing bad debt on the financial statement by concealing the rebill credit as a contra entry in the sales register. He would issue a credit for the old invoice and record the credit in the sales journal versus the sales adjustment general ledger account. The controller would then issue a new invoice, with a current date replacing the old invoice. The contra entry in the sales journal was the clue.
10. Contra‐entry schemes are immediately flagged. In one case, we identified negative adjustments in a deduction field that was increasing net pay versus decreasing net pay. In another case, the controller was increasing incurred cost for percentage of completion; the red flag was the size of credits existing in accounts payable. The largest was a negative $420,000.

Consider the Following Scenario

Project manager creates a shell company; he leases equipment under the shell company's name from a real equipment leasing company and then causes the company by which he is employed to lease the equipment from his shell company at an inflated price, resulting in the diversion of company assets.

In the number anomaly strategy, the analysis would identify a high frequency of a recurring invoice amount paid to the same supplier. Since the supplier is an equipment rental company, the next‐level analysis would focus on the invoice number pattern, most likely a sequential pattern, and the description field would be vague by normal industry standards. Referencing BR Equipment, one of the clues in the description field was the fact that the description field referenced a brand name of equipment that could have been leased directly from the brand‐name company.

Frequency Analysis

Frequency analysis is the process of assigning a record count that correlates to the number of transactions that are attributable to an entity that links to a fraudulent action, in essence attributable to a fraud scenario. The frequency analysis focuses on either over or under a predetermined record count. The record count number is judgmental, based on the auditor's professional experience and the relevant fraud theory. It should be noted that the record count is not relevant to every fraud scenario. In establishing a record count, we suggest the following guidelines:

1. The frequency count is based on the expected occurrence rate associated with the specific fraud scenario or the fraud pattern.
2. Frequency analysis is typically associated with the transaction analysis versus the entity analysis.
3. The number of transactions associated with false entity schemes is determined by the perpetrator.
4. In payroll, the number of transactions is typically associated with the payroll cycle.
5. Record count should be based on a logical interval whenever possible—that is, daily, weekly, monthly, quarterly, semiannually, or annually.
6. Specific identification strategies associated with transaction analysis should be sufficient to indicate an intent factor versus a normal error rate for the population.
7. Internal control avoidance strategies focus on the number of records avoiding a control threshold if the scenario is a false entity scenario.
8. Internal control avoidance strategies for real entity schemes can be a frequency of one or more.
9. Data interpretation for the frequency of the pattern is a critical aspect of the selection process.
10. Number anomaly frequency should be sufficient to indicate an intent factor versus a normal error rate for the population.
11. Remember, with every guideline there is a logical exception.

Pattern Recognition

Pattern recognition is the process of searching for a predefined condition in a data set. The pattern either is implied through the four strategies or is defined as an attribute to a fraud scenario. Every data interrogation routine uses pattern recognition. The key is to know what you are looking for versus identifying a data pattern that does not correlate to a fraud scenario. There are five general categories of pattern recognition for fraud detection:

1. Creating groups of data for further study, often called cluster analysis. The cluster is typically associated with a business process or transaction type within a business system. Based on the first cluster, the goal is to create a micro‐cluster within the primary cluster. The goal is to identify a discrete number of transactions that conforms to the fraud scenario data profile.
2. Anomaly pattern is the identification of transactions that do not conform to an expected pattern or deviate from the norm. The various patterns are: nonconformance with a process or procedure; event occurs at an unusual date or time; and illogical order of events or outliers analysis based on frequency, individual amount, aggregate amount, percentage, or range.
3. Outlier pattern is focused on the transactions that exist outside of the bell‐shaped curve.
4. Entity pattern is based on all the known permutations of the shell entity, conflict of interest, and real entity structures that are associated with fraud scenarios.
5. Transaction pattern is a form of predictive analysis that suggests a pattern of data within transactions is more likely to be fraudulent than nonfraudulent. It is a lot like building a hypothesis and testing the hypothesis through data examination.

Correlating the pattern recognition between entity and transaction is the key to fraud detection. When the transactional data associated with the entity fit the fraud action pattern, the likelihood of fraud detection increases dramatically.

Strategies for Master File Data

The first step is to understand that there are three primary categories of entities; the applicability will vary based on the nature of your organization. In each primary category, there are different types of entities that create different fraud scenarios and require unique search routines to locate the entity. The three primary categories of entity structures are shell companies, conflict of interest, and real entities. For vendors and customers, the following provides a list of the secondary type of entities within the primary category. Employees follow a similar pattern, but due to the nature of employees, the description would be different, whereas the concept would be the same.

Through understanding the different permutations, the fraud auditors can improve their pattern recognition. The following provides a list of entity patterns associated with fraud scenarios.

Shell Company:

1. Stand‐alone company.
2. Pass‐through stand‐alone company created by an internal source.
3. Pass‐through stand‐alone company created by salesperson at real company.
4. Assuming the identity of dormant vendor.
5. Temporarily assuming identity of the same active vendor.
6. Temporarily assuming identity of the random active vendor.
7. Causing a real vendor not on your master file to be added to master file, in essence, assuming the identity of a real entity.
8. Hidden entity
   1. Look‐alike name.
   2. Real vendor with multivendor numbers or names.
9. Temporary or one‐time entity.

Conflict of Interest:

1. Real company has one customer.
2. Pass‐through stand‐alone has one customer.
3. Real company with hidden ownership.
4. Real company with multiple customers has no hidden ownership that corrupts the internal selection process.

Real Company:

1. Real entity is complicit in corrupting internal source.
2. Real entity is extorted by internal source.
3. Real entity operates as a pass‐through, typically in collusion with an internal source.
4. Real entity operates under multiple names.
5. Real entity operates as temporary or one‐time entity.
6. Real entity is not complicit.
7. Subcontractors to a general contractor can function in the same manner; however, since the subcontractor is not within the master file, it is beyond the scope of this book.

Guidelines in Building Data Interrogation Routines for Entity Types

1. The first step is to decide which primary entity category is within the audit scope.
2. Data interrogation routines should be designed for each secondary type of entity in the primary category.
3. The description of the secondary entities will vary by revenue, payroll, and expenditures.
4. For shell companies, the data interrogation should search on missing information, anomalies in the identifying information, and matching to other company data files. If the shell company is a vendor, then matching to human resources or customer database would prove to be useful.
5. For multiple shell companies operated by the same individual, search on duplicate address, bank account, telephone number, or email address.
6. Shell companies operating as a pass‐through shell company by an internal source are similar to shell companies for false billing schemes.
7. For shell companies operating as a pass‐through by a salesperson from a real company, the data interrogation should search on duplicate address, bank account, telephone number, or email address.
8. Conflict‐of‐interest entity with one customer has a similar analysis to the shell company.
9. Assume identity schemes always search on change of address or bank account. The caveat occurs when the perpetrator is able to manually control the payment for expenditures or change or delete a customer's transaction after shipment.
10. Real companies operating under multiple names: Search on duplicate identifying information. The permutation typically is associated with corruption schemes.
11. For real companies, the analysis should focus on the transactional activity that links to the fraudulent action.

What Data Are Available for the Business Transaction?

Data is data. Maybe that's a philosophic statement, but for most data items used in fraud data analytics the concept is that basic. Finding the data in your databases is a different challenge. Most transactions have a core set of data that is necessary to initiate, process, and record the transaction. There is no magic here; the starting point for transactional fraud data analytics centers on the auditor's ability to use the following information:

1. Control number: purchase order number, vendor invoice number, payment number, sales order number, sales invoice number, remittance number, etc.
2. Date of the transaction: purchase order date, vendor invoice date, etc.
3. Amount of the transaction: vendor invoice amount, discount amount, payment amount, etc.
4. Alpha description of the transaction: words used to describe what was purchased, inventory description, etc.
5. Numeric description of the transaction: product number, sku number, etc.
6. General ledger account number.

Specific data elements that relate to a specific fraud scenario are discussed in later chapters.

Depending on the business system the auditor will need to change the generic term, control number, to a business‐specific number. We have vendor invoice numbers, customer order numbers, transaction numbers; the list goes on and on. What is important is to understand is how the control number or any other data element can be used in transactional fraud analysis. To explain the methodology we will use the control number to illustrate how to answer the six questions listed earlier. The chapter will address the remaining data items by providing the necessary guidance on how to use the data element versus illustrating the application of the six questions.

What Control Number Patterns Could Occur within the Specific Data Item?

The pattern question is not a fraud question but rather a logic question: What are all the logical patterns that can exist within the specific data element? Remember, many control numbers in your database are created by another organization (vendor or customer). That organization decides on the control pattern versus your company. Using permutation analysis, a listing of logical patterns associated with a control number follows:

1. No number.
2. Sequential number.
3. Duplicate number.
4. Random ascending numbers.
5. Random descending numbers.
6. Mix of ascending and descending numbers.
7. All alpha or alpha right‐justified or alpha left‐justified.
8. Date format numbers.
9. Project numbers.
10. Project number with hyphen sequential number.
11. Illogical range—the pattern focuses on the beginning control number and ending control number based on the date range in the scope period. The illogical question is whether the control number range makes sense for the perceived size of the vendor or customer. The determination is subjective and based on limited range. With the right professional experience, the analysis can be very effective to detect someone who knows not to use a sequential pattern but did not think about the range of numbers over a period of time.
12. Hidden number is a number that is intentionally disguised to avoid data detection. The number might have a letter added to avoid duplicate number testing, it might be created by selecting a number that was not used, or it might exceed the known range or a dormant number.

What Control Number Pattern Would Normally Exist in the Database?

False positives are an interesting problem in fraud data analytics. One of the reasons for false positives is a lack of understanding of the data. There was an oil commercial years ago in which the tagline was, “You can pay me now or you can pay me later.” The tagline is on point with understanding your data before you create reports. Most data patterns that we use in fraud data analytics are either a normal business pattern for an organization or an anomaly that might indicate a fraud scenario. The most bizarre story I have seen was a company that reverted back to control number 1 when it reached control number 100,000. Confused? Well, so was I, but that is the reality of the type of patterns your analysis might find attached to an entity structure.

In the pattern‐recognition stage, we need to understand both our business practices and our suppliers' and customers' business practices. If my suppliers are large public corporations, I would expect ascending direction of invoice numbers. If my suppliers are small, nonpublic companies, I would not be surprised to have invoices with no invoice number. This step is about creating realistic expectations as to the quality of the data for data‐mining procedures. In Chapter 4, the concept of data availability, reliability, and usability will be discussed.

Typically, a sequential pattern of vendor invoice numbers would be a red flag of a shell company. However, in certain industries, the sequential pattern is a normal business pattern. In a project‐based industry, invoice numbers are sometimes a customer's project number hyphenated for the project billing cycle (i.e., 0604‐19). Assuming that the supplier submitted 19 invoices with a range of 0601‐01 through 0604‐19, then the supplier invoice pattern is a sequential pattern. However, the sequential pattern identified in this example correlates to normal business practice versus a fraud scenario. The fraud auditor needs to understand the patterns that exist in the company's database and the patterns that correlate to a fraud scenario.

So, here is the million‐dollar question: Should the data analytics be further refined to mitigate the false positive, or should the audit team resolve the false positive through performing audit procedures? This should be a definitive decision within the fraud data analytics plan. The only wrong answer is to ignore the question.

What Would Cause a Pattern to Be a Data Anomaly versus a Red Flag of Fraud?

There are four categories of data anomalies in your database that will affect the success of your fraud data analytics plan:

1. Data entry errors. A digit is added to a vendor invoice number, the control number is entered as 19250 versus the correct control number of 1925, and the list goes on and on. Data reliability is further discussed in Chapter 4.
2. Changes in society. In payroll for years, having a duplicate bank account number with two different names would be a red flag of a ghost employee, or if the area code of the telephone number did not correlate to the physical location of the business, then maybe we found a shell company. Societal changes have changed the traditional red flags.
3. How your customer or suppliers use the five data elements on their documents. If a vendor includes letters in its invoice number, then the fraud auditor's ability to calculate an invoice number range via a control number is impacted.
4. False positives. The data anomaly matches the pattern for the fraud scenario; however, the pattern has a logical business explanation.

Which Patterns Link to the Fraud Scenario?

The fraud auditor needs to understand that selecting the pattern is an educated guess; however, without selecting the pattern, you will not be able to write the program to search for a pattern that is associated with a fraud scenario. Chapters 7 through 15 will provide examples of patterns that link to specific scenarios.

Data interrogation routines are designed to search for a pattern that correlates to a fraud scenario. There are no absolutes as to which pattern correlates to which fraud scenario. However, without careful consideration, the data interrogation step will search for data anomalies caused by errors or natural anomalies that simply exist in every database.

Let's select three patterns and correlate the control number to the most likely fraud scenario:

1. Sequential pattern of vendor invoice numbers is useful to locate shell companies or conflict‐of‐interest companies because the sequential pattern suggests that the vendor has only one customer.
2. Duplicate numbers is useful in searching for a real vendor operating in collusion with an internal person who is structuring invoices to avoid control levels or to search for intentional duplicate payment schemes.
3. Limited range is useful in searching for pass‐through entities operated by an outside salesperson who has more than one customer participating in the scheme or a shell company where the perpetrator was sophisticated enough to avoid a sequential pattern but not sophisticated enough to make the range of numbers consistent with the perceived size of the company. Pass‐through schemes are discussed in detail in Chapter 7.

How Do We Develop a Data Interrogation Routine to Locate the Links to the Fraud Scenario?

In this step, the fraud auditor becomes the programmer. Using the available software routines, the fraud auditor develops reports to identify the noted pattern for either audit examination or further refined data interrogation routines. This step requires both skill and imagination. The skill is associated with the use of the software. The imagination is associated with finding creative ways of working around the data issues that will exist in every database.

Illustrative Example of Transactional Data and False Entity

In one fraud data analytics project, an internal manager created three shell companies. The companies all had different addresses, in different states, and different telephone numbers. The only common pattern in the master file was that all three companies were created in the database on the same day, but at different times of the day. However, in the transactional file, the vendor invoices were all the same amount, the same date, and the same description, and the control numbers for all three companies had the same pattern: 0001, 020506, 0003, 071806, 0005, and 0006. Most likely, the pattern was intended to be a sequential pattern, but note that the same data error occurs in the control number for all three companies. If you believe in coincidences, then pass on further review. If, however, you do not believe in coincidences, then start your fraud investigation, because you have just found three shell companies that all link to the same individual because of the general ledger account.