IASIU CIFA cheat sheet

A fraud analyst is a role that converts raw transaction, claims, or identity data into evidence-based conclusions about whether fraud occurred, how it occurred, and how much it cost.

Core analyst outputs are four: detection (flagging suspect activity), investigation (testing hypotheses), quantification (loss and exposure estimates), and reporting (defensible documentation).

The analyst role differs from an auditor: auditors test compliance against controls; analysts test behavior against expected patterns and look for anomalies without a predefined rule.

Analyst independence means conclusions are driven by data and evidence, not by the referring department, the subject, or a recovery target.

Chain of custody: every data extract used in a case should record source system, extract date/time, query or filter applied, and handler, so findings can be reproduced.

The analyst's standard of proof is usually preponderance or 'more likely than not' for internal purposes; criminal referral requires evidence that supports proof beyond reasonable doubt.

Key fraud triangle concepts - pressure, opportunity, rationalization - guide interview and data questions but are not themselves evidence of fraud.

An analyst's work product may be discoverable; write every note and email as if a defense attorney and a jury will read it.

Red flags are indicators, not proof: a red flag raises the prior probability of fraud and must be corroborated by at least one independent data source.

Common quantitative red flags: round-number amounts, amounts just under an approval threshold, duplicate invoices, payments to employees or vendors sharing addresses, and transactions outside business hours.

Benford's Law: in naturally occurring datasets, leading digit 1 appears about 30.1% of the time, 2 about 17.6%, 3 about 12.5%, declining to 9 at about 4.6%.

Benford's Law applies to data spanning multiple orders of magnitude; it does not apply to assigned numbers, amounts capped by policy, or small samples.

Relative size factor (RSF) = largest amount in a group / second-largest amount in that group; a high RSF flags one outlier dominating a vendor or account.

Duplicate testing keys: exact match on invoice number plus vendor; fuzzy match on amount, date, and description to catch altered invoice numbers.

Segregation-of-duties testing compares who created, approved, and paid a transaction; the same user ID in two of those steps is a control gap.

Sampling: attribute sampling estimates a deviation rate; discovery sampling is used when even one occurrence matters, such as suspected collusion.

Hypothesis-driven analysis: state the fraud theory, list the data that would be true if the theory holds, then test for absence of that data.

Confirmation bias countermeasure: explicitly define what evidence would disprove the hypothesis before running the query.

Base-rate reasoning: if fraud prevalence is 1% and a test has a 5% false-positive rate, most positive alerts will be false positives even with good sensitivity.

Occam's razor in fraud work: prefer the simplest explanation (data entry error, timing difference) until evidence rules it out.

Root cause analysis: separate the fraud act, the control failure that allowed it, and the detection failure that delayed discovery.

Materiality threshold: prioritize by expected loss = probability of occurrence x estimated exposure, not by count of anomalies.

Document alternative explanations for every anomaly and state why each was accepted or rejected; unexplained anomalies weaken the report.

Timeline reconstruction: order events by system timestamp, not by document date, because documents can be backdated.

Data types: nominal (unordered labels), ordinal (ordered labels), interval (equal spacing, no true zero), ratio (equal spacing with true zero); only ratio data supports ratios like 'twice as large'.

Structured data lives in rows and columns with a defined schema; unstructured data includes free-text notes, emails, images, and call recordings.

Field-level properties that matter for analysis: data type, length, nullability, allowed values, and whether the field is system-generated or user-entered.

Data quality dimensions: completeness, accuracy, consistency, timeliness, uniqueness, and validity.

Metadata describes data - table names, field definitions, refresh dates, and source system - and should be captured with every extract.

Granularity is the level of detail in a record (one row per transaction vs one row per account); mixing granularities causes double counting.

Derived fields (calculated columns) should be reproducible from source fields and documented with the formula used.

Personally identifiable information should be minimized in analysis files; use pseudonymous keys where the case does not require identity.

A relational table stores records in rows (tuples) and attributes in columns; a primary key uniquely identifies each row and cannot be null.

A foreign key in one table references the primary key of another table and enforces referential integrity between them.

Cardinality describes relationship type: one-to-one, one-to-many, or many-to-many; many-to-many requires a junction table.

Normalization reduces redundancy by splitting data into related tables; denormalized or star schemas trade redundancy for faster analytical queries.

An index speeds lookups on a column but adds write cost and storage; unindexed joins on large tables are a common cause of slow fraud queries.

NULL means unknown or missing, not zero or blank; comparisons with NULL return unknown, so use IS NULL / IS NOT NULL rather than = NULL.

A view is a stored query presented as a table; it does not store data itself unless materialized.

Transaction logs and audit tables record inserts, updates, and deletes with user and timestamp - critical for proving who changed what.

Standard sequence: define the question, identify and obtain data, profile and clean, explore, test hypotheses, validate results, report, and preserve evidence.

Data profiling checks row counts, distinct value counts, null rates, min/max, and duplicates before any analysis is trusted.

Cleaning decisions (excluding records, correcting values) must be logged with the rule applied and the count of records affected.

Exploratory analysis looks for distribution shape, outliers, and unexpected gaps; confirmatory analysis tests a predefined hypothesis.

Reconciliation control: totals in the analysis file should tie back to the source system control totals before conclusions are drawn.

Validation: re-run the key query independently, test on a known-good sample, and have a second analyst review logic where stakes are high.

Reproducibility: save the exact query, filters, and extract date so the result can be regenerated months later.

Reporting step converts findings into loss estimate, control gap, and recommendation, each tied to specific evidence.

VLOOKUP(lookup_value, table_array, col_index, FALSE) returns the first exact match; FALSE is required for exact matching in fraud work.

INDEX(array, row_num, col_num) with MATCH(lookup_value, lookup_array, 0) is more flexible than VLOOKUP because it can look leftward.

XLOOKUP handles not-found values and left lookups natively; IFERROR wraps either lookup to suppress #N/A noise.

COUNTIF(range, criteria) and SUMIFS(sum_range, criteria_range1, criteria1, ...) are the core tools for duplicate counts and threshold testing.

Conditional formatting with a formula rule visually flags amounts above an approval limit or duplicate invoice numbers across a sheet.

Remove Duplicates and the COUNTIF>1 test serve different purposes: the former deletes rows, the latter preserves evidence of the duplicate set.

PivotTables aggregate by vendor, user, or month; adding a calculated field for amount variance reveals outliers by group.

Text functions LEFT, RIGHT, MID, TRIM, and SUBSTITUTE normalize invoice numbers before duplicate testing; trailing spaces defeat exact matching.

Freeze panes, filter, and sort are audit-friendly; sorting should be done on a copy so original row order is preserved as evidence.

Chart choice rule: comparison across categories uses bar charts; distribution uses histograms or box plots; trend over time uses line charts; relationship between two numeric variables uses scatter plots.

Pie charts are poor for more than about five categories and for showing small differences; use a sorted bar chart instead.

Benford's Law visualization plots observed vs expected leading-digit frequency; deviation is read as a pattern, not a single-digit spike.

Scatter plots expose outliers and clusters; annotate the specific transactions rather than relying on the reader to spot them.

Time-series plots reveal seasonality and period-end spikes; overlay a moving average to separate trend from noise.

Axis integrity: truncated y-axes exaggerate differences; label units, currency, and time zone on every chart used in a report.

Network or link charts map relationships among people, accounts, and addresses to reveal shared identities or circular flows.

A visualization in a fraud report must be reproducible from a stated data source and filter, and should show counts behind percentages.

Rule-based detection applies explicit thresholds (for example, payment over $10,000 to a new vendor within 30 days); rules are transparent but static and easy to evade.

Anomaly detection models flag records that deviate from learned normal behavior; they catch unknown schemes but generate more false positives.

Exception reporting compares actual values to a policy limit and lists every record outside it, such as approvals above a delegate's authority.

Trend analysis compares current-period metrics to prior periods and peers; a jump in average claim amount for one adjuster warrants review.

Cross-matching compares two independent files, such as the employee master and the vendor master, to find shared addresses or bank accounts.

Digital analysis tests digit patterns (Benford, rounding, duplicate amounts) to find fabricated numbers.

Proactive detection uses continuous monitoring with alerts; reactive detection begins from a tip, complaint, or audit finding.

Alert triage: rank by expected loss and case viability, document disposition for every alert closed, and track false-positive rates to tune thresholds.

Structure findings as: issue, evidence, impact (loss or exposure), root cause, and recommendation; lead with the conclusion, then support it.

Quantify with ranges where uncertainty exists, and state the basis (for example, 'tested 100% of 4,312 transactions; 37 exceptions totaling $182,400').

Avoid conclusory language such as 'stole' or 'fraudster'; use factual phrasing like 'the vendor received payments with no supporting receipt'.

Interviewing: use open questions first, then closed and confirmatory questions; avoid disclosing evidence details that allow a fabricated explanation.

Written reports should distinguish observation, inference, and opinion, and cite the source document or query for each factual claim.

Privilege and confidentiality: share findings only with those who need them, and mark drafts appropriately; careless distribution can waive protections.

Testimony readiness: be able to explain the data source, the query, and any limitation in plain language without jargon.

Visual and verbal consistency: numbers in the narrative, tables, and charts must reconcile, or the credibility of the whole report is undermined.

SELECT column_list FROM table WHERE condition returns rows; WHERE filters rows before grouping and cannot reference aggregate results.

GROUP BY groups rows for aggregation; HAVING filters groups after aggregation, so HAVING COUNT(*) > 1 finds duplicate keys.

JOIN types: INNER returns matches only; LEFT returns all left-table rows plus matches, which is how you find records with no counterpart.

The LEFT JOIN ... WHERE right.key IS NULL pattern finds orphan records, such as payments with no matching purchase order.

ORDER BY sorts results; LIMIT restricts row count and is useful for top-N outlier lists but hides the full population.

BETWEEN is inclusive of both endpoints; date filters should state whether the upper bound is included to avoid off-by-one errors.

Aggregate functions COUNT, SUM, AVG, MIN, MAX ignore NULLs except COUNT(*), which counts rows regardless of nulls.

String matching with LIKE uses % as a wildcard; UPPER() and TRIM() normalize text before comparison to catch formatting variants.

Subqueries and CTEs (WITH clause) break complex fraud logic into readable, reviewable steps.

Core building blocks for fraud scripting: variables, lists/arrays, dictionaries for lookups, loops, conditionals, and functions.

Pandas patterns: read_csv or read_sql to load, merge for joins, groupby for aggregation, and duplicated() for duplicate detection.

Vectorized operations on whole columns are far faster than row-by-row loops on large transaction files.

Reproducibility: set a random seed for any sampling, pin library versions, and keep scripts under version control.

Data validation in code: assert expected row counts and column types before analysis, and fail loudly rather than silently producing wrong results.

Logging every filter and transformation to a file creates an audit trail that supports the analyst's conclusions.

Never modify the source extract in place; write cleaned output to a new file and retain the original with a hash for integrity.

Regular expressions are powerful for normalizing invoice numbers, emails, and addresses but should be tested against known edge cases.