You don’t need a 200-page compliance manual to get started. You do need the right documents though. That’s the bit founders miss.
I’ve seen early-stage fintech and crypto teams spend weeks polishing pitch decks, product flows, even office lease files, then send over a two-page AML policy copied from somewhere random online. Banks hate that. Regulators hate it more. And honestly, it usually tells them you don’t really understand your own risk.
Your first AML programme should be simple, usable, and tied to what your business actually does. If you’re onboarding UK and EEA retail clients into a crypto app, that looks different from a B2B payments company handling merchant settlement, and very different again from an online casino taking deposits from multiple regions.
So let’s make this practical. These are the six documents almost every regulator, banking partner, or serious due diligence team will expect to see early on.
1. Business-wide risk assessment
This is the foundation. Everything else hangs off it.
Your business-wide risk assessment explains where your money laundering and sanctions exposure actually comes from. Products. Customer types. Countries. Delivery channels. Transaction patterns. Source of funds issues. Use of agents or introducers. Crypto rails. Card acquiring. Nested payment flows. All of it.
Don’t make it abstract. That is the trap.
If you run a fiat-crypto exchange, say whether you deal with self-hosted wallets, whether you allow stablecoin deposits, whether you support cross-border transfers, and which jurisdictions you block. If you’re a gambling operator, spell out bonus abuse risk, mule account behaviour, prepaid card use, and customer spend patterns that don’t fit normal gameplay.
A decent risk assessment usually covers:
- customer risk – retail, VIP, corporate, high-net-worth, PEP exposure, third-party funding
- geographic risk – customer residence, payment origin, IP location, sanctioned or high-risk regions
- product risk – transfers, custody, wallets, fast deposits, anonymous instruments, high-value withdrawals
- channel risk – non-face-to-face onboarding, affiliates, API onboarding, introducers
- control effectiveness – what reduces the risk and where gaps still sit
And yes, regulators will expect this to match reality. If your assessment says you don’t touch high-risk countries but your PSP statements show traffic from them, you’ve got a problem. A silly one, too.
2. AML and CTF policy
This is the main rulebook. The thing people usually call “the AML policy,” even though that phrase gets used for almost everything.
Your policy should explain how your firm prevents, detects, and escalates suspicious activity. Not in theory. In your operation.
That means covering customer due diligence, enhanced due diligence, ongoing monitoring, sanctions screening, suspicious activity reporting, record keeping, internal reporting lines, training, governance, and who signs off what. If you’re applying for a licence or registration, this document often gets read front to back. Slowly.
Short is fine. Vague is not.
A good policy says things like:
– We screen all customers at onboarding and on an ongoing basis against sanctions, PEP, and adverse media datasets.
– We apply enhanced due diligence to higher-risk customers, including customers connected to high-risk jurisdictions, complex corporate structures, or unusual funding patterns.
– We review transaction activity against expected behaviour and escalate red flags to the MLRO.
That’s much better than filler language about “maintaining the highest standards” and other glossy nonsense.
If you haven’t appointed an internal compliance lead yet, this is exactly where founders start looking at outsourced AML officer and compliance support. For a lean startup, that’s often the sensible move.
3. Customer due diligence and onboarding procedure
This one should sit next to the AML policy, but it deserves its own document because the detail matters.
Your onboarding procedure needs to show what you collect, how you verify it, when you ask for more, who reviews exceptions, and what makes you reject an applicant. Think operational steps, not grand principles.
For example, if you’re a payments startup onboarding SME merchants, your procedure might say you collect incorporation documents, UBO information, director IDs, website review findings, expected monthly volume, settlement geographies, and details of the business model. If the merchant is a crypto OTC desk or gambling affiliate, maybe you trigger enhanced review straight away. Makes sense.
For corporate clients, beneficial ownership is usually where things get messy. Trusts, layered holdings, nominee arrangements, offshore entities. You need a clear rule for how far up the chain you go, what evidence you accept, and when independent verification is needed.
And don’t forget event-driven reviews. New shareholder? New market launch? Sudden jump from EUR 40,000 monthly turnover to EUR 700,000? Your file should not just sit there gathering dust.
If you’re still building the model behind your onboarding and monitoring decisions, this guide on customer risk scoring is worth a read. It saves alot of rework later.
4. Suspicious activity reporting and escalation procedure
This is where firms get exposed fast, because everyone says they will report suspicious activity, but very few have a clean internal process.
You need a written escalation procedure showing:
- how staff identify unusual activity
- who they report it to internally
- how the MLRO or responsible officer documents the review
- how external reporting decisions are made under the laws of the relevant jurisdiction
That’s it. Simple structure. But it has to be real.
Let’s say you’re a crypto broker and a customer starts sending in funds from multiple third parties, then asks for rapid off-platform withdrawals to newly added wallet addresses. Or you’re running a gaming platform and a player deposits heavily, barely plays, then withdraws to a different payment method. Staff need to know what happens next. Who reviews the case? What gets frozen, if anything? What notes go into the case file? How long do you keep the records? Check current local requirements for the reporting thresholds and filing mechanics – those vary, and getting them wrong is avoidable.
No procedure means panic. Panic creates bad records. Bad records are a gift to regulators.
5. Sanctions screening and transaction monitoring procedure
People sometimes lump these together, sometimes split them. For an early AML pack, having one document that explains both can work if it’s properly drafted.
You need to show what screening happens at onboarding, what happens after onboarding, what lists or tools you use, how alerts are handled, and how transaction monitoring scenarios fit your business. Not somebody else’s template. Yours.
If you’re a remittance or EMI-style business, maybe your scenarios focus on rapid movement of funds, pass-through accounts, unusual sender-recipient patterns, and geography mismatches. For crypto, add wallet exposure, mixers, darknet indicators, chain-hopping, and unusual use of stablecoins. For gambling, look at deposit-withdrawal behaviour, chip dumping, collusive patterns, and source-of-funds triggers for high spenders.
And please, don’t write “all alerts are reviewed promptly” and leave it there. Promptly by whom? Within what internal SLA? What gets auto-closed? What requires manual review? I’ve seen this kill a banking application because the document looked polished but said almost nothing.
If your product has any payments complexity at all – multiple PSPs, collection accounts, merchant settlement, crypto-to-fiat ramps – sort the infrastructure side early too. It ties straight back into monitoring design. That’s where payment strategy and banking access planning becomes more than a banking issue.
6. AML governance, training, and MLRO framework
This is the bit founders leave too late. Honestly, most do.
Regulators don’t just want policies. They want ownership. Who is responsible for AML day to day? Who receives internal reports? Who approves higher-risk clients? Who signs off annual reviews? Who trains staff? Who reports to the board or founder group?
Your governance document can be short, but it should clearly set out:
– roles and responsibilities
– reporting lines
– frequency of AML reviews and policy updates
– training requirements by team or function
– recordkeeping for decisions, breaches, and escalations
If you’re pre-revenue with six employees, this does not need a massive committee structure. That would be overkill. But it does need names, accountability, and a believable setup. For many smaller firms, especially before licensing is finalised, outsourcing the MLRO function is cleaner than hiring too early. This article on what an MLRO actually does lays it out well.
What founders usually get wrong
A few repeat mistakes show up again and again.
First, the documents don’t match the business model. A B2C app submits a policy written for private wealth management. A gaming operator uses a crypto exchange template. Weirdly common.
Second, the controls sound expensive and sophisticated but aren’t actually built. Daily transaction monitoring reviews, annual independent audits, full adverse media analysis on every low-risk customer. Maybe. But can your tiny team really do that every day from day one? If not, rewrite it before the regulator asks.
Third, nobody links AML design to licensing and structure. If you’re choosing where to set up, who the contracting entity is, which markets you target, and how money flows between group companies, your compliance file should reflect that. If you’re still at that stage, sorting the legal setup through company formation across multiple jurisdictions usually makes the AML drafting much cleaner because the operating model is finally nailed down.
Start with something usable
You are not trying to impress anyone with legal poetry. You’re trying to show that your business understands its risk and has a workable system for handling it.
So start with the six documents above. Keep them aligned with your actual customer journey, payments flow, product set, and team size. Review them when the business changes. And don’t fake maturity you don’t have yet. Regulators and banks can smell that a mile off.
Simple. Specific. True to the business. That’s usually enough to get your first AML programme into decent shape.