Exam Overview and Scope
Who this guide is for
The Certified Anti-Fraud Specialist (CAFS) is an ACAMS certification for professionals working in fraud prevention, detection, analytics, and investigations, particularly in banks and non-bank financial institutions. Its emphasis includes payment and operational fraud, including authorized push payment (APP) fraud and first-, second-, and third-party fraud; it is not primarily an accounting-fraud credential.
Exam format and scope
As described in the ACAMS candidate handbook reviewed on October 11, 2026, the examination has 100 questions, a 175-minute time limit, and single-choice and multiple-response items. The stated passing score is 75; this guide does not convert that score into a percentage. The handbook assigns 40% to fraud risk management, 30% to fraud detection and analytics, and 30% to fraud investigations. Technology is integrated across the domains.
This guide is written in English for study purposes. Its language does not establish which languages are available for the official exam or course; check current options and logistics directly with ACAMS. Provider information can change, so consult the latest handbook before booking.
How to use the guide
Work through the concepts in sequence, then explain why the example supports a particular action and why the pitfall is weaker. The domain weights below are the handbook's reported examination blueprint, not a separate recommendation about how every candidate should divide study time.
Official references: ACAMS CAFS certification page and ACAMS CAFS candidate handbook.
CAFS examination domains
| Domain | Coverage | Official examination weight |
|---|---|---|
| Building a Fraud Risk Management Program | Risk appetite and governance; assessment, controls, policies, response, remediation, continuous improvement, and enabling technology. | 40% |
| Fraud Detection and Analytics | Indicators and typologies; APP fraud, account takeover, party types, data preparation, models, thresholds, and error trade-offs. | 30% |
| Fraud Investigations | Triage, evidence preservation, chronology, internal and external information, interviewing, reporting, recovery, and control feedback. | 30% |
60 useful CAFS concepts 1–10
1. The purpose of a fraud risk management program
Building a Fraud Risk Management Program
A fraud risk management program connects an institution’s objectives to a repeatable way of identifying, assessing, controlling, and reviewing fraud exposure. It should work across products and channels rather than depend on a single team or detection tool. Its effectiveness is judged by whether responsibilities, controls, information, and response decisions fit the institution’s risks and are improved when evidence changes.
Practical example: A bank adding instant transfers first maps likely scam and account-compromise risks, then assigns owners for preventive controls, monitoring, customer response, and review of emerging losses.
Common misconception: A list of fraud policies is not, by itself, a functioning program. Without accountable owners, working controls, and feedback from cases, written intentions may not reduce exposure.
2. Governance and accountability
Building a Fraud Risk Management Program
Governance determines who sets direction, accepts risk within their authority, operates controls, and receives information about performance and failures. Clear accountability helps prevent gaps between product, operations, analytics, and investigation teams. Oversight should be informed by useful reporting and escalation routes, while day-to-day responsibilities remain assigned to people who can actually carry them out.
Practical example: A fraud committee reviews rising transfer losses, asks the product owner to explain control changes, and assigns analytics and operations leads to report on agreed actions.
Common misconception: Assigning all responsibility to a fraud department can hide risks created elsewhere. Product and channel owners also need defined duties because their decisions shape exposure.
3. Fraud risk appetite
Building a Fraud Risk Management Program
Risk appetite expresses the kinds and levels of fraud exposure an institution is prepared to tolerate while pursuing its objectives. It should guide decisions about controls, customer friction, resources, and escalation—not serve as a promise that losses will not occur. Useful appetite statements are specific enough to inform decisions and are revisited when products, threats, or operating conditions materially change.
Practical example: A bank’s approved appetite requires new payment services to remain within internal fraud-loss limits and customer-harm tolerances. Pre-launch scenario testing indicates that a proposed instant-transfer service would exceed those limits. The product owner adds targeted safeguards and reassesses the exposure, escalating any proposed exception through the bank’s authorized approval process rather than treating projected revenue as permission to launch.
Common misconception: A broad statement such as “zero fraud” does not define practical decisions or acceptable trade-offs. It may sound strong while leaving teams without usable direction.
4. Fraud taxonomy and consistent classification
Building a Fraud Risk Management Program
A fraud taxonomy gives teams shared categories for describing schemes, affected products, actors, and outcomes. Consistent classification makes risk assessments, loss reporting, analytics, and investigations easier to compare. Categories should be useful for decisions and precise enough to distinguish materially different mechanisms, while still allowing cases with incomplete or changing facts to be recorded as uncertain.
Practical example: A case system separately records account takeover, APP scam, and suspected first-party misuse, with an uncertainty field when investigators have not established the actor.
Common misconception: Forcing every early alert into a definitive fraud category creates misleading data. Record uncertainty rather than turning an initial suspicion into a confirmed classification.
5. Contextual fraud risk assessment
Building a Fraud Risk Management Program
A useful assessment starts with the institution’s actual activities: products, customer groups, channels, transaction features, locations, and dependencies. It then considers relevant threats, vulnerabilities, likely consequences, and existing safeguards. The result should help prioritize action, not merely catalog risks. Reassessment is warranted when meaningful changes occur or when case and loss information challenges earlier assumptions.
Practical example: Before launching a remote account-opening feature, a team considers identity abuse, application fraud, customer friction, available verification signals, and how quickly funds can move.
Common misconception: Copying a generic enterprise risk list can miss the mechanics of a particular service. An assessment must connect threats to the institution’s real products and workflows.
6. Inherent risk
Building a Fraud Risk Management Program
Inherent risk is the exposure considered before taking the effect of controls into account. It helps reveal how a product or process could be abused if safeguards were absent or ineffective. The assessment should be grounded in relevant features such as speed, reversibility, access, and customer interaction, rather than treating a high-level product label as a complete risk analysis.
Practical example: A team assesses an instant, irreversible transfer as having substantial scam exposure before crediting any benefit to warnings, limits, or monitoring.
Common misconception: Calling a product low risk because current losses are low confuses observed outcomes with underlying exposure. Effective controls or limited experience may be masking the risk.
7. Residual risk after controls
Building a Fraud Risk Management Program
Residual risk is the exposure that remains after relevant controls are considered, including how reliably they operate. The assessment asks whether controls address the specific threat and whether their performance is supported by evidence. Residual risk is not automatically small because a control exists; nor must it always be lower in every respect if controls introduce new vulnerabilities or concentrate risk elsewhere.
Practical example: A review finds that a transfer limit reduces the impact of some compromises but leaves a gap for several smaller payments made in quick succession.
Common misconception: Subtracting a control from a risk register without checking its operation gives false assurance. Evaluate coverage, reliability, and any new exposure the control creates.
8. Control design versus operating effectiveness
Building a Fraud Risk Management Program
Design effectiveness asks whether a control, if performed as intended, can address the identified risk. Operating effectiveness asks whether it is actually performed consistently and achieves that purpose in practice. The distinction determines remediation: a badly matched control may need redesign, while a suitable control applied inconsistently may need operational fixes, monitoring, or clearer ownership.
Practical example: A step-up check is designed to interrupt suspicious transfers, but reviews show staff routinely bypass it during busy periods; the immediate issue is execution.
Common misconception: Treating a written procedure as proof of an effective control confuses design with operation. Conversely, replacing a sound design may not fix a failure caused by inconsistent use.
9. Preventive, detective, and corrective controls
Building a Fraud Risk Management Program
Preventive controls aim to reduce the chance that fraud succeeds; detective controls identify suspicious activity or control failures; corrective controls limit harm or address causes after detection. One measure can contribute to more than one objective, but the categories clarify what it is expected to achieve. A balanced response often uses several control types across the fraud lifecycle.
Practical example: A payee warning is preventive, transaction monitoring is detective, and a rapid account restriction after a substantiated compromise is corrective.
Common misconception: Monitoring alone does not prevent every loss, especially where payment movement is immediate. It needs timely response capability and, where appropriate, earlier protective measures.
10. Layered controls and compensating measures
Building a Fraud Risk Management Program
Layered controls use measures that address different stages or failure modes, so one weakness does not automatically defeat the entire program. A compensating control can reduce exposure when a preferred safeguard is unavailable or impractical, but its coverage and limitations should be understood. Layers should work together rather than repeat the same check while leaving a different attack path open.
Practical example: When a device signal is unavailable, a payment service combines transaction-context review, payee controls, and an appropriate customer confirmation instead of silently skipping protection.
Common misconception: More controls do not necessarily mean stronger protection. Redundant checks can add friction without addressing independent ways a fraudster could succeed.
60 useful CAFS concepts 11–20
11. Assessing product and change risk
Building a Fraud Risk Management Program
New products, features, and material process changes can alter the fraud opportunity before loss history is available. A pre-launch assessment considers the changed journey, likely abuse, control coverage, data availability, response capacity, and how effectiveness will be monitored. Risk review should continue after launch because real customer behavior and attacker adaptation may differ from design assumptions.
Practical example: A wallet feature permitting faster withdrawals is reviewed for account compromise, mule use, transaction monitoring coverage, and the team’s ability to respond after launch.
Common misconception: Reusing controls from a superficially similar product assumes identical loss mechanics. Compare the actual transaction flow, recovery options, and customer behavior.
12. Segmenting risk and calibrating friction
Building a Fraud Risk Management Program
Fraud controls should reflect meaningful differences in product, channel, transaction, and customer context. Segmentation can make interventions more proportionate than applying the most restrictive treatment to everyone. Decisions should use relevant evidence and be monitored for unintended exclusion or friction; a segment is a tool for tailoring controls, not a conclusion that each person in it is suspicious.
Practical example: A payments team applies additional confirmation to a risky combination of new payee, unusual transfer behavior, and recent account changes, rather than blocking every first payment.
Common misconception: A single risk label for an entire customer group can create unnecessary harm and miss risky behavior elsewhere. Assess the context and review outcomes.
13. Policies, procedures, and usable guidance
Building a Fraud Risk Management Program
Policies establish principles and responsibilities; procedures translate them into repeatable actions, decisions, and escalation paths. Guidance is useful only if relevant staff can find and apply it in real workflows. Documents should be maintained when products or threats change, with clear ownership and suitable training, while allowing authorized judgment where cases do not fit a standard pattern.
Practical example: A case-handling procedure tells analysts how to preserve transaction records, record uncertainty, and escalate a suspected account compromise for timely review.
Common misconception: A policy’s existence does not show that staff understand or follow it. Check usability and observed practice rather than relying only on document approval.
14. Roles, handoffs, and segregation
Building a Fraud Risk Management Program
Fraud processes often cross product, operations, analytics, customer support, and investigation teams. Defined roles and handoffs help ensure that alerts receive attention, decisions are recorded, and no critical task falls between teams. Appropriate separation of duties can reduce conflicts or unauthorized actions, while escalation routes allow complex or urgent cases to reach people with suitable authority.
Practical example: An alerting team records its rationale and transfers a high-impact case to investigators, while a separate authorized reviewer approves a sensitive account restriction.
Common misconception: More handoffs are not automatically safer. Unclear ownership and duplicate queues can delay intervention; make responsibility and decision authority explicit.
15. Fraud response planning
Building a Fraud Risk Management Program
A response plan defines how an institution coordinates when a suspected fraud event, control failure, or emerging pattern requires action. It can cover decision authority, communication, evidence handling, customer support, containment options, and post-event review. Plans should be tailored to plausible scenarios and tested so that teams understand dependencies before a fast-moving incident occurs.
Practical example: A bank rehearses a scenario involving multiple linked payment complaints, identifying who can coordinate account reviews, customer communications, and evidence preservation.
Common misconception: A response plan that only describes escalation contacts may not support effective action. Test whether teams can make decisions and coordinate under realistic conditions.
16. Containment and proportionate response
Building a Fraud Risk Management Program
Containment aims to limit continuing harm while facts are still developing. Options may include a focused review, a temporary restriction, customer contact, or a broader pattern investigation, depending on the evidence, urgency, and applicable process. The response should be proportionate, documented, and reviewed as new information arrives so that protective steps do not become unsupported permanent conclusions.
Practical example: After credible signs of account takeover, a team pauses a risky payment pathway pending checks while preserving access needed for the customer to receive support.
Common misconception: Treating every signal as grounds for the broadest restriction can harm customers without improving safety. Match the action to the risk and revisit it as evidence develops.
17. Root-cause analysis and remediation
Building a Fraud Risk Management Program
Remediation should address why a loss or control failure occurred, not only the visible symptom. Root-cause analysis may consider design, execution, data, incentives, handoffs, and changes in attacker behavior. Actions need owners and a way to confirm completion and effectiveness. A successful fix reduces recurrence or exposure rather than merely closing an issue in a tracking system.
Practical example: Repeated bypasses of a warning lead a team to examine workflow design and staff guidance, then test whether the revised process changes bypass rates.
Common misconception: Closing a remediation item when a document is updated does not establish that the underlying problem is fixed. Verify the control’s operation and outcomes.
18. Prioritizing remediation
Building a Fraud Risk Management Program
Prioritization compares the likely harm of an exposure with factors such as scale, speed, customer impact, control weakness, and the feasibility of mitigation. It should make trade-offs transparent and identify interim safeguards when a durable fix will take time. A ranking is a decision aid, not a substitute for reassessment when new incidents or evidence change the picture.
Practical example: A team addresses an exploitable, high-impact payment gap before a low-impact reporting defect, while adding targeted review during development of the permanent fix.
Common misconception: Prioritizing solely by the number of recorded cases can undervalue a rare but severe weakness. Consider plausible impact and the quality of the underlying evidence.
19. Metrics and meaningful indicators
Building a Fraud Risk Management Program
Metrics help determine whether controls and processes are working, but each measure needs a clear definition and interpretation. Useful reporting may cover losses, detection timeliness, review outcomes, customer friction, control performance, and case backlogs. Compare measures over time and across relevant segments, and investigate unexpected changes rather than assuming that a single favorable number proves program effectiveness.
Practical example: A team reviews confirmed loss, false-alert burden, time to review, and customer complaints together after changing a transfer rule.
Common misconception: A rising alert count is not proof that fraud is increasing or detection is better. It may reflect a rule change, data shift, or more low-value alerts.
20. Continuous improvement and feedback loops
Building a Fraud Risk Management Program
Continuous improvement uses outcomes from alerts, confirmed cases, customer reports, and control testing to reassess assumptions and adjust the program. Feedback should reach the people who set controls and build analytics, with changes evaluated after implementation. The cycle is iterative: a control may reduce one threat, create friction, or shift attacker behavior, requiring further observation and refinement.
Practical example: Investigators find that fraudsters repeatedly exploit a payee-creation gap, so product and analytics teams update controls and monitor the revised journey.
Common misconception: Collecting lessons from cases without changing decisions or control design is not improvement. Close the loop by assigning action and checking results.
60 useful CAFS concepts 21–30
21. Technology as an enabler, not a program
Building a Fraud Risk Management Program
Technology can support identity checks, transaction monitoring, case management, data analysis, and response, but tools do not replace governance or sound processes. Selection should be based on the risk addressed, data and workflow fit, performance evidence, and operational capacity. The institution remains responsible for understanding how a tool is used and for acting appropriately on its output.
Practical example: A bank evaluates a vendor’s device-risk signal against its own payment journey and response process before using it to influence reviews.
Common misconception: Buying an advanced platform does not automatically make a fraud program effective. A tool can fail through poor integration, unsuitable data, or weak operational follow-through.
22. Automation and human oversight
Building a Fraud Risk Management Program
Automation can handle scale and speed, while human review may be valuable for ambiguity, unusual impact, or exceptions. The appropriate division depends on the decision, evidence quality, reversibility, and consequences of error. Systems should have defined escalation and override processes, with monitoring for performance drift and clear accountability for decisions that affect customers or cases.
Practical example: A system routes routine low-risk activity automatically but sends a complex account-compromise pattern to a trained analyst for contextual review.
Common misconception: Assuming automation is neutral or infallible can conceal systematic errors. Human oversight also needs training, authority, and enough information to be meaningful.
23. Third-party and dependency risk
Building a Fraud Risk Management Program
Fraud controls may depend on vendors, data providers, payment partners, or other external services. Assess what happens if a dependency is unavailable, inaccurate, delayed, or changed, and understand how information is handled. Oversight should include fit for purpose, performance monitoring, escalation, and contingency arrangements proportionate to the service’s role in fraud decisions.
Practical example: Before relying on an external device signal, an institution tests how a service outage is handled and what alternative review is available.
Common misconception: Outsourcing a detection function does not transfer responsibility for the institution’s decisions. Understand limitations and keep a workable response when the service fails.
24. Testing controls and change resilience
Building a Fraud Risk Management Program
Testing asks whether a control behaves as intended in realistic conditions, including ordinary activity, edge cases, and changes to systems or threats. Testing before release can catch defects; ongoing monitoring can reveal later drift or workarounds. Results should inform remediation and be repeated after material changes, because successful performance in one setting does not guarantee effectiveness across channels.
Practical example: A team tests a new payee control against legitimate customer journeys and representative scam patterns, then checks outcomes after deployment.
Common misconception: A one-time launch test is not lasting assurance. Customer behavior, system changes, and attacker tactics can alter performance after the initial review.
25. Indicators, typologies, and conclusions
Fraud Detection and Analytics
An indicator is a feature that may warrant attention; a typology describes a recurring way fraud can occur; a conclusion requires an assessment of relevant evidence. A single indicator rarely distinguishes fraud from legitimate behavior on its own. Detection combines context and multiple signals to prioritize inquiry, while subsequent review determines whether the pattern is explained, remains uncertain, or supports a finding.
Practical example: A new device and an unusual transfer trigger review, but an analyst checks account history and customer context before characterizing the event.
Common misconception: A match to a known pattern is not proof that a customer or transaction is fraudulent. Treat the signal as a reason to examine evidence.
26. First-party fraud
Fraud Detection and Analytics
First-party fraud generally involves a person using their own genuine relationship or identity to deceive an institution for gain. The relevant behavior may include dishonest application information or a knowingly false claim about a legitimate transaction. Classification depends on evidence about the conduct, not merely on account ownership or an outcome that appears suspicious.
Practical example: A customer disputes a purchase they knowingly made, and evidence supports that the claim was deliberately false rather than a genuine misunderstanding.
Common misconception: A customer complaint or disputed payment does not establish first-party fraud. A person may be deceived, coerced, confused, or unable to recognize an unauthorized act.
27. Second-party fraud
Fraud Detection and Analytics
Second-party fraud commonly describes a genuine customer knowingly allowing another person to use an account or credentials in a fraudulent arrangement. The key distinction is the customer’s knowing participation, which must not be inferred simply from activity occurring through their account. Coercion, deception, or unauthorized access can produce similar transaction patterns but different explanations and responses.
Practical example: Evidence suggests an account holder knowingly gives another person access to receive and move fraud proceeds, prompting further investigation of the arrangement.
Common misconception: An account used by another person does not alone prove knowing assistance. Establish what the account holder understood and whether access was voluntary.
28. Third-party fraud
Fraud Detection and Analytics
Third-party fraud involves an external actor using deception, stolen information, or unauthorized access against a customer or institution. The account holder may be a victim rather than a participant, so detection and investigation should distinguish the attacker’s actions from the customer’s behavior. Signals such as unfamiliar access are useful, but they need contextual assessment and corroboration.
Practical example: A customer reports an unfamiliar transfer after credentials were compromised; investigators examine access and transaction records for activity inconsistent with the customer’s account use.
Common misconception: Activity on a customer’s familiar device does not rule out third-party fraud. A victim may be manipulated into taking actions or sharing information.
29. Authorized push payment fraud
Fraud Detection and Analytics
APP fraud involves a customer being deceived into authorizing a payment to a fraudster. Because the customer initiates the transfer, controls designed only to identify unauthorized account access may not detect the scam. Effective analysis considers payment context, payee changes, customer behavior, warning design, and available response options without assuming that authorization means the customer was not deceived.
Practical example: A customer authenticates a transfer after a scammer impersonates a trusted service; a new payee and an unusual payment sequence support timely review.
Common misconception: An authenticated payment is not automatically free of fraud. Authentication can establish how a payment was initiated without resolving whether deception influenced the customer.
30. Account takeover
Fraud Detection and Analytics
Account takeover occurs when an unauthorized actor gains access to or control of a customer’s account. Detection may combine changes in access patterns, device or credential signals, contact-detail changes, new payees, and unusual transactions. No one feature is conclusive: legitimate travel, device replacement, or accessibility needs can also change account behavior.
Practical example: A login from a new device is followed by a contact-detail change, a new payee, and rapid transfers, creating a stronger combined signal than the login alone.
Common misconception: A new device by itself does not establish takeover. Consider the sequence and context of events, then use proportionate verification or review.
60 useful CAFS concepts 31–40
31. Data quality before model changes
Fraud Detection and Analytics
Detection performance depends on whether input data is accurate, timely, complete, and consistent with the intended use. Missing events, inconsistent definitions, delayed updates, or incorrect joins can make an effective method appear weak or distort results. Before changing a model or rule, identify whether a data issue explains the observed performance and correct the foundation where possible.
Practical example: A sudden drop in account-takeover alerts leads analysts to find that a recent system change stopped supplying device-change events to the model.
Common misconception: Retraining or lowering thresholds cannot reliably repair missing or corrupted inputs. Diagnose the data pipeline before treating every performance change as a model problem.
32. Labels and ground truth
Fraud Detection and Analytics
Labels tell an analytic system which historical cases are treated as fraud or legitimate, but they may be incomplete, delayed, or wrong. A customer dispute, an alert closure, or an unresolved investigation is not automatically a reliable final label. Review how labels were created and whether outcomes are comparable before using them to train or evaluate detection methods.
Practical example: A team separates confirmed fraud from unresolved disputes instead of treating every dispute as a positive training example.
Common misconception: Assuming every historical label is accurate can teach a model the wrong pattern. Validate label sources and retain uncertainty where outcomes are not established.
33. Feature construction and leakage
Fraud Detection and Analytics
Features summarize information used to distinguish patterns and should use data available at the time a real decision is made. Leakage occurs when training or evaluation uses information that would not legitimately be available for the decision being tested. It can arise from later case outcomes or from improper overlap between training and evaluation data, such as testing on duplicate transactions already used for training. Check feature timing, provenance, stability, relevance, and evaluation-data separation so that measured performance reflects usable evidence.
Practical example: A model review finds that a feature records a later case disposition; removing it lowers test performance but makes the evaluation more representative of live use.
Common misconception: A very accurate retrospective result may be misleading if it relies on future information or contaminated evaluation data. Verify that features were available at the decision time and that evaluation records were appropriately separated from training records.
34. Class imbalance
Fraud Detection and Analytics
Fraud is often a small share of all activity, so a dataset can contain many more legitimate examples than confirmed fraud. Overall accuracy may therefore look high even when the method misses much of the fraud it is intended to detect. Evaluation should use measures and comparisons suited to rare events and reflect the operational costs of both missed cases and unnecessary alerts.
Practical example: A model that classifies almost every payment as legitimate has high overall accuracy in a mostly legitimate dataset but fails to find enough confirmed fraud.
Common misconception: High accuracy alone is not evidence of useful fraud detection. Examine performance on the relevant fraud cases and consider alert burden and loss impact.
35. Rules and models as complementary tools
Fraud Detection and Analytics
Rules encode explicit conditions, while statistical or machine-learning models combine patterns to estimate or rank risk. Rules can be transparent and quick to adjust; models can identify combinations too complex for simple conditions. A program may use both, but each requires suitable data, testing, monitoring, and a clear role in the decision workflow.
Practical example: A rule flags rapid payee changes while a model ranks transactions using broader behavioral signals, allowing analysts to prioritize cases.
Common misconception: A model is not automatically superior to a rule, and a simple rule is not automatically safer. Compare tools against the risk, evidence, and operational need.
36. Model validation and monitoring
Fraud Detection and Analytics
Validation checks whether a detection method is suitable for its intended purpose using relevant data and performance measures. Monitoring then looks for changes in inputs, outcomes, or effectiveness after deployment. Fraud patterns evolve, so a method that performed well historically may drift. Review should include operational effects such as alert volume and whether teams can act on outputs.
Practical example: After deploying a transaction model, the institution compares observed confirmed cases and review workload with expectations, investigating a sudden change in either.
Common misconception: A strong development test does not guarantee sustained live performance. Reassess the method when data, customer behavior, or threat patterns change.
37. Threshold selection
Fraud Detection and Analytics
A threshold determines how much evidence or model score is needed to trigger an alert or intervention. Lowering it can capture more potentially fraudulent activity but usually increases false alerts; raising it may reduce unnecessary review while missing more risk. Choose based on the scenario’s consequences, available review capacity, and evidence—not a general preference for more or fewer alerts.
Practical example: For a fast, hard-to-reverse payment, a team tests a more sensitive review threshold on the relevant segment and measures both missed cases and additional alerts.
Common misconception: Lowering every threshold is not a cost-free way to improve detection. Excess alerts can delay review and create friction for legitimate customers.
38. False positives and customer friction
Fraud Detection and Analytics
A false positive is legitimate activity incorrectly flagged as suspicious. These alerts consume review capacity and may delay or inconvenience customers, potentially reducing trust or causing staff to overlook important cases. Measure false alerts in context and assess their impact alongside fraud outcomes. The objective is not to eliminate all false positives but to make a defensible trade-off.
Practical example: A travel-related alert rule generates repeated interruptions for customers making legitimate purchases abroad, so the team reviews the rule’s context and targeting.
Common misconception: Treating every false positive as harmless ignores operational and customer costs. At the same time, removing all friction can increase missed fraud.
39. False negatives and missed fraud
Fraud Detection and Analytics
A false negative occurs when relevant fraudulent activity is not identified by a detection method. Its significance depends on the potential harm, whether other controls may still intervene, and how quickly the gap can be corrected. Reviewing misses can reveal weak features, data gaps, unsuitable thresholds, or a changed fraud pattern; it should inform targeted action rather than an automatic system-wide adjustment.
Practical example: A review of missed account takeovers shows that suspicious transfers often follow a contact-detail change, suggesting a focused improvement to event sequencing.
Common misconception: A few misses do not by themselves justify a global threshold reduction. Determine why the cases escaped and whether the same gap is present elsewhere.
40. Segment-level calibration
Fraud Detection and Analytics
Detection performance can vary across products, channels, transaction types, and customer behavior. Segment-level analysis can show where a method misses fraud or generates excessive alerts, supporting more targeted calibration. Segments need enough reliable data and periodic review; small samples or unstable definitions can create misleading conclusions and unfairly concentrate customer friction.
Practical example: A bank finds that a rule flagging transfers to newly added payees generates more false alerts in its mobile-banking channel than in its online-banking channel. Analysts check event definitions and confirmed fraud outcomes, then test channel-specific adjustments using sufficient reliable data.
Common misconception: A good overall result can hide poor performance in a particular segment. But overfitting small groups can also produce unstable or unjustified rules.
60 useful CAFS concepts 41–50
41. Combining behavioral and transaction signals
Fraud Detection and Analytics
Fraud detection can become more useful when it considers how events relate over time rather than treating each transaction independently. Sequences such as access changes, payee creation, and rapid movement of funds may provide stronger context than any event alone. Signals should still be checked for reliability, relevance, and legitimate explanations before driving a consequential intervention.
Practical example: A monitoring workflow links a new device, changed contact details, and several transfers to newly added payees for prioritized review.
Common misconception: A sequence that resembles a known pattern does not establish fraud. Patterns prioritize inquiry; context and evidence determine the next decision.
42. Explainable and responsible detection
Fraud Detection and Analytics
Detection methods should produce information that relevant teams can interpret well enough to review, challenge, and act on outputs. Their use should be monitored for unsuitable data, unexpected effects, and unjustified differences in customer treatment. Explainability does not require every model to be simple, but the institution should understand its limitations and how outputs influence operational decisions.
Practical example: Analysts receive the main factors behind a high-risk alert and can record why available evidence supports or contradicts further action.
Common misconception: A high score is not a self-explanatory finding. Treating it as proof removes the opportunity to identify bad inputs, context, or model limitations.
43. Triage and initial assessment
Fraud Investigations
Triage determines what a report or alert appears to involve, how urgent it is, and what safe next step is appropriate. It uses the information available without pretending that early facts settle the case. Relevant considerations include potential ongoing harm, evidence at risk of loss, customer needs, and whether a specialist or escalation route is appropriate.
Practical example: A report of continuing unauthorized access is prioritized for account-protection review while the investigator records what is known and what remains uncertain.
Common misconception: Triage is not a final finding. Closing a case because the initial report is incomplete may overlook urgent risks or evidence that can still be obtained.
44. Prioritizing cases
Fraud Investigations
Investigation priority should reflect the potential scale and immediacy of harm, the risk that evidence will disappear, links to other cases, and available resources. A consistent framework improves focus, but discretion may be needed when unusual facts create urgency. Record the basis for prioritization so that delayed or redirected cases can be reviewed and reprioritized as information changes.
Practical example: A case involving an active account compromise and multiple linked transfers is advanced ahead of an older, contained dispute with no ongoing activity.
Common misconception: First-in, first-out handling can ignore urgent continuing harm. Conversely, a large reported amount alone may not tell the full priority story.
45. Define the investigative question
Fraud Investigations
A clear investigative question identifies what the review is trying to establish, such as how access occurred, who controlled an account, or whether a payment followed deception. It guides evidence collection and helps avoid an unfocused search through available data. Investigators should consider plausible alternatives and refine the question when new facts change the scope.
Practical example: For a transfer the customer confirms they initiated, an investigator asks what instructions they received and whether the actual recipient and payment purpose matched what they had been led to believe.
Common misconception: Starting with a fixed theory can bias the review toward confirming it. Define questions that allow evidence to support or weaken competing explanations.
46. Preserve relevant evidence early
Fraud Investigations
Evidence preservation helps prevent relevant records from being altered, deleted, or lost while an investigation proceeds. Identify likely sources early and follow the institution’s authorized processes for retaining them. Preserve enough context to understand the material later, including where it came from and when it was collected, while keeping the collection focused on the case purpose.
Practical example: An investigator promptly flags relevant transaction, access, and customer-contact records for preservation before routine retention processes could remove them.
Common misconception: Waiting until a theory is certain can make useful information unavailable. Preserve relevant material early without collecting unrelated data indiscriminately.
47. Evidence handling and traceability
Fraud Investigations
Traceable evidence handling records what information was obtained, from which source, when it was accessed, and how it was stored or transferred. These details help reviewers understand whether a record is complete and how it supports a conclusion. Follow applicable internal requirements and protect evidence from unauthorized changes or access.
Practical example: A case note records the source and retrieval time of a transaction log and identifies the controlled repository where the original is retained.
Common misconception: A screenshot or copied extract without source context may be difficult to interpret or verify. Preserve provenance and relevant surrounding information.
48. Build a case chronology
Fraud Investigations
A chronology organizes relevant events in sequence, using dates, times, sources, and known uncertainties. It can reveal relationships among account access, customer contact, payee changes, payments, and reports. A sound chronology distinguishes recorded fact from interpretation and notes gaps, helping investigators test whether a proposed explanation fits the available timeline.
Practical example: An investigator places a contact-detail change, customer call, new payee, and disputed transfer on one timeline, noting which events come from system records.
Common misconception: A neat timeline can give uncertain information a false appearance of certainty. Identify the source and confidence of each important event.
49. Use internal data purposefully
Fraud Investigations
Internal information may include transaction records, access events, customer communications, case history, and control actions. Select sources that address the investigative question and establish how they relate to one another. Internal data can provide strong context, but it may contain errors or gaps and should not be treated as infallible simply because it comes from the institution.
Practical example: To assess a disputed transfer, an investigator compares payment details with login events and prior customer contacts rather than relying on a single system record.
Common misconception: More internal data is not automatically better evidence. Collect what is relevant and check whether records are complete, consistent, and correctly interpreted.
50. Evaluate external information and evidence
Fraud Investigations
External information can provide investigative leads or evidence of particular events. A partner's allegation or a shared fraud label generally requires corroboration before supporting a consequential conclusion; an appropriately obtained external transaction record may itself support a finding about a recorded payment. Assess provenance, reliability, completeness, timing, and permitted use. Distinguish what the material directly establishes from inferences that require further support.
Practical example: A partner reports that a payee appeared in another case, prompting investigators to compare relevant transaction details and check available internal evidence.
Common misconception: A third-party risk label is not proof about the customer or transaction under review. Assess the source and corroborate the connection.
60 useful CAFS concepts 51–60
51. Plan interviews around evidence gaps
Fraud Investigations
Interview planning starts with the facts already established, the questions that remain open, and the purpose of speaking with a person. Prepare neutral prompts, consider the sequence of topics, and allow the interviewee to describe events in their own words. Planning helps avoid repeated questioning, premature assumptions, and missed opportunities to clarify a timeline or alternative explanation.
Practical example: Before contacting a customer, an investigator identifies what is known about a disputed payment and prepares questions about the instructions the customer received.
Common misconception: An interview should not be used merely to obtain agreement with a theory. Open questions can reveal explanations that records alone do not show.
52. Conduct neutral, careful interviews
Fraud Investigations
A careful interview seeks relevant information without treating suspicion as established fact. Clear, neutral questions and accurate notes help preserve the person’s account and distinguish direct knowledge from assumptions or later interpretation. Consider the interviewee’s circumstances and communication needs, and follow applicable internal procedures for conducting and recording the interaction.
Practical example: An investigator asks the customer to describe how they selected a payee and what the caller said, rather than accusing them of knowingly sending funds.
Common misconception: Leading questions can distort the account and undermine its usefulness. Ask what happened before presenting an interpretation as though it were settled.
53. Consider deception, coercion, and vulnerability
Fraud Investigations
A person’s apparent participation in a transaction does not resolve whether they understood it, acted voluntarily, or were manipulated. Investigators should consider deception, coercion, and relevant customer circumstances alongside technical records. These factors do not prove fraud or vulnerability on their own; they shape appropriate questions, support needs, and the interpretation of behavior.
Practical example: A customer authenticated transfers but describes a caller directing each step, so the investigator explores the interaction rather than relying only on authentication records.
Common misconception: Authentication does not establish informed, unpressured consent. It records an aspect of the process, not necessarily the circumstances behind the customer’s action.
54. Corroborate and test alternative explanations
Fraud Investigations
Corroboration compares information from different sources or methods to see whether a conclusion is supported beyond a single account. Investigators should also seek information that could contradict their initial theory. This balanced approach reduces confirmation bias and helps distinguish a strong conclusion from one that remains uncertain or depends on an unreliable source.
Practical example: A device signal suggests familiar access, so the investigator compares it with customer contact, transaction timing, and evidence of who controlled the device.
Common misconception: Repeatedly finding the same claim in records that share one original source is not independent corroboration. Examine how each piece of information was generated.
55. Privacy and purpose-limited investigation
Fraud Investigations
Investigators should access, collect, retain, and share information in ways consistent with the case purpose and applicable privacy requirements. Focused collection reduces unnecessary exposure and makes the reasoning easier to explain. Where the next step involves sensitive information or external sharing, consider authorization, relevance, and the institution’s approved process before proceeding.
Practical example: An investigator requests records relevant to the disputed transfer rather than browsing unrelated customer activity, and records the reason for any permitted external disclosure.
Common misconception: Access to data for work does not mean every use is appropriate. Relevance and authorized purpose matter even when information is technically available.
56. Escalation and investigative reporting
Fraud Investigations
Escalation brings a case to a person or function with appropriate expertise or authority when risk, uncertainty, or potential consequences warrant it. A useful report states the question, material facts, sources, analysis, limitations, and outstanding issues. Separate observations from inferences so readers can evaluate how the investigator reached the assessment and what remains unresolved.
Practical example: A case summary describes the transaction sequence, source records, customer account, alternative explanations considered, and reason for specialist review.
Common misconception: A persuasive narrative is not a substitute for sourced analysis. Distinguish confirmed facts from assumptions and avoid overstating what evidence establishes.
57. Recovery and loss mitigation
Fraud Investigations
Recovery work seeks to limit loss or identify funds and assets that may be recoverable, while recognizing that results depend on timing, payment paths, evidence, and applicable processes. Coordinated, prompt action can matter, but recovery prospects should not replace investigation of how the fraud occurred. Document actions and outcomes so that the case record supports later review.
Practical example: After a suspected scam transfer, an institution promptly uses its established process to contact relevant payment partners while preserving records and continuing the case assessment.
Common misconception: A recovery request or returned payment does not resolve who caused the event or whether controls failed. Keep loss response distinct from the investigative conclusion.
58. Cross-case connections and intelligence
Fraud Investigations
Comparing cases can reveal repeated payees, devices, contact details, narratives, or transaction sequences that are difficult to see individually. A link can guide priorities and questions, but it does not prove that every connected person or event has the same explanation. Confirm the match quality, context, and permitted information use before treating a connection as meaningful.
Practical example: Two reports involve the same recipient account, so investigators compare payment timing and supporting records before deciding whether to coordinate the cases.
Common misconception: A shared attribute may be common, stale, or inaccurately matched. A connection is a lead to test, not an automatic finding against all linked customers.
59. Reach a proportionate case conclusion
Fraud Investigations
A case conclusion should match the strength and limits of the evidence collected. It may distinguish established facts, supported assessments, unresolved questions, and reasons for closure or further work. Decisions affecting customers should follow applicable procedures and authority. Recording uncertainty is more defensible than forcing a binary answer where the information does not justify one.
Practical example: The evidence supports that a payment followed a scam, but does not identify who controlled the recipient account; the report states both points separately.
Common misconception: Closing a case as proven fraud or legitimate activity simply because a system requires a category can overstate the evidence. Use qualified outcomes where available.
60. Feed investigative findings back into controls
Fraud Investigations
An investigation can reveal weaknesses in product design, data, detection, customer communication, or operational handoffs. Sharing appropriate findings with control owners turns individual cases into program learning. Feedback should preserve necessary uncertainty and privacy, assign follow-up actions, and be checked for results; a case is not a complete learning loop merely because it has been closed.
Practical example: Several completed cases reveal confusion around new-payee warnings, prompting a team to review the wording and test whether customers understand it.
Common misconception: A case-specific fix may fail to address a recurring pattern. Look across cases, identify the underlying cause, and verify that the broader adjustment works.
Six-step study plan
Sources and verification
Authority: ACAMS CAFS certification page (https://www.acams.org/en/certifications/cafs-certification) and ACAMS CAFS candidate handbook (https://www.acams.org/en/media/document/37704). The handbook supports the domain structure, weights, question count, time limit, item types, and stated passing score summarized here. Provider details may change; verify current information with ACAMS. This guide is original educational material, not official or recalled examination content.