CFCI common mistakes
CFCI · Understand the traps and how to avoid them.
Treating the three FATF predicate categories as interchangeable when classifying an offence, so a case is labelled 'cybercrime' simply because a computer was involved rather than because the conduct meets a defined predicate such as computer-related fraud or offences against confidentiality/integrity/availability of computer data.
Candidates memorise that cybercrime is a predicate for money laundering but never learn the boundary between instrument, target, and predicate offence, so any digital element triggers the wrong label.
What to do instead
For each scenario, write two lines before answering: (1) what conduct element is alleged, (2) which predicate category that element maps to. Practise with cases where a computer is merely the instrument (e.g. email used to send a fraudulent invoice) versus where the system is the target (e.g. unauthorised access to a server).
Placing the placement, layering, and integration stages at the wrong point in a transaction chain, e.g. calling the initial deposit of cash from an illegal source 'layering' or calling a series of cross-border transfers 'placement'.
The stages are learned as a list rather than as a test of proximity to the predicate offence and of the purpose of concealment or obscuring of the audit trail.
What to do instead
Apply a proximity test: the stage closest to the criminal proceeds entering the financial system is placement; steps whose dominant purpose is to break the paper trail are layering; steps that give the funds an apparently legitimate origin are integration. Rehearse with a five-step fact pattern and justify each label in one sentence.
Confusing suspicious transaction reporting obligations with the substantive money laundering offence, so a scenario describing a failure to file a report is answered as if it were a laundering conviction, or vice versa.
Both appear in the same compliance chapters and candidates blur the duty-holder (the reporting entity) with the offender (the launderer).
What to do instead
Separate the two on a one-page matrix: who owes the duty, what triggers it, the threshold or suspicion standard, the reporting channel, and the sanction. Then classify each fact pattern by asking 'who is being criticised here?' before choosing an answer.
Reciting typologies by name (e.g. trade-based laundering, smurfing, shell company layering) without being able to identify the specific red flags that evidence them in a described transaction set.
Typology lists are easy to memorise and feel sufficient, but exam items test recognition of indicators such as over- or under-invoicing, mismatched shipping and payment parties, or structured deposits just under a threshold.
What to do instead
For each typology, build a three-column card: mechanism, observable red flags, and the control that would catch it. Test yourself by reading only the red flags and naming the typology.
Assuming a digital forensics artefact proves authorship or intent, e.g. concluding that because a file was created on a suspect's laptop the suspect created it, or that a login timestamp proves the account holder was the person at the keyboard.
Candidates conflate data provenance with human attribution, which is the most common logical gap in forensic reasoning.
What to do instead
Always state the artefact, the inference it supports, and the alternative explanations (shared device, remote access, malware, clock skew, account compromise). Answer attribution questions only when corroborating evidence such as network logs, MFA records, or physical access records is present.
Ignoring volatility order and chain of custody when describing seizure of digital evidence, e.g. recommending powering off a running machine first or imaging without hashing and documenting the write-blocker.
Textbook steps are remembered as a checklist without the rationale that live memory, encryption keys, and network connections are lost on shutdown.
What to do instead
Memorise the rationale, not just the order: capture volatile data (RAM, network state, running processes) before non-volatile storage; use a write-blocker; hash the image at acquisition and verification; record handler, time, location, and tool versions. Practise ordering steps in scenarios involving powered-on devices and full-disk encryption.
Misreading timestamps by ignoring time zone, UTC offset, or file system behaviour (e.g. NTFS last-access updates, MACB grouping, or FAT local-time storage), leading to a wrong timeline conclusion.
Candidates treat every timestamp as a simple fact and do not normalise to a single reference clock before building a timeline.
What to do instead
Normalise all timestamps to UTC in a working table, record the source artefact and its known quirks, and only then sequence events. Include a column for confidence and note any artefact whose semantics differ by file system or application.
Conflating indicators of compromise with indicators of attack or with vulnerabilities, e.g. listing an unpatched service as an IOC or treating a single failed login as proof of intrusion.
The vocabulary overlaps and candidates answer from familiarity with security tooling rather than from the definitions used in investigations.
What to do instead
Define each term precisely: a vulnerability is a weakness, an IOC is forensic evidence of past or present compromise (hash, domain, IP, registry key), an IOA is behavioural evidence of an attack in progress. Classify a mixed list into the three buckets and justify each placement.
Describing the cyber kill chain or attack lifecycle as a rigid sequence and failing to recognise that real intrusions loop, skip, or reorder phases, so a scenario that begins with credential phishing is mislabelled at the wrong phase.
The chain is memorised as a numbered list, and candidates map facts to phase numbers rather than to the adversary's actual objective at that moment.
What to do instead
Learn each phase by its goal (reconnaissance, weaponisation, delivery, exploitation, installation, command and control, actions on objective) and practise mapping partial fact patterns, explicitly noting when a phase is absent or repeated.
Answering cross-domain items in a single lens, e.g. analysing a ransomware case purely as a cyber incident without addressing the laundering of the ransom payment, or purely as money laundering without addressing evidence preservation.
Candidates revise domain by domain and never practise integrated scenarios, yet exam items frequently require two or three domains at once.
What to do instead
For integrated scenarios, produce a short structured answer covering incident classification, evidence handling, financial flow and reporting obligations, then check that each domain has at least one substantive point. Build a personal template and rehearse it on mixed cases.