BCCILA common mistakes
BCCILA · Understand the traps and how to avoid them.
Treating a permissioned DLT as automatically equivalent to a public blockchain when analysing consensus, finality, and participant trust assumptions, so the answer describes proof-of-work mining where the scenario describes a validator set.
Candidates memorise 'blockchain = decentralised, immutable, proof-of-work' as a single package and never separate the consensus mechanism, the access model (permissioned vs permissionless), and the trust model. Exam items deliberately vary one variable to test whether the concepts are actually distinguished.
What to do instead
Build a three-column comparison table (access model, consensus/finality, who can read/write/validate) and, before answering any scenario item, explicitly identify which of the three the question is testing. Practise rewording the same scenario as public/permissioned and note which conclusions change and which do not.
Answering 'immutable, therefore irreversible and legally final' when a scenario involves a fork, a rollback, or a smart-contract upgrade, ignoring that recorded state can be changed by governance or majority action.
'Immutability' is learned as an absolute slogan. Candidates do not connect it to the practical mechanisms (hard forks, chain reorganisations, admin keys, proxy upgrades) that alter ledger state, so they miss items testing the gap between technical immutability and legal finality.
What to do instead
Learn the distinction between technical irreversibility, probabilistic finality, and legal finality, and list at least three mechanisms that can alter on-chain state (fork, reorg, upgradeable proxy, multisig admin). When a stem mentions any of these, treat 'immutable' as a claim to be tested, not a premise.
Assuming that because a token or smart contract is deployed on a decentralised network, the issuer or operator falls outside securities, payments, or commodities regulation.
Candidates conflate technological decentralisation with regulatory non-attribution. Regulators typically look at the function of the token (investment, payment, utility) and the activities of identifiable persons, not at the underlying ledger architecture.
What to do instead
Adopt a function-over-form habit: for every token scenario, ask (a) what rights does the holder get, (b) is there a common enterprise and expectation of profit from others' efforts, (c) who markets and controls it. Answer the regulatory characterisation question first, then the technology question.
Treating a smart contract as either 'just code, not a contract' or 'automatically a binding contract', instead of assessing offer, acceptance, consideration, intention, and capacity in the fact pattern.
Candidates polarise around the technology and skip the doctrinal test. Items often hinge on whether the parties intended legal relations or whether a statutory writing/electronic-signature requirement is satisfied.
What to do instead
Apply the ordinary contract-formation checklist to every smart-contract item, then add the two blockchain-specific layers: electronic signature/record validity under applicable e-commerce law, and whether code terms are incorporated by reference. State which element is missing or satisfied before concluding enforceability.
Missing that an automated execution (e.g., a liquidation or oracle-triggered transfer) may still be challenged for mistake, misrepresentation, unfair terms, or consumer-protection breach, and answering 'the code executed, so the result stands'.
Candidates assume code finality displaces legal remedies. In practice, courts and regulators can grant restitution, unwinding, or damages even where on-chain transfer is irreversible, and consumer law may override coded terms.
What to do instead
For each enforceability item, separate three questions: did the code execute as written, is the resulting contract valid/enforceable, and what remedy exists if not. Learn the concept of off-chain remedies against on-chain finality (restitution, damages, injunctions against a controller) and apply it explicitly.
Applying a single AML standard (usually the domestic one) to a cross-border or virtual-asset scenario without identifying the applicable jurisdiction, the travel-rule threshold, or the customer due-diligence tier.
Candidates learn one regime's thresholds and treat them as universal. Virtual-asset items often turn on which jurisdiction's rules attach, whether the entity is a VASP, and whether enhanced due diligence is triggered.
What to do instead
For every AML item, first write down: entity type, jurisdiction(s) of establishment and customer, and product/channel. Then apply the specific CDD/EDD and travel-rule obligations that follow. Memorise thresholds only alongside the regime they belong to, never in isolation.
Confusing the roles of the compliance officer, the MLRO, and senior management in reporting suspicious activity, or delaying a report pending internal investigation.
Candidates merge 'detect', 'escalate', and 'report to the FIU' into one step. Items test whether the candidate knows who decides to file, the tipping-off prohibition, and that suspicion (not proof) is the reporting trigger.
What to do instead
Draw the escalation chain explicitly: staff detect → MLRO assesses suspicion → MLRO files with the FIU → no tipping off. Rehearse that the threshold is suspicion on reasonable grounds, that internal investigation does not suspend the filing duty, and that record-keeping obligations survive the filing.
Treating personal data written to an immutable ledger as if it could be deleted by ordinary means, or concluding that hashing always removes personal-data status.
Candidates apply standard data-protection reflexes (delete on request) without confronting the technical impossibility of erasure on a distributed ledger, and they assume pseudonymisation equals anonymisation.
What to do instead
Learn the layered analysis: is the on-chain value personal data (identifiability, singling out)? If yes, which lawful basis and which erasure approach (off-chain storage with on-chain pointer, cryptographic erasure/key destruction, chimeric or redactable designs)? Practise stating that hashed data remains personal data where re-identification is reasonably likely.
Calculating a digital-asset tax result using only the disposal proceeds, ignoring cost basis, holding period, and the distinction between income at receipt and capital gain at disposal.
Candidates treat crypto tax as a single-step sale calculation. Exam items embed two events (receipt as payment/income, then later disposal) and test whether both are recognised, and whether the asset was held as trading stock or investment.
What to do instead
For every tax item, build a two-event timeline: acquisition (how, at what value, income or capital) and disposal (proceeds minus basis, character of gain). State the valuation method used for non-cash consideration and check whether the jurisdiction taxes mining/staking rewards as income at receipt.
Answering a cross-border item by naming one jurisdiction's law without running the conflict-of-laws steps (characterisation, connecting factor, public-policy override, and recognition/enforcement).
Candidates default to the law they know best or to the law of the platform's incorporation, skipping the private-international-law analysis that the question is actually testing.
What to do instead
Use a fixed sequence: characterise the issue (contract, property, regulatory, insolvency), identify the connecting factor (lex situs of the asset, governing law, place of business), check mandatory rules and public policy, then consider recognition of any foreign judgment or order. Apply the sequence aloud before choosing an option.