Launching a Crypto Startup? AML Checklist for Exchanges, Wallets, Payment Apps, and DeFi Products

The phrase “crypto startup” tells you almost nothing about which AML obligations apply. A four-person team building a custodial swap interface, a payment processor settling stablecoin invoices for merchants, a token issuer running a redemption desk, and a non-custodial DEX front end all describe themselves the same way at the pitch deck stage — and none of them will end up with the same compliance scope. The relevant question what its product actually does with user funds.

This is the position FinCEN took explicitly in its May 2019 Guidance on Convertible Virtual Currencies, which states that AML obligations attach to the activity a person or business conducts, not to the label that business uses to describe itself. That means a founder cannot decide AML scope by picking a category. The scope is determined by whether the product exchanges, holds, transfers, routes, issues, or only provides access to crypto activity — and by where the customers actually sit.

This article is built around that decision: identify the operating model, isolate the AML questions specific to that model, and assemble a pre-launch checklist that matches the markets the business intends to serve. Deeper regional and operational guides are linked where appropriate, but the goal here is to get the foundational map right before any of those become useful.

Start With Your Crypto Business Model, Not a Generic AML Checklist

Before reading any framework, founders should resolve a more basic question: which kind of operation are we, really? A product called a “wallet” can be custodial or non-custodial, with very different obligations. A product called a “DeFi App” can range from a thin contract-only interface to an operator-controlled service layer that charges fees, manages liquidity, or gates access. A “Payment Platform” can mean either a single merchant accepting crypto for its own goods or an intermediary handling funds for many merchants — two completely different compliance pictures.

The table below maps common startup descriptions to the AML model they should treat as their starting point.

This table is only a starting point. The final regulatory classification of any product depends on its detailed flow of funds and on the markets it serves. A startup that processes deposits in the US, runs swaps for EU customers, and pays out to merchants in third countries can sit inside more than one of these categories at once, and may need to plan for the strictest applicable obligations rather than the easiest.

Note: None of this information should be considered as legal advice. While we’ve done our best to ensure this information is accurate at the time of publication, laws and practices may change, so please double-check it.  

AML Checklist by Crypto Startup Type

The point of this section is to give each startup a short, model-specific checklist rather than a uniform list. Each subsection describes the model, names the central AML question for it, and lists what should be assessed before serving real users.

Crypto Exchange or Swap Platform

This category covers fiat-to-crypto exchanges, crypto-to-crypto platforms, broker-style products, swap services, and OTC-oriented desks. The structural common feature is that the platform holds, intermediates, or executes asset movements on behalf of customers — even briefly — rather than simply publishing software they use to trade with each other.

The central AML question is direct: does the startup exchange assets for customers, accept customer funds, or organize trades between counterparties? If the answer to any of these is yes, the platform should plan for a full customer-and-transaction control set, not a partial one. The pre-launch assessment should cover:

An exchange operator has to think simultaneously about who the customer is and what the customer is doing — the two questions cannot be split. For a focused explanation of how identity verification and transaction-level screening complement each other, see our explainer KYC vs KYT Explained: Key Differences for Crypto Compliance.

Custodial Wallet or Crypto Transfer App

This section applies to products that control customer assets, hold private keys on a user’s behalf, or execute transfers between accounts. A simple non-custodial wallet interface, where the user holds their own keys and the company never touches the funds, sits in a different category and is addressed later.

The defining feature is custody and movement. The AML question is whether the company controls or can move customer funds — not whether it markets itself as a “wallet.” If users deposit, hold, send, or receive through the product, the company is in the path of those flows and the controls should reflect that. The pre-launch checklist for this model:

A useful takeaway: for a custodial or transfer product, AML risk does not stop at onboarding. It re-appears every time funds move. A clean onboarding process does not protect a platform whose later transfer activity is not monitored, and a strong monitoring system cannot compensate for missing identity records on the customer behind the wallet.

Crypto Payment Gateway or Merchant Payment Product

This is one of the most misclassified models in early-stage crypto. Founders sometimes describe their product as “just accepting crypto payments,” without separating two structurally different setups:

Anything in the second bucket should expect to operate as a regulated payment intermediary in most major markets — with onboarding and screening obligations not only for the end customer making a payment, but also for the merchants on whose behalf the funds are being received and disbursed. The pre-launch checklist:

The business case here is not abstract. A payment startup that builds a payout flow without front-loaded merchant due diligence is building exactly the kind of channel that a partner bank later refuses to support — or worse, that a regulator looks at retroactively.

Token or Stablecoin Startup

This block is intentionally short and cautious. The most common error here is the assumption that any project “with a token” needs the same AML setup as an exchange. That conclusion does not follow automatically. The relevant question is what services the project provides around the token, not the existence of the token itself.

In practical terms, the distinction looks like this. A team that issues a token and does nothing else — no redemption desk, no custodial wallet, no transfer service, no distribution interface that takes user funds — is in a different position from a team that issues a token and also runs a stablecoin redemption process, holds reserves, or operates a customer-facing distribution channel. The latter starts to look operationally similar to a custodial or exchange model on top of issuance.

The pre-launch checklist:

Controls should follow the actual model. A project with only a token contract on-chain should not be forced into the same workflow as a project that takes in fiat, holds reserves, and processes redemptions for retail users.

DeFi or Non-Custodial Product

The opposite simplification appears here: “we are non-custodial, so AML does not apply.” That statement is too strong. Non-custodial architecture removes some of the levers a regulator can pull, but it does not automatically remove every obligation, particularly when there is an identifiable team operating the front end, collecting fees, controlling routing, or restricting access. The relevant question, well before launch, is what the team actually controls. In practical terms, founders should document each of the following:

The pre-launch checklist follows from those answers:

A DeFi or non-custodial startup should not copy the AML setup of a centralized exchange by default, but it should also not assume the absence of custody removes the question entirely. For a deeper review of how DEXs, bridges, smart contracts, and non-custodial wallets fit into the broader picture, see our guide to AML Risks and Compliance Controls for DeFi Products.

The Pre-Launch AML Checklist Every Crypto Startup Should Work Through

After identifying the operating model, every crypto startup has to walk through a more universal sequence. The order matters: each step depends on the previous one, and trying to skip directly to tools or templates without doing the earlier work tends to produce a setup that does not match the product.

Step 1: Map the Product Activities

The first artifact every founder should produce is a plain-language description of the product’s actual flow of funds — not the marketing description. It should answer who sends assets, who receives them, whether the company controls those funds or the keys behind them, whether the company performs exchange, custody, transfer, payment routing, or redemption, and where customers, merchants, and counterparties show up in the picture.

This is what every later step refers back to. Without a clean product-flow document, customer controls and transaction controls are designed against a guess. With it, compliance assessment becomes a relatively short exercise of comparing flows to obligations.

Step 2: Identify the Markets and Regulatory Path

The same product can require very different actions depending on where it is registered and which users it serves. Before launch, the team should clarify the country of incorporation, the target customer markets, whether the product will serve EU, UK, US, Canadian, or other users, and whether authorization, registration, or a local review is needed before going live.

This step is what determines which regional rulebook applies — and there is rarely one. Most crypto startups operate across borders by default and have to plan for a layered answer.

Explore Requirements by Market:

– European Union – MiCA License Explained: CASP Requirements, Authorization Process, and EU Passporting.

– United States – Crypto Regulations in the US 2025: Complete AML & Compliance Guide.

– United Kingdom – Crypto Regulations in the UK 2025 — Post‑Brexit Framework for Digital Assets, AML & FCA Licensing.

– Canada – Crypto Regulation in Canada 🇨🇦

Step 3: Assign Ownership of AML Decisions

Even very small teams need to name the person or persons responsible for approving AML procedures, reviewing risk decisions, handling escalations, communicating with partners or regulators, and updating controls as the product flow evolves. This does not require an enterprise compliance department on day one, but it does require that AML decisions stop floating informally between a founder and a developer.

The documented version of this step is what banking partners, payment partners, and regulators look for first. They want to see a named, accountable owner of the program — someone whose calendar reflects the role and whose authority is recognized inside the company.

Step 4: Prepare the Required AML Documentation

Documentation is where the operating model becomes a reviewable artefact. Depending on the model and the markets served, a startup may need:

In practical terms, a policy that does not reflect the real product flow is worse than no policy at all — it gives partners and regulators a written admission of mismatch.

Step 5: Determine Which Customer Controls Apply

Customer-side controls vary by model:

The available controls include identity verification, business verification, beneficial owner checks, sanctions and PEP screening, and source-of-funds review where the risk model requires it. In practical terms, the team’s job is not to apply every control but to match a defensible subset to the product.

Step 6: Determine Which Transaction Controls Apply

Transaction controls become critical for a specific set of models:

For each of these, the team needs to decide which addresses or transactions are checked, at what point (before acceptance, before payout, after transfer, or continuously), which risk categories require review or restriction, how the result is linked back to a customer or merchant or account, and how decisions and supporting evidence are stored. In practical terms, this is where many startups start with manual spot checks and reach a wall as volumes grow.

Step 7: Assess Travel Rule, Reporting and Recordkeeping Needs

Travel Rule obligations sit specifically with businesses performing transfers or operating qualifying crypto-asset services. In practical terms, a startup in this position should determine the applicability of the rule for its routes, define which records are kept on customers, merchants, transactions, risk decisions and escalations, and assess the reporting workflow that its regulatory status implies.

For EU-facing operations, the starting point is our guide EU Crypto Travel Rule: How the Regulation Applies to Crypto-Asset Service Providers (CASPs); for US-facing operations, see US Crypto Travel Rule: FinCEN Requirements for Crypto Businesses. Neither obligation applies uniformly to every transaction of every business — the route, the thresholds, and the counterparties matter — which is why the assessment cannot be skipped.

Step 8: Test the Setup Before Launch and Review It as the Product Changes

AML preparation does not end when a policy document is signed. Before launch, the team should confirm that chosen controls correspond to actual user and asset flows, that responsible persons know how decisions are handled in practice, and that records can be produced for a bank, partner, auditor, or regulator without an emergency.

In practical terms, controls should also be re-reviewed whenever the product changes in a way that affects compliance exposure: adding a new chain or token, opening a new market, introducing a custody feature, adding fiat rails, launching a payout flow, or simply experiencing a meaningful jump in transaction volume. Audit or readiness reviews become particularly relevant around licensing, bank onboarding, partnership due diligence, significant product changes, and expansion into a new market. For a step-by-step view of what such a review looks like, see our guide on How to Prepare for a Crypto Compliance Audit.

What Should Be Ready Before Your Crypto Startup Goes Live?

Before launching, a crypto startup does not necessarily need every control listed in this guide. It does need a documented answer to which controls apply to its product, its customers, its asset flows, and the markets where it plans to operate. The readiness summary below pulls those answers together.

The goal is not to copy the compliance setup of another crypto company. It is to launch with a documented understanding of what your own product does, where AML exposure may arise, and which controls must exist before real users and real funds move through the business.

Conclusion

A crypto startup cannot resolve AML preparation by buying a template policy or licensing a single tool. The first task is to decide whether the product operates as an exchange, a custodial wallet, a payment intermediary, an issuer or service provider, or a non-custodial or DeFi layer — and then to align activities, markets, documents, and controls to that picture rather than to an industry-wide average.

Once the model and markets are clear, the next step is straightforward and specific to the business: a regional compliance assessment for the relevant jurisdictions, the preparation of procedures that match the documented flow, or the implementation of the particular customer and transaction controls the model actually requires. The earlier they are mapped to the real product, the less rework the team faces after launch.

FAQ: AML Setup for a Crypto Startup Before Launch