CAFS Exam Guide: Fraud Risk, Detection, Analytics and Investigations
The ACAMS Certified Anti-Fraud Specialist (CAFS) credential addresses fraud work in banks and non-bank financial institutions. It is suited to professionals in fraud operations, payment risk, investigations, financial crime and customer protection.
ACAMS states that the exam has 100 questions in 175 minutes, using single-choice and multiple-response formats. The candidate handbook states a passing score of 75. Its three examination domains are building a fraud risk management program, fraud detection and analytics, and fraud investigations. Technology is integrated across them.
This guide develops decisions a specialist must make: matching controls to a threat, testing an alert against reliable data, preserving evidence, and feeding findings back into the program. Its practice activities are original study exercises, not exam questions.
Exam domains and study priorities
| Examination domain | Official ACAMS exam weight | This guide's study priority |
|---|---|---|
| Building a Fraud Risk Management Program | 40% | Work through concepts 1–24; design and assess controls for several products and channels. |
| Fraud Detection and Analytics | 30% | Work through concepts 25–42; interpret data, compare alerts and justify threshold changes. |
| Fraud Investigations | 30% | Work through concepts 43–60; practice defensible sequencing, evidence handling and reporting. |
60 essential concepts 1-10
1. Set a usable fraud risk appetite
Building a Fraud Risk Management Program
Fraud risk appetite becomes useful when leaders translate broad tolerance into decisions for products, channels, losses, customer harm and service interruption. Set escalation triggers and owners alongside financial measures; a low loss total can conceal severe harm to a small group. Revisit the limits when payment speed or customer mix changes. The CAFS candidate handbook places this work within the official risk management domain.
Example: A bank launches instant transfers for new customers. Its fraud committee sets tighter initial limits, a customer harm trigger and a named escalation owner, then schedules review after observing legitimate usage.
Common mistake: Treating a single loss percentage as the whole appetite misses concentrated harm and operational disruption. Translate the stated tolerance into product-specific actions that staff can actually take.
2. Assign fraud governance and decision rights
Building a Fraud Risk Management Program
A fraud program needs named owners for accepting risk, operating controls, investigating cases and challenging performance. Document who can change a rule, pause a payment flow or approve an exception, with escalation when roles conflict. Oversight should receive evidence about outcomes, not just activity counts. Internal audit may assess governance independently, but management retains ownership of its controls and risk decisions.
Example: After losses rise in a wallet channel, product management proposes a higher transfer limit. Fraud operations supplies impact analysis, a designated risk owner decides, and independent assurance later tests the approval trail.
Common mistake: Calling fraud operations the owner of every risk obscures product and executive accountability. Separate operational advice from the authority to accept residual exposure and document the decision.
3. Map exposure before selecting controls
Building a Fraud Risk Management Program
A fraud risk assessment begins with how value, credentials and instructions move through a product. Map customer entry, authentication, account changes, transaction initiation, approval and payout. For each step, identify who could exploit it, what access they need and what loss or harm could follow. This sequence prevents a familiar control catalogue from crowding out channel-specific vulnerabilities.
Example: A lender maps an online disbursement journey and finds that bank details can change shortly before payout. The team tests that change path before buying a broader transaction monitoring package.
Common mistake: A generic list of fraud types can appear complete while missing the actual point of exploitation. Tie each threat to a concrete journey step and plausible actor capability.
4. Distinguish inherent and residual risk
Building a Fraud Risk Management Program
Inherent risk describes exposure before considering the effectiveness of current controls; residual risk reflects the exposure that remains after those controls operate. Estimate both using the same scenario and assumptions so that the difference is explainable. Evidence of control design alone is insufficient: test whether the control runs reliably and reaches the threatened population. Residual risk may still exceed appetite even when several controls exist.
Example: A merchant onboarding process has high inherent impersonation risk. Document checks reduce some exposure, but a sample shows manual overrides lack review, leaving residual risk above the approved limit.
Common mistake: Counting controls as proof of low residual risk assumes they work at the intended coverage and quality. Verify operation and exceptions before lowering the rating.
5. Use a common fraud scenario taxonomy
Building a Fraud Risk Management Program
A consistent taxonomy lets teams compare incidents without erasing important differences. Record actor relationship, authorization, entry point, deception method, payment or account channel, and outcome. A first-party false claim differs from a compromised account and from a customer who authorizes a payment under deception. Stable definitions improve trend analysis, ownership and control selection across products.
Example: Two disputes both involve new devices. One customer made a false nonreceipt claim; another lost account access to an intruder. Coding them separately points to different evidence and controls.
Common mistake: Labeling every disputed transfer as account takeover can inflate one trend and hide authorized payment scams. Classify from evidence about who initiated and understood the action.
6. Assess threats by product, channel and customer
Building a Fraud Risk Management Program
The same control can perform differently across products. Compare transaction reversibility, customer vulnerability, payout speed, device access and available recovery routes before ranking exposure. Segment where risk mechanisms differ, while checking that segmentation does not unfairly deny service to legitimate customers. The assessment should lead to a specific control choice and a measurable reason for that choice.
Example: A credit union applies stronger beneficiary-change checks to irrevocable international transfers than to internal transfers between a customer's established accounts, because recovery and instruction risks differ.
Common mistake: Applying one friction level to every customer journey treats all exposures as equal. Match intervention to the threatened step and test whether legitimate customers bear disproportionate cost.
7. Build controls in layers
Building a Fraud Risk Management Program
Layered controls place barriers at different points in a fraud path: enrollment, access, instruction, payment and post-event response. Layers should fail differently rather than depend on the same data or employee judgment. Map each control to a scenario and identify what the next layer catches if the first fails. This makes residual exposure visible and helps prioritize investment.
Example: A payment provider combines device registration, beneficiary-change review, transaction monitoring and rapid recall procedures. Each layer covers a different point at which a criminal could redirect funds.
Common mistake: Several rules using the same compromised phone signal are not independent layers. A single bad data source can defeat all of them, so examine shared dependencies.
8. Choose preventive, detective and responsive controls
Building a Fraud Risk Management Program
Prevention blocks an action before loss, detection identifies concerning activity, and response limits damage after a signal. Choose the mix according to speed, reversibility and customer impact. A highly intrusive preventive step may be justified for an unusual irreversible payout but excessive for a low-risk inquiry. Specify the expected decision and fallback when a control is unavailable.
Example: For first-time high-value payees, a bank delays release pending a targeted check. For established low-value payees, it monitors anomalies and keeps a fast recall route ready.
Common mistake: Describing an alert as prevention confuses detection with an actual stop. State whether the payment is held, reviewed after release or subject to recovery action.
9. Separate identity proofing from authentication
Building a Fraud Risk Management Program
Identity proofing establishes whether an applicant's claimed identity is credible at enrollment; authentication tests whether a returning user controls an accepted credential. A strong login cannot repair a weak initial enrollment, and sound proofing cannot prevent later credential theft. NIST identity proofing guidance helps structure assurance choices, while financial-sector customer due diligence duties must be assessed under applicable law and policy.
Example: A fraudster enrolls using a synthetic profile and then uses a valid authenticator. The login succeeds technically, so the firm reviews enrollment evidence rather than treating authentication success as identity proof.
Common mistake: Assuming a successful multifactor login validates the person's original identity collapses two different controls. Examine enrollment evidence and later access separately, especially when account ownership is disputed.
10. Protect authentication and recovery paths
Building a Fraud Risk Management Program
Account takeover controls must cover sign-in, credential reset, authenticator replacement and session recovery. An attacker may avoid the strongest login step by exploiting a weaker recovery path. Compare factor strength, resistance to interception, device binding and support-agent overrides against the threatened channel. NIST authentication guidance offers technical design criteria, but institutions must separately determine legal and policy requirements.
Example: A customer receives a new authenticator after a phone call to support, then funds leave the account. Review shows that reset checks were weaker than routine login checks.
Common mistake: Adding another login factor will not close an account recovery loophole. Test every route that can issue, replace or bypass the factor, including manual exceptions.
60 essential concepts 11-20
11. Design controls for authorized payment scams
Building a Fraud Risk Management Program
In an authorized push payment scam, a customer may pass authentication and approve the transfer while acting on deception. Controls therefore need to examine beneficiary changes, payment context and signs of coaching, not only credential compromise. Use targeted interventions that give the customer a genuine chance to reconsider. Local reimbursement and reporting duties vary; a control design should not assume one jurisdiction's rules apply elsewhere.
Example: A customer adds a new payee after repeated calls from someone claiming to be bank security. A pause and specific callback question reveal the instruction came from the caller.
Common mistake: Treating valid customer authorization as proof of an untainted decision ignores deception. Investigate the surrounding instruction and beneficiary context before classifying the event.
12. Manage first-party fraud without presuming intent
Building a Fraud Risk Management Program
First-party fraud involves misuse by the person presenting as the customer, but intent is rarely established by a single anomaly. Design checks around verifiable representations, account history and transaction evidence, with a route to correct mistakes. Controls should distinguish deliberate misstatement from hardship, confusion or operational error. The related CAMS risk management guide can help connect this assessment to broader financial crime governance.
Example: A borrower reports income that differs from payroll data. The analyst seeks dated source records and an explanation before escalating, since a recent job change could account for the gap.
Common mistake: An inconsistent field is an investigative lead, not proof of dishonesty. Preserve the source and timing of both values, then test plausible nonfraud explanations.
13. Address second-party and third-party misuse
Building a Fraud Risk Management Program
Second-party misuse can involve a person knowingly allowing another to use their account or identity; third-party fraud involves an outside actor exploiting a victim or their credentials. Distinguishing them changes customer protection, recovery and investigation steps. Map who controlled the account, who benefited and what each person knew at each stage. Avoid inferring consent merely because credentials or devices were shared.
Example: An account receives scam proceeds and immediately forwards them. Investigators compare messages, device access and withdrawal behavior before deciding whether the holder knowingly assisted or was manipulated.
Common mistake: A transfer from the customer's device does not settle whether they were complicit, coerced or compromised. Separate observed access from evidence about knowledge and intent.
14. Govern fraud rules and model changes
Building a Fraud Risk Management Program
A fraud rule or model change should have an owner, rationale, test period, approval record and rollback condition. Compare expected loss reduction with alert volume and customer friction before release, then monitor actual effects. Emergency changes can be faster but still need traceability and later review. This discipline prevents a successful short-term response from becoming an unexamined permanent control.
Example: After a new mule pattern appears, a team raises a velocity rule for one channel. It records the threat, simulates recent transactions and schedules review of declines and missed cases.
Common mistake: A lower loss figure immediately after a rule change may reflect seasonality or reduced transaction volume. Compare relevant cohorts and intervention outcomes before claiming effectiveness.
15. Write actionable fraud policies and procedures
Building a Fraud Risk Management Program
A policy should state authority, risk principles and required oversight; procedures should tell staff what to do at a decision point. Include trigger, permitted action, evidence to record, exception route and escalation deadline where timing matters. Test the procedure with a realistic case to expose ambiguous wording. Keep legal requirements, internal choices and recommended practices identifiable so revisions do not blur their source.
Example: A procedure for suspected account takeover specifies when to restrict access, how to verify the customer through a separate channel and which records to retain for investigation.
Common mistake: A statement to 'investigate promptly' provides no operational decision rule. Define the trigger and next action while allowing documented judgment when the facts differ.
16. Test control coverage and operation
Building a Fraud Risk Management Program
Control testing asks two separate questions: does the design address the threat, and did it operate for the intended population? Identify exclusions, manual overrides, missing data and processing delays. Sample both flagged and unflagged activity where feasible, because testing only alerts cannot reveal missed fraud. Record evidence that supports conclusions and limitations that prevent a stronger claim.
Example: A team samples beneficiary changes across mobile and branch channels. The mobile check worked, but branch overrides lacked supporting records, revealing a coverage gap rather than a model failure.
Common mistake: A dashboard showing that a rule is enabled does not prove every relevant event reached it. Reconcile source events to evaluated events and inspect exceptions.
17. Set proportionate customer friction
Building a Fraud Risk Management Program
Fraud friction has costs: abandonment, delayed access and customer distress. Use the least disruptive intervention that can resolve the specific uncertainty at the point of risk. Measure who is challenged, who passes and what harm is prevented, not merely total challenges. A control that looks effective in losses may be poor if it repeatedly blocks legitimate customers without better detection.
Example: A bank replaces a blanket hold on all new payees with a targeted check for unusual device and payment combinations. It tracks fraud prevented alongside legitimate transfers delayed.
Common mistake: Equating more challenges with stronger protection ignores false positives and unequal effects. Compare incremental fraud prevention with the real cost to legitimate users.
18. Plan a fraud response before an incident
Building a Fraud Risk Management Program
A response plan specifies who can contain activity, contact customers, preserve records, seek recovery and communicate with external parties. It should include alternate contacts and decision authority outside normal hours. Practice the sequence with a scenario that crosses fraud, cyber, legal and operations teams. NIST incident response guidance supports coordination and preservation, while applicable notification duties come from law and institutional obligations.
Example: A weekend credential attack generates hundreds of suspicious transfers. The practiced plan lets on-call staff suspend the affected path, retain logs and engage payment recovery contacts quickly.
Common mistake: A contact list alone is not a response plan. Staff also need the authority, trigger and order of actions needed to contain loss without destroying evidence.
19. Manage third-party fraud dependencies
Building a Fraud Risk Management Program
Vendors may supply identity checks, device signals, transaction scores or case platforms, but the institution still needs to understand their coverage and failure modes. Define data quality, service levels, change notice, access rights and contingency steps. Test what happens when a vendor feed is delayed or unavailable. A contract metric is useful only if it measures the control's actual purpose.
Example: A device intelligence feed stops updating for two hours. The payment team follows a predefined fallback limit and later reconciles transactions processed during the gap.
Common mistake: Assuming a vendor score is universally reliable hides product-specific gaps and outages. Validate its inputs and outcomes on the institution's own traffic.
20. Use metrics that explain control performance
Building a Fraud Risk Management Program
A fraud dashboard should connect exposure, alerts, confirmed cases, prevented loss, realized loss, recovery and customer impact. Use denominators such as transactions or active accounts to interpret changes in volume. Separate detection speed from investigation time, because they imply different fixes. Define case confirmation and loss timing consistently so apparent improvements do not come from recoding or reporting lag.
Example: A rise in alerts seems alarming until the team finds payment volume doubled. Loss per thousand transfers fell, while review time increased, pointing to a capacity problem.
Common mistake: Reporting only gross prevented loss rewards rules that flag large legitimate payments. Pair it with confirmed outcomes, missed fraud estimates and customer friction.
60 essential concepts 21-30
21. Prioritize remediation by causal weakness
Building a Fraud Risk Management Program
After an incident, distinguish the attacker technique from the control weakness that enabled it. Identify the earliest feasible interruption point, the owner and the evidence needed to verify a fix. Prioritize weaknesses that recur or affect multiple products. Track temporary containment separately from durable remediation, since an emergency block may become obsolete when the attack changes.
Example: Several takeover cases used different phishing messages but the same weak authenticator replacement process. The team fixes replacement checks and tests support-agent overrides across channels.
Common mistake: Adding a rule for each observed message variant treats symptoms as separate causes. Look for the shared process failure and confirm that the fix covers it.
22. Use technology with accountable human decisions
Building a Fraud Risk Management Program
Automation can prioritize events and enforce limits at scale, yet people must understand when to override it and how to document that choice. Define which decisions can be automated, what evidence the system exposes and when a specialist must intervene. Monitor drift, outages and customer complaints as control signals. Technology is integrated across CAFS domains rather than confined to a separate examination domain.
Example: A model automatically holds high-risk transfers, but an analyst can release one only after recording the corroborating evidence and a second approval for large amounts.
Common mistake: A human review step is weak if reviewers merely accept a score without underlying context. Give them the relevant facts and a clear decision standard.
23. Coordinate fraud and financial crime controls
Building a Fraud Risk Management Program
Fraud and money laundering risks can intersect when stolen proceeds move through accounts, but their purposes and legal triggers differ. Define referral points and shared evidence so teams can act without assuming every fraud case establishes a separate offense. Financial crime specialists may need different analysis of transactions and relationships. The CAMS guide provides adjacent context for that work.
Example: A mule account receives scam proceeds and sends them onward. Fraud staff contain further loss and share transaction evidence with the financial crime team for its separate assessment.
Common mistake: Treating a fraud classification as automatic proof of money laundering skips a distinct assessment. Record the suspected conduct and route evidence to the team with the relevant mandate.
24. Review program changes after launch
Building a Fraud Risk Management Program
A launch review should compare expected fraud exposure and control behavior with observed outcomes. Check whether new channels, customer segments or criminal adaptations changed the assumptions in the original assessment. Use incidents, complaints, sampled transactions and staff exceptions together; each source has blind spots. Assign actions and retest them, rather than closing the review when a report is circulated.
Example: Three months after introducing instant payouts, a firm finds that night-time exceptions drive most confirmed losses. It changes staffing and limits, then measures the next period's outcomes.
Common mistake: An annual review date cannot substitute for a trigger when exposure changes rapidly. Reassess after material product changes or a new attack path appears.
25. Start detection with a testable fraud hypothesis
Fraud Detection and Analytics
Useful analytics begin with a suspected behavior, the data that could reveal it and a plausible innocent explanation. State what an alert should cause an analyst or system to do. This keeps feature selection tied to an action rather than to whatever fields are available. Test the hypothesis on confirmed cases and representative legitimate activity, acknowledging that confirmed cases may be an incomplete sample.
Example: A team suspects rapid beneficiary changes before account draining. It compares change-to-transfer intervals in confirmed takeovers and ordinary customer activity, then defines a review action.
Common mistake: A statistically unusual event is not automatically fraudulent. Ask whether the pattern fits a mechanism and whether the intervention can resolve the uncertainty.
26. Prepare data before trusting an alert
Fraud Detection and Analytics
Fraud signals depend on consistent timestamps, identifiers, currencies, status codes and missing-value treatment. Reconcile records across source systems before calculating velocity or customer behavior. Document whether fields reflect event time, posting time or later corrections; mixing them can create false sequences. A model trained on clean historical data may fail in production if the live feed has different omissions or delays.
Example: An alert says a payee was added after a transfer. Investigators discover one system stores local time and another UTC, reversing the apparent order until timestamps are normalized.
Common mistake: Treating an engineered feature as a fact conceals its input assumptions. Validate source fields and timing before using it to stop payments or accuse a customer.
27. Recognize label and sampling bias
Fraud Detection and Analytics
Confirmed fraud labels often reflect cases the existing controls detected and investigators had time to resolve. Undetected fraud, abandoned transactions and disputed outcomes may be absent. Compare the labeled sample with the full transaction population before training or measuring a model. Where possible, use targeted sampling and delayed outcome checks to estimate what the alert process misses.
Example: A model trained only on manually reviewed alerts excels on that queue but misses small transfers never sent for review. A random sample of unalerted payments exposes the gap.
Common mistake: High accuracy on previously flagged cases does not prove broad detection. The evaluation set must include realistic normal traffic and plausible missed fraud.
28. Interpret behavioral indicators in context
Fraud Detection and Analytics
Device change, unusual time, new payee and atypical amount can signal fraud, but each also has legitimate causes. Consider combinations, customer history and the sequence of events. Weight a signal by how well it distinguishes the suspected mechanism from routine behavior, not by how dramatic it sounds. Preserve the underlying observations so an analyst can challenge the inference.
Example: A customer changes phones while travelling and makes a familiar bill payment. The new device matters less once destination, amount and established payee history are considered together.
Common mistake: A single red flag may be common among legitimate customers. Escalate on a coherent pattern or a high-consequence event, with reasons documented.
29. Detect authorized push payment patterns
Fraud Detection and Analytics
Authorized push payment detection examines the relationship between a customer's normal behavior and a new instruction, including beneficiary age, urgency, transfer sequence and contact history. Authentication success is expected in many such cases. Use interventions designed to test deception, such as a specific question about the payee's identity or payment purpose, rather than a generic warning that customers may ignore.
Example: A customer sends several escalating transfers to a newly added payee after changing the stated purpose twice. The analyst initiates a targeted conversation before the next payment.
Common mistake: A generic scam banner shown on every transfer produces little evidence about this customer's decision. Target the warning to the observed risk and record the response.
30. Detect account takeover as a sequence
Fraud Detection and Analytics
Account takeover often unfolds through access changes, recovery events, device enrollment, beneficiary updates and payments. Sequence these events rather than scoring each in isolation. Compare their timing with the customer's established patterns and known service interactions. NIST authentication guidance helps assess whether a successful sign-in actually reduces the concern raised by a suspicious recovery or session event.
Example: A password reset, new authenticator and large transfer occur within an hour. Each event could be legitimate, but their order and speed prompt immediate verification through an established channel.
Common mistake: A successful login does not erase suspicious preceding events. Review the path that granted access, especially resets and factor changes, before clearing the alert.
60 essential concepts 31-40
31. Identify possible mule activity
Fraud Detection and Analytics
A mule pattern may involve incoming funds from unrelated senders followed by rapid withdrawals or onward transfers. Assess account age, transaction purpose, counterparties, timing and customer explanation. The same surface pattern can occur in legitimate collection activity, so seek corroboration before assigning intent. Detection should support timely containment and referral while preserving a route to correct a mistaken restriction.
Example: A new account receives several small payments and forwards most funds to one destination. The team reviews messages and transaction context before deciding whether the holder is complicit or exploited.
Common mistake: Rapid movement alone does not establish criminal knowledge. Separate the transactional pattern from conclusions about the account holder and investigate each with appropriate evidence.
32. Use network links as leads, not identity proof
Fraud Detection and Analytics
Shared devices, addresses, beneficiaries or contact details can reveal coordinated activity, but a link may reflect a household, workplace or service provider. Evaluate the type, reliability and timing of each connection before drawing conclusions. Stronger clusters combine independent signals and a plausible transaction story. Preserve the raw linkage and uncertainty so reviewers can distinguish a lead from a finding.
Example: Several accounts share an IP address and send funds to one payee. The address belongs to a public network, so analysts focus on the payment relationship and device evidence.
Common mistake: A common IP address is not proof that one person controls multiple accounts. Test shared infrastructure and seek independent corroboration before escalating.
33. Tune thresholds to an explicit trade-off
Fraud Detection and Analytics
A threshold changes how many events are stopped, reviewed or missed. Compare candidate settings on representative data using confirmed fraud, likely missed cases, review capacity and customer disruption. Report precision and detection rate with their denominators, and examine performance by channel and customer group. A threshold justified for one product may fail when transaction speed or attack patterns differ.
Example: Lowering a transfer score threshold catches more confirmed scams but triples reviews. The team adds a second condition and tests whether it retains the added detection with manageable friction.
Common mistake: Selecting the setting with the fewest alerts can simply hide fraud. Compare the cost and consequences of false negatives as well as the workload from false positives.
34. Read false positives and false negatives correctly
Fraud Detection and Analytics
A false positive is a legitimate event treated as suspicious; a false negative is fraud that passes undetected. Their costs differ by product, payment reversibility and customer circumstances. Estimate both using outcomes that have had time to mature, because immediate labels can be wrong. Explain why a change improves the overall decision, rather than celebrating one error rate while ignoring the other.
Example: A new rule reduces account takeover losses but blocks many payroll payments. Analysts compare confirmed prevention, delayed wages and recoverability before deciding whether to narrow the rule.
Common mistake: Calling every cleared alert a false positive ignores cases with insufficient evidence. Keep unresolved outcomes distinct so performance measures do not imply certainty the investigation lacked.
35. Choose features available at decision time
Fraud Detection and Analytics
A feature is usable for prevention only if it exists before the decision must be made. Historical datasets may include chargebacks, investigator notes or final case labels created days later. Excluding that later information from training and backtesting avoids misleading results. Record feature latency and fallback behavior for missing data, especially when payment release occurs in seconds.
Example: A proposed real-time model scores well because it uses a dispute code assigned a week after payment. The team removes that field and retests with only pre-release data.
Common mistake: Excellent backtest results can reflect future information leaking into the model. Check when each feature was known, not merely when it appears in the database.
36. Validate models beyond one headline metric
Fraud Detection and Analytics
Validation asks whether a model serves its intended decision under realistic conditions. Examine performance across time, products, channels and relevant customer groups; inspect calibration, alert concentration and operational capacity. Compare it with a simpler rule or existing process. Document assumptions, limitations and monitoring triggers so decision makers know when the result should no longer be trusted.
Example: A model performs well overall but misses most takeover cases in a newly launched app channel. The team limits deployment there until it gathers suitable evidence.
Common mistake: A strong aggregate metric can conceal a weak high-risk segment. Break results down by the contexts where the model will actually control transactions.
37. Monitor drift and changing criminal behavior
Fraud Detection and Analytics
Data drift means incoming behavior or data quality differs from the development period; concept drift means the relationship between signals and fraud changes. Track feature distributions, outcomes, alert yield and complaints, then investigate the cause before retraining. A sudden change may reflect a new attack, product launch or broken feed. Each calls for a different response.
Example: A device-risk feature suddenly falls for nearly all customers. Engineers find a feed outage, so the team uses a fallback control rather than retraining on corrupted observations.
Common mistake: Retraining whenever performance falls can teach the model from bad or delayed data. First determine whether the problem is criminal adaptation, population change or pipeline failure.
38. Use analyst feedback without contaminating labels
Fraud Detection and Analytics
Analyst decisions can improve detection when the reason and supporting evidence are recorded consistently. Distinguish confirmed fraud, likely fraud, customer denial, unresolved cases and legitimate activity. Audit samples for inconsistent coding and delayed reversals before feeding outcomes into a model. The CFCS guide offers adjacent context for cross-channel financial crime analysis, but CAFS decisions remain grounded in the fraud mechanism.
Example: Reviewers mark alerts 'fraud' whenever a customer cannot be reached. The analytics team separates unreachable cases from confirmed loss before using those records for training.
Common mistake: An analyst disposition is not always a verified outcome. If uncertain labels become ground truth, the model learns the team's prior assumptions and errors.
39. Prioritize alerts by risk and urgency
Fraud Detection and Analytics
An alert queue should reflect potential harm, time until funds become unrecoverable, signal reliability and the action available. Separate a high-risk event awaiting release from a low-value historical anomaly. Define service targets and escalation paths, then measure whether urgent cases receive timely decisions. Capacity constraints should be visible rather than hidden by a queue sorted only by score.
Example: Two alerts share the same score. One concerns a pending irreversible transfer; the other is a completed small payment. The pending transfer receives immediate review.
Common mistake: Sorting purely by model score ignores intervention opportunity. Prioritize what can still be prevented or recovered, using score as one input.
40. Evaluate alerts with corroborating evidence
Fraud Detection and Analytics
An alert is a claim about risk, not a finding. Check independent evidence such as authenticated customer contact, device history, beneficiary relationship and transaction sequence. Note which observations support fraud and which support a legitimate explanation. Decide whether to release, hold, escalate or monitor based on the balance of evidence and the consequences of delay.
Example: A large transfer triggers an alert, but it matches a prearranged property payment confirmed through an established contact route. The analyst records the corroboration and releases it.
Common mistake: Clearing an alert because the customer answered a number supplied in the suspicious message is weak corroboration. Use an independently established contact route.
60 essential concepts 41-50
41. Measure the effect of an intervention
Fraud Detection and Analytics
A stop, warning or call can change customer behavior, so the observed outcome alone may not reveal what would have happened without it. Compare suitable groups, account for selection effects and record whether funds were actually at risk. Look at repeat attempts and migration to other channels after an intervention. This supports a more credible estimate of value than summing every blocked amount.
Example: A warning causes many customers to abandon payments. Follow-up shows some were scams and others were routine transfers completed later, so the team reports both outcomes.
Common mistake: Counting every abandoned payment as prevented fraud overstates impact. Confirm the suspected mechanism where possible and distinguish uncertainty from verified prevention.
42. Translate analytics into operational action
Fraud Detection and Analytics
Detection has little value if the alert arrives after funds leave or lacks a clear next action. Design data latency, routing, analyst instructions and decision authority together. Test how the workflow handles missing signals, duplicate alerts and out-of-hours volume. Feed confirmed cases and missed events back into the rule or model review, with evidence that the change improves decisions.
Example: A model identifies suspicious transfers quickly, but alerts wait overnight in a general queue. The team creates a release-time hold path and tests staffing against peak volume.
Common mistake: A sophisticated score does not itself prevent loss. Link it to a timely, authorized intervention and verify that staff can execute that intervention.
43. Triage an allegation before expanding the case
Fraud Investigations
Triage establishes the immediate risk, available evidence, possible victims and action deadline. Separate containment decisions from conclusions about wrongdoing. Record the allegation's source, credibility and uncertainty, then choose the narrowest steps that protect funds and records. Escalate promptly when the case crosses authority or legal boundaries, without waiting for a complete narrative.
Example: A customer reports a transfer they do not recognize while another is pending. The investigator checks the pending payment and preserves access logs before seeking a full interview.
Common mistake: Trying to prove the entire fraud before taking an authorized containment step may allow avoidable loss. Preserve options while keeping the allegation clearly unproven.
44. Build an investigation plan with decision points
Fraud Investigations
An investigation plan states the competing explanations, evidence needed to distinguish them, owners and time-sensitive decisions. Start with facts that can change containment or recovery, then pursue broader context. Update the plan as findings arrive rather than collecting every available record. Include privacy, employment and legal constraints where relevant, and document why a step was proportionate.
Example: For a disputed transfer, the plan first tests customer authorization and account access, then examines beneficiary history. It reserves employee access review for evidence that warrants it.
Common mistake: A checklist of all possible data requests can create delay and unnecessary intrusion. Tie each request to a question whose answer could change the next decision.
45. Preserve volatile evidence early
Fraud Investigations
Logs, session records, call recordings and device data may be overwritten or altered during normal operations. Identify retention windows and issue preservation requests before routine deletion occurs. Capture source, collection time, method and custodian so later reviewers can assess reliability. Preserve the original where feasible and work from copies; a screenshot alone may omit metadata needed to reconstruct events.
Example: A suspected takeover occurs near the end of a short session-log retention period. The investigator requests a protected export immediately and records the system and extraction time.
Common mistake: Waiting until the interview is complete can lose decisive technical records. Preserve time-sensitive material first, while limiting collection to data relevant to the allegation.
46. Maintain evidence provenance and integrity
Fraud Investigations
An evidence record should show where an item came from, who handled it, when it was collected and whether it changed. Use access controls, versioning and integrity checks suited to the material. Explain transformations, such as converting timestamps or filtering a transaction export. Provenance lets another reviewer reproduce the inference and identify gaps without relying on an investigator's memory.
Example: An analyst exports payment records, stores the original, and creates a separate normalized copy. The case log records the query, time zone conversion and each person who accessed it.
Common mistake: A polished chart without its source query and transformation steps may be impossible to verify. Keep the underlying records and a reproducible path to the display.
47. Construct a reliable case chronology
Fraud Investigations
A chronology aligns actions across payment, access, support and communications systems using a common time reference. Distinguish event time from recording time and mark estimated times clearly. Place each event beside its source and confidence level, then identify gaps and alternative sequences. Chronology can expose a causal path, but temporal proximity alone does not prove one event caused another.
Example: A reset request, support call and transfer appear out of order until system clocks are reconciled. The corrected chronology identifies which action preceded the new device enrollment.
Common mistake: Sorting raw timestamps from different systems may fabricate a sequence. Normalize clocks, preserve original values and mark uncertainty before drawing conclusions.
48. Separate facts, inferences and allegations
Fraud Investigations
A defensible case record distinguishes observed data from interpretations and statements by interested parties. Attribute each assertion to its source and note when evidence conflicts. Use provisional language for unresolved points, especially intent and identity. This discipline protects fair treatment and helps a decision maker see exactly which conclusion is supported by which evidence.
Example: A report states that a device accessed the account, the customer denies using it, and shared control remains unproven. It does not name the customer as the actor.
Common mistake: Writing 'the customer transferred the money' because the account was used converts account activity into an unsupported identity finding. Attribute the event accurately.
49. Verify customer contact independently
Fraud Investigations
Contact with a customer can clarify authorization, but a fraudster may control a compromised phone, email or active session. Select a previously established channel or use an approved verification path that does not rely solely on newly changed details. Record the questions, responses and verification method. Avoid revealing sensitive investigative facts until the person's authority to receive them is established.
Example: A caller claims a transfer was legitimate immediately after changing the account phone number. The investigator uses an established contact route and checks the change history first.
Common mistake: A responsive caller is not necessarily the customer. If the contact point changed during the suspected compromise, treat it as evidence to test rather than authentication.
50. Scope internal and external data requests
Fraud Investigations
Request data that can answer a defined case question, and document the authority to access or share it. Internal transaction and access records may be readily available; external records may require consent, formal process or a specialist team. Consider retention, privacy and cross-border constraints under applicable law and policy. A narrow request often arrives faster and creates a cleaner evidential record.
Example: To test whether a payee was newly controlled by a suspect, an investigator requests relevant account and transfer records for a defined period rather than a broad customer data dump.
Common mistake: Assuming every useful record may be collected or shared can breach access limits and delay the case. Establish purpose, authority and scope before requesting it.
60 essential concepts 51-60
51. Interview to test explanations
Fraud Investigations
An interview should seek an accurate account, not merely a confession or confirmation of a theory. Prepare open questions, establish the person's own sequence, then test specific inconsistencies against records. Record the method, participants and material statements under applicable policy. Delay revealing detailed evidence until the interviewee has given an unprompted account, when appropriate and lawful.
Example: An employee explains a manual payment release in their own words before seeing the system log. The investigator then asks about a time gap the explanation does not address.
Common mistake: Leading questions can contaminate the account and conceal alternative explanations. Start broadly, then put specific evidence fairly and record both answers and uncertainties.
52. Assess a disputed payment's authorization
Fraud Investigations
Authorization analysis should separate technical credential use, the customer's actual instruction and any deception shaping that instruction. Examine initiation path, authentication events, beneficiary details, customer communications and timing. A valid credential event may support access but does not settle who controlled it or whether the customer was deceived. Classification should follow the evidence and the institution's applicable definitions.
Example: A payment was confirmed with the customer's authenticator, yet messages show the customer followed a fake security officer's instructions. The case is assessed as possible authorized payment fraud.
Common mistake: Equating successful authentication with a fully informed payment instruction can misclassify scams. Investigate who acted, what they believed and how the payee was presented.
53. Investigate account takeover across access paths
Fraud Investigations
For suspected takeover, reconstruct enrollment, sign-in, recovery, session and transaction events. Compare device and network records with customer history, while recognizing that shared networks are weak identity evidence. Look for support-agent actions and factor replacement that could explain access. Cyber incident guidance can help coordinate technical preservation, but the fraud finding still depends on case-specific evidence.
Example: An attacker may have used a support reset rather than stolen login credentials. The investigator preserves call recordings, reset approvals and later session records to test that route.
Common mistake: Finding an unfamiliar IP address does not identify the intruder or prove takeover. Corroborate it with access-path changes, device evidence and customer account context.
54. Investigate suspected first-party misrepresentation
Fraud Investigations
A first-party case requires careful testing of a person's representation, their access to accurate information and plausible error. Compare dated source documents with application or claim statements, then give the person an appropriate opportunity to explain discrepancies. Distinguish a material intentional misstatement from stale data, misunderstanding or process failure. Escalation language should reflect what evidence supports, not what the loss suggests.
Example: A loan application lists income above a later payroll record. The investigator checks the employment period and asks about bonuses before concluding whether the difference was material.
Common mistake: A discrepancy is not by itself evidence of deliberate deception. Test timing, source accuracy and a reasonable explanation before making an intent finding.
55. Coordinate containment and recovery
Fraud Investigations
Containment aims to stop further harm; recovery seeks return of funds already moved. Both are time-sensitive but may involve different authorities and evidence. Record when a hold, recall or counterparty contact was requested and its outcome. Preserve records before disruptive action where feasible, while acting immediately when delay would materially increase loss. Follow applicable payment-network, legal and institutional processes.
Example: A suspicious transfer has reached another institution. The investigator starts the approved recall route, documents timestamps and beneficiary details, and separately preserves the access records supporting the case.
Common mistake: Waiting for a final fraud conclusion before attempting an authorized recall can squander the recovery window. A provisional, documented concern can support timely action.
56. Write findings for a decision maker
Fraud Investigations
An investigation report should state scope, key facts, sources, reasoning, limitations and recommended actions. Present the chronology and strongest contrary evidence, not only facts supporting the preferred explanation. Separate a finding about a control failure from a finding about a person's intent. Write so an independent reader can trace each material conclusion to records and understand what remains unresolved.
Example: A report concludes that a weak reset process enabled unauthorized access, while the actor's identity remains unknown. It cites the reset record and recommends a control change.
Common mistake: A confident executive summary cannot repair missing support in the case file. Link each conclusion to evidence and state where the evidence stops.
57. Handle external reporting through the right authority
Fraud Investigations
Potential police, regulator, payment-network or financial crime reporting has different thresholds, recipients and deadlines depending on jurisdiction and obligation. Investigators should preserve relevant facts and route the case to the designated decision maker. Record what was reported, by whom and when, without treating a referral as proof of guilt. Internal policy can require escalation earlier than external law requires reporting.
Example: A fraud case may also implicate suspicious fund flows. The investigator sends a documented referral to the designated financial crime team, which assesses its own reporting duty.
Common mistake: Assuming every confirmed fraud loss triggers the same external report ignores distinct legal tests. Identify the applicable obligation and authorized decision maker for that case.
58. Protect privacy and fairness during investigation
Fraud Investigations
An investigation can affect account access, employment and reputation before facts are settled. Limit access to case material, collect proportionate data and record reasons for adverse interim actions. Provide suitable review or correction routes under applicable law and policy. Fairness also improves accuracy: an affected person may supply evidence that changes the chronology or explains an apparent anomaly.
Example: A shared-device alert leads to a temporary payment restriction, but the customer supplies evidence of a family device. The team reviews the restriction promptly and documents its decision.
Common mistake: Treating a provisional alert as a final finding can cause avoidable harm and bias later review. Keep restrictions proportionate and revisit them as evidence develops.
59. Feed case lessons into control design
Fraud Investigations
Close a case with a structured account of the entry point, failed or missing controls, detection delay and recovery outcome. Identify which weakness is generalizable and which facts are case-specific. Assign an owner to each proposed fix, define a success measure and test after implementation. Investigation learning is incomplete if findings remain in a case system without changing risk assessment or operations.
Example: Three cases show that support agents accepted the same weak reset evidence. The case team proposes a revised check, and control owners sample later resets to verify improvement.
Common mistake: A list of recommendations without ownership or testing does not establish remediation. Specify the causal weakness and evidence that would show it has been reduced.
60. Close cases with explicit uncertainty
Fraud Investigations
Closure should record the outcome, evidence basis, unresolved questions, loss and recovery status, customer actions and referrals. Use a disposition that matches the available proof; an unresolved case should not be forced into a confirmed category to tidy reporting. Set conditions for reopening if new evidence arrives. Clear closure data also improves future fraud analytics by keeping uncertain labels separate.
Example: A customer dispute remains unresolved because key call records expired, although the transfer was unusual. The case closes with that limitation and a retention improvement action.
Common mistake: Marking an unproven case as confirmed fraud contaminates both reporting and model training. Preserve uncertainty and explain which missing evidence prevented a firmer conclusion.
Six-session study plan
Official references
Exam format and domain weights are attributed to ACAMS. Other linked standards and guidance inform specific controls or methods; their applicability depends on jurisdiction and institutional obligations.