FCIBT common mistakes
FCIBT · Understand the traps and how to avoid them.
Treating every transaction output as belonging to a distinct person and building a suspect profile from raw address counts rather than consolidating addresses into clusters before drawing conclusions.
Candidates learn address-level tracing first and carry that mental model forward; the exam tests whether they understand that one wallet or custodian can control thousands of addresses, so address counts overstate actor counts and distort risk narratives.
What to do instead
Before any attribution statement, run and document a clustering pass (common-input-ownership heuristics, change-address identification, deposit-address reuse) and state the cluster-level conclusion, noting heuristic limits and false-positive risk explicitly.
Presenting a single heuristic (usually common-input ownership) as conclusive proof of common control, without flagging exceptions such as CoinJoin, exchange batch withdrawals, or smart-contract-mediated transfers.
Heuristics are taught as rules of thumb and candidates memorize them as facts; the exam rewards calibrated language and penalizes overclaiming, so unqualified heuristic conclusions read as analytical error.
What to do instead
Phrase every heuristic finding as a probabilistic indicator with the specific confounders named, and pair each clustering claim with at least one corroborating signal (timing, amount pattern, off-chain data) before asserting common control.
Confusing tainted or indirect exposure with direct receipt of illicit funds and reporting a wallet as 'sanctioned' or 'illicit' based on a one- or two-hop taint score.
Tracing tools surface exposure percentages prominently and candidates conflate risk scoring with legal status; the exam distinguishes direct transactions, indirect exposure, and listed-entity control.
What to do instead
Separate the three concepts in every answer: direct counterparty to a designated address, indirect exposure via taint, and control by a listed person or entity. State which one the evidence actually supports and what additional proof would be needed for the stronger claim.
Assuming a mixer or privacy tool guarantees anonymity and therefore ends the trace, instead of analyzing deposit and withdrawal timing, amounts, and fee patterns to link inputs to outputs.
Mixers are described in training material as obfuscation tools, and candidates stop analysis at the mixer boundary rather than applying statistical linkage techniques to the pool.
What to do instead
Describe the specific linkage methods available (amount correlation, timing windows, fee fingerprinting, reuse of addresses before and after the pool, peel-chain behavior) and state that privacy tools raise cost and uncertainty rather than eliminating traceability.
Treating cross-chain hops as a dead end and closing the trace when funds move through a bridge or swap service, rather than following the asset onto the destination chain.
Candidates learn single-ledger tracing workflows and lack a method for mapping a bridge deposit on one chain to a mint or release on another, so they stop at the boundary.
What to do instead
Build a bridge-mapping step into every trace: identify the bridge contract, match deposit and withdrawal by amount, timing, and destination address, then continue on the receiving chain. Note wrapped-asset and liquidity-pool mechanics that can break one-to-one matching.
Asserting that a transaction is anonymous or untraceable because it uses a privacy coin or a privacy-preserving protocol, rather than describing what metadata and off-chain data remain available.
Privacy features are often summarized as 'hides sender, receiver, amount', and candidates generalize that to total opacity, missing the operational and off-chain evidence that survives.
What to do instead
For any privacy-enhancing technology, enumerate what is hidden and what is not (timing, fees, node-level data, exchange records, view keys where lawfully available, chain-analytics pattern leakage) and frame conclusions as reduced visibility, not zero visibility.
Classifying every cryptoasset as a security or as a currency and applying one regulatory regime uniformly, instead of distinguishing payment tokens, utility tokens, stablecoins, and asset-referenced tokens by function and jurisdiction.
Candidates memorize a single taxonomy label from a headline case and apply it broadly; the exam tests functional classification and the fact that the same token can be treated differently across regimes.
What to do instead
Classify by function and by jurisdiction, name the specific test or framework applied, and state the consequence for the compliance obligation at issue (registration, Travel Rule, sanctions screening) rather than treating the label as an end in itself.
Describing the Travel Rule obligation only as 'identify the counterparty' without addressing the counterparty VASP's identity, the data elements required, the threshold, and what to do when the receiving institution is unhosted or unidentified.
Candidates recall the headline purpose of the rule but not its operational mechanics, so answers omit the information-transfer requirement and the handling of unhosted wallets.
What to do instead
Structure Travel Rule answers around four elements: originator and beneficiary data required, the threshold and jurisdiction, the counterparty VASP identification and due-diligence step, and the documented risk-based treatment of unhosted or unidentified counterparties.
Screening only the customer's identity at onboarding while ignoring ongoing screening of wallet addresses, transaction counterparties, and changes in sanctions designations after onboarding.
Candidates map traditional KYC habits onto crypto, where the risk unit is the address and counterparty, not just the named customer, and designations change continuously.
What to do instead
Describe a layered control set: identity screening at onboarding, address and counterparty screening at transaction time, periodic rescreening against updated lists, and a documented escalation path for hits including freeze, report, and lookback.
Documenting an investigation as a narrative conclusion without preserving the underlying evidence: no capture of block heights, transaction hashes, tool versions, query timestamps, or chain of custody for off-chain exhibits.
Candidates focus on the analytical finding and treat documentation as an afterthought, but the exam tests whether the work product would survive challenge and be reproducible by a second analyst.
What to do instead
Use a standard evidence record for every finding: transaction hash and block height, chain and tool with version, access timestamp, screenshot or export hash, and a custody log entry. Write conclusions so another analyst can reproduce them from the record alone.