Prepare for CAFCA by pairing each classic AML concept with its FinTech version, tracing one product — a wallet, marketplace, or BNPL book — through risk assessment, due diligence, monitoring, investigation, and reporting, and checking yourself against a rubric of named outputs at each stage.
Why Bank-Era AML Notes Need Rewriting Before They Fit CAFCA
The concepts transfer, but their FinTech versions differ: identity is digital, payments are instant and hard to reverse, and abuse arrives as networks of accounts rather than single customers. Learn each syllabus term as a pair — classic form and FinTech form.
Take the mule network. In a bank, a mule often means one account receiving anomalous credits that batch monitoring or a branch employee eventually flags. On a payment platform, mules are typically opened in bursts, share device or IP signals, pass automated checks as individuals, and move funds out within minutes. The unit of analysis shifts from account to network, which changes what data an investigator requests, what a monitoring scenario must test, and what a case file must document.
Practice the pairing deliberately. For beneficial ownership, write the bank version — documented owners of a corporate entity — beside the FinTech version — the controller of a merchant account who may appear on no registry. For customer risk scoring, pair the classic KYC profile with behavioral signals such as onboarding velocity and device age. If you can state both forms of every key term, scenario questions become translation exercises rather than guesswork, and the table below gives you three typologies to start with.
| Typology | What it is | Strongest data signals | Primary control | Where it reappears in the syllabus |
|---|---|---|---|---|
| Synthetic identity | An identity fabricated from real and invented attributes, nurtured until it passes checks | Thin credit or history, shared address or phone across applicants, identity age | Digital identity verification plus identity-correlation checks at onboarding | Typologies; due diligence |
| Mule network | Multiple accounts used to receive and relay criminal funds, often opened together | Device/IP clusters, rapid pass-through, synchronized in-out timing | Network-aware monitoring scenarios and cross-account investigation | Typologies; investigation; monitoring |
| Account takeover | A legitimate customer account seized via stolen credentials or social engineering | New device or location, changed contact details, unusual session behavior | Behavioral monitoring and step-up authentication, coordinated with cybersecurity | Typologies; fraud-AML touchpoints |
Perimeter Confusion: Money Transmitter, E-Money, Lending, or Crypto?
Financial crime obligations follow a product's regulatory characterization. A payments app, an e-money wallet, a BNPL book, and a crypto service can sit in different perimeters, which changes compliance ownership, escalation lines, and which controls are expected.
Trace the distinctions. Holding customer funds in a wallet points toward e-money obligations; moving funds on a customer's behalf points toward money transmission; extending credit adds consumer-protection touchpoints; crypto assets introduce tracing and sanctions complications of their own. The syllabus coverage areas span AML/CFT, sanctions, fraud, and consumer-protection touchpoints across these product types, so expect the study task to be naming the relevant touchpoints for a described product rather than reciting any single country's licensing regime — build the habit of asking, for each product, which four regimes it touches.
Then map the people. In a startup FinTech, the first line is often a product or operations team running automated onboarding, while a compliance lead or MLRO-style role owns escalation and suspicious activity decisions. Exercise: take a one-line product description — for example, 'an app that lets gig workers receive cross-border payouts into a stored balance' — and write down the likely perimeter, the compliance owner, and the escalation path to senior management. If you hesitate on any of the three, that is your revision target.
Governance When Your Controls Live at a Sponsor Bank, Vendor, or Agent
Scalable governance means proportionate design plus dependency management. Early-stage and large FinTechs need different control depths, but outsourcing onboarding, screening, or accounts to a sponsor bank or vendor never outsources accountability.
Connect the risk assessment to control design in both directions. A documented assessment identifies the products, corridors, customers, and channels that drive risk; controls — policies, procedures, training, screening, monitoring — must map to those identified risks, and independent testing checks whether the mapping holds. In FinTech environments, add the dependency layer: a sponsor bank may impose its own program requirements, a vendor may run identity verification, and an agent or partner may face customers directly. For each control, know who performs it, who is accountable, and how performance is evidenced.
Scaling creates a second, quieter governance problem: workarounds. As volume grows, manual reviews pile up, backlogs form, and teams improvise spreadsheet-based checks that no policy describes. CAFCA's governance domain treats metrics, issue management, and audit readiness as the antidote — track alert handling and review times, log control gaps as managed issues with owners and deadlines, and keep regulatory-change monitoring so new obligations update policies before testing finds the gap. When you read a governance scenario, look for the workaround; it is usually the fact that makes the program unsupported.
Scenario: Automated Screening Clears a Merchant With a Fabricated Controller
FinTech due diligence means verification plus expectation-setting, not screening alone. When automated checks return clean, the residual risk hides in data quality and behavioral intent — which only controller scrutiny and a transaction profile surface.
Worked scenario: a cross-border marketplace merchant onboards through an automated flow. Documents are internally consistent, sanctions and adverse media screening return no hits, and the risk model scores the merchant medium. The reviewing analyst approves because nothing is flagged. Two months later, sales volume spikes far beyond the listing history, payout requests target accounts unrelated to the business, and chargebacks climb. The mistake was treating screening clearance as the whole of due diligence: screening answers 'is this person known to be bad,' not 'is this business real and does this behavior fit it.'
The better decision happens at onboarding. Verify the controller through a source independent of the applicant's documents; set an expected transaction profile — plausible volumes, corridors, counterparty types — and tie monitoring thresholds to it; and define which mismatch triggers enhanced due diligence or an event-driven review. In the scenario, the volume spike against a thin listing history would have breached the expected profile immediately, converting a slow-loss problem into a fast detection. That is the practical difference between screening as a filter and due diligence as a baseline for ongoing monitoring.
Scenario: Thirty New Accounts, One Device Cluster, and a Tipping-Off Trap
Platform investigations are network problems. Correlate device, counterparty, and transaction data across accounts, coordinate with fraud, legal, and cybersecurity, act without tipping off customers, and document the case to an evidence standard.
Worked scenario: monitoring raises alerts on dozens of new accounts opened within days. Amounts arrive from unrelated senders and exit within minutes; several accounts share device fingerprints or overlapping contact details. The mistaken response: an analyst closes the accounts one at a time and sends each customer an identical message citing 'suspicious activity.' That response has two defects — it treats a network as isolated incidents, missing the upstream senders and the full cluster, and it uses language that could tip off connected actors before the case, and any law enforcement collaboration, concludes.
The better decision: build the network map first — devices, IPs, counterparties, timing — and pull in fraud and cybersecurity for account takeover or credential data, legal and privacy for account action and communications, and the MLRO-style role for the reporting decision. Preserve evidence before taking action, use neutral communications that state account closure without reasons, and route any law enforcement request through the defined internal channel rather than ad hoc replies. Document who decided what and on which evidence, because confidentiality obligations and potential follow-up questions both attach to the file, not to anyone's memory.
Designing Monitoring Scenarios and SAR Narratives for Instant, Cross-Border Volumes
Monitoring design starts from typology behavior and available data inputs, not from generic threshold folklore. A strong narrative then explains, with digital evidence, who did what, why it is unusual for this customer, and what the institution did.
For scenario design, work in four inputs. First, define the behavior the scenario targets — for example, rapid pass-through with deposits exiting within minutes across a specific corridor. Second, list the data the test needs: timestamps, counterparty jurisdictions, device signals, expected profile from onboarding. Third, set the logic and thresholds, accepting that instant cross-border products need scenario logic tuned to speed, not just amount. Fourth, plan the feedback: quality assurance reviews, operational metrics such as alert volumes against handling capacity, and intelligence from closed cases feeding back into tuning. An untuned scenario produces either an unmanaged backlog or a silent gap — both are examinable governance failures.
For reporting practice, draft narratives to a fixed structure: the subject and their onboarding profile, the observed activity with specifics — dates, flows, counterparties, devices — why it is inconsistent with the expected profile, and what actions the firm took. Avoid conclusory labels like 'obviously laundering'; the narrative's job is to let the reader reconstruct your reasoning from the evidence. Then address post-filing monitoring: filing a report does not end the relationship or the obligation, so continuing activity must stay under review, and the case should feed the emerging-typology feedback loop back into scenario design.
The Product-Trace Exercise, a Self-Check Rubric, and an Adaptable Sequence
Trace one FinTech product through all six domains in writing, score yourself against a four-point rubric per stage, then revise in paired domains — typologies with monitoring, due diligence with governance, investigation with reporting — before a final full trace.
Exercise: choose a wallet, marketplace, or BNPL product and produce one page per stage — perimeter and accountable owner; top three typologies with their signals; onboarding data, risk scoring, and your EDD trigger; one monitoring scenario with its data inputs and tuning plan; an investigation evidence list including device and counterparty data; and a short SAR/STR narrative skeleton. As a built-in self-check, examine whether your trace is thin on investigation evidence and narrative structure — those two stages depend on data sources that are easy to describe vaguely, and vagueness there signals exactly what to revise next.
Rubric — score each stage 0 to 4: one point each for naming the concept, naming the data source, naming the accountable role, and stating the escalation or reporting decision. Repeat the trace until you consistently score near the top on every stage; treat that as a learning milestone, not a prediction of any score. Adaptable sequence: run two or three cycles pairing the heaviest-content domains first — typologies with monitoring, then due diligence with governance — then investigation with reporting, and finish with a timed full trace. Readiness checks: reproduce the three-typology table from memory; draft a 150-word narrative from a made-up alert; explain one sponsor-bank dependency and its control implication; and spot the tipping-off risk in a drafted customer notice.
- Reproduce the typology table from memory, then add a fourth typology of your own with signals and controls
- Draft a 150-word SAR-style narrative from a constructed alert and check it against the four-part structure
- Describe one sponsor bank or vendor dependency and who holds accountability for the outsourced control
- Identify the tipping-off risk in a sample account-closure message and rewrite it neutrally
- State your specific EDD trigger for the product you traced and the event that would start an event-driven review
References and further reading
Use these references to explore the concepts and check the latest information from the relevant organizations.