Why Most Crypto Projects Get AML/KYC Compliance Wrong Before They Launch & How To Fix It

There is a pattern we see more often than we should. A crypto founder comes to us six months after going live. They have users, transaction volume, a product that works; and a compliance program that was clearly built in a weekend from a template they found online. 

The AML policy references a jurisdiction they are not incorporated in. The KYC flow captures a passport scan but stores it in a folder with no access controls, no retention policy, and no audit trail. A bank has already sent them a derisking notice.

At that point, retrofitting a proper compliance infrastructure costs two to three times what building it correctly from the start would have. We have seen this exact situation across exchanges in Estonia, payment processors in Lithuania, and OTC desks operating out of Panama. The pattern does not change by jurisdiction. It changes only by the scale of the damage.

This article is not a general overview of what AML and KYC are. You can find that anywhere. This is what we have learned from structuring crypto compliance programs across 50+ jurisdictions; where founders consistently go wrong, what regulators are actually looking for, and how to build a program that does not fall apart the moment a correspondent bank or licensing authority examines it.

What Crypto Compliance Actually Means in 2026

Crypto compliance is not a single document or a checkbox. It is an operational architecture; the same way your exchange infrastructure is an architecture. You would not describe your trading engine as “we have servers.” You describe the matching logic, the order book design, the custody model, the settlement flow. AML/KYC compliance deserves the same level of specificity.

At its core, crypto compliance refers to the full set of regulatory obligations a digital asset business must meet to operate lawfully. This includes anti-money laundering controls, counter-terrorism financing obligations, customer due diligence procedures, transaction monitoring, suspicious activity reporting, and ongoing sanctions screening. Every one of these components interacts with the others. A gap in one creates a gap in all of them.

The regulatory frameworks governing these obligations are not uniform. MiCA (Markets in Crypto-Assets Regulation) applies across the EU and introduces a standardized CASP authorization framework with explicit AML obligations tied to the 6th Anti-Money Laundering Directive (AMLD6). FATF’s Recommendation 16; the Travel Rule; requires VASPs to transmit originator and beneficiary information for transactions above specified thresholds. In the US, FinCEN’s Bank Secrecy Act applies to money services businesses operating in the digital asset space, with separate state-level requirements layered on top.

The point is that “crypto compliance” is not one thing. It is jurisdiction-specific, model-specific, and increasingly, transaction-type-specific. What applies to a centralized exchange does not apply identically to a non-custodial wallet provider. 

What applies in Poland under MiCA does not map directly onto what a Bahrain-licensed VASP must do under the Central Bank of Bahrain’s rulebook. Getting this wrong; treating compliance as a generic concept rather than a jurisdiction-by-jurisdiction operational design; is the first mistake most projects make.

The AML/KYC Compliance Gap We See Most

We review a lot of compliance programs. The single most common gap is not a missing document. It is a missing connection between the policy and the operational reality.

Here is what that looks like in practice. A crypto exchange has an AML policy that says “the company will conduct enhanced due diligence for high-risk customers.” Fine. But when we ask: what triggers the EDD flag in your onboarding system? Who reviews EDD cases? What is the escalation path? What is your decision timeline?; the answers are either vague or do not exist outside of one person’s head. The policy says the right things. The operation does not implement any of them.

KYC and AML compliance are not the same thing, and conflating them is a separate problem. KYC or Know Your Customer is the identity verification and due diligence process you run on customers at onboarding and on an ongoing basis. AML; Anti-Money Laundering; is the broader framework of controls designed to detect, prevent, and report financial crime. KYC is one component of an AML program, not a synonym for it.

This distinction matters because regulators assess them separately. The MLRO (Money Laundering Reporting Officer) at your licensing authority is not just looking at whether you verify IDs. They are looking at your risk appetite statement, your customer risk scoring methodology, your transaction monitoring rules, your STR (Suspicious Transaction Report) filing history, your training records, and your internal audit schedule. Missing any of these is a material deficiency in the context of a licensing application or regulatory examination.

Why the Travel Rule Breaks Most Crypto Projects’ Compliance Programs

The Travel Rule is where a lot of otherwise decent compliance programs collapse. FATF’s Recommendation 16 requires VASPs to collect and transmit certain information about the originator and beneficiary of virtual asset transfers when those transfers exceed the applicable threshold; typically 1,000 EUR/USD equivalent in most FATF member jurisdictions, though some countries apply it to all transactions regardless of amount.

The practical challenge is not understanding what the Travel Rule requires. It is implementing it in an environment where not every counterparty VASP has a compliant solution. If your user sends funds to a wallet address that belongs to a non-compliant VASP; or worse, an unhosted wallet; how does your system handle that? What is your policy for transactions to unhosted wallets? Have you implemented a blockchain analytics provider? Does your Travel Rule solution integrate with your transaction monitoring system or operate as a separate, siloed tool?

We worked with a European crypto exchange that had a Travel Rule policy and a Travel Rule provider. What they did not have was any automated feed between their Travel Rule compliance tool and their risk team. 

Alerts generated by the Travel Rule system were reviewed manually, on a delay, by someone who was also responsible for KYC onboarding. When transaction volumes scaled from 50 per day to 800 per day, that manual review process broke. The exchange was processing transactions without completing required Travel Rule checks, which under their VASP registration terms was a reportable breach.

The fix required redesigning the operational workflow, not just patching the technology. That is what good AML crypto compliance looks like in practice; not just having the right tools, but having the right processes connecting them.

How Regulators Actually Examine AML Programs

Here is something that does not get said enough: regulators examining your AML compliance program are not looking for perfection. They are looking for evidence that you understand the risks you face and have made proportionate, documented decisions about how to manage them. The word “proportionate” is doing real work in that sentence.

A crypto exchange serving retail clients in 30 countries with anonymous-friendly features has a different risk profile than an OTC brokerage serving ten institutional counterparties. The regulator examining the exchange expects a correspondingly more intensive transaction monitoring ruleset, stricter thresholds for enhanced due diligence, and more frequent internal audit cycles. 

The OTC brokerage might operate with simpler controls because its risk surface is smaller and its counterparties are known entities with their own compliance obligations.

When the Central Bank of Bahrain, the FCIS in Lithuania, or the FIU in Estonia sends an examiner to review your AML program, they will ask for several things: your most recent Business Risk Assessment (BRA), your customer risk scoring model, a sample of your Enhanced Due Diligence files, your transaction monitoring alert logs with disposition records, and your STR filing history. They will also ask for your training records to confirm that your staff; not just your MLRO; received AML training within the required period.

What causes failures in these examinations is almost never that the business is actually laundering money. It is that the documentation does not exist, or the controls described in the policy cannot be evidenced in the operation. “We do that, we just do not have it written down” is the answer that ends licensing applications.

Building a Crypto Compliance Program That Holds Up

A compliance program that holds up is built in layers. Each layer depends on the one below it.

Layer 1: The Business Risk Assessment. Before you write a single policy, you need a documented assessment of the specific risks your business model creates. What markets are you serving? What payment rails are you using? What is the geographic profile of your customer base? What transaction types are permitted? A BRA that was clearly written for a different company; generic language, no reference to your actual business model; does not provide regulatory cover. It provides the appearance of one.

Layer 2: Customer Risk Scoring. Every customer you onboard should be assigned a risk rating based on documented criteria: their jurisdiction of residence, their source of funds, their PEP or sanctions status, the business they say they are conducting, and the products they are accessing. This scoring should not live in someone’s judgment. It should be encoded into your onboarding process, with documented escalation paths for high-risk ratings and mandatory EDD triggers.

Layer 3: Transaction Monitoring. Your transaction monitoring rules need to be calibrated to your business model, not copied from a generic ruleset. If you run a crypto-to-fiat on-ramp, your alerts should be configured for structuring patterns typical of on-ramp misuse. If you run a derivatives platform, the relevant typologies are different. Rules that generate 98% false positives are not protecting you; they are creating alert fatigue that causes real risk to be ignored.

Layer 4: The MLRO and the Reporting Chain. Your MLRO needs to be qualified, genuinely independent from commercial pressure, and empowered to file STRs without management overriding them. Regulators look at the seniority and qualifications of the MLRO as a direct signal of how seriously the business takes its AML obligations. In several EU jurisdictions, the MLRO must be approved by the regulator before they can take the role. Filing that name as a formality while routing all compliance decisions through a commercial team is a compliance failure, full stop.

Layer 5: Internal Audit and Review Cycles. Your compliance program needs a schedule: when does the BRA get updated? When do transaction monitoring rules get reviewed against current typologies? When does staff AML training occur? These are not optional; they are what converts a static policy document into a living compliance infrastructure.

Why Off-the-Shelf Compliance Templates Are a Liability

There is a market for generic AML policy templates. We understand why founders use them; they are cheap, they look professional, and writing one from scratch feels daunting. The problem is that a generic template is designed to describe a generic business. Your business is not generic.

A KYC and AML compliance template built for a European EMI will reference PSD2 obligations, EBA guidelines, and AMLD6 transposition. If you are an offshore VASP operating under a Seychelles or BVI regulatory framework, those references are either irrelevant or actively misleading to a compliance examiner. If your template says you are subject to an EBA threshold for transaction monitoring when no such threshold applies to your license, you have a document that misrepresents your regulatory obligations. That is not a minor problem; it is a credibility issue in front of a regulator.

We have also seen templates that reference a Customer Acceptance Policy, an EDD procedure, and a Sanctions Screening process without a single operational detail on how any of those processes work.

The policy says “the company conducts sanctions screening.” But with what tool? At what point in the onboarding flow? Against which lists; OFAC, EU consolidated list, UN Security Council, both? How are false positives handled? Who has authority to clear a match? These are operational questions. A template cannot answer them because it does not know your operation.

The MLRO Resourcing Problem in Crypto

One of the least-discussed compliance problems in the crypto industry is MLRO resourcing. The MLRO role requires someone with genuine AML expertise, the seniority to act independently, and enough time to actually manage the compliance function. In practice, a significant number of crypto businesses; especially at the startup stage; appoint an MLRO who is simultaneously the CFO, the COO, or a co-founder with no AML background.

Some jurisdictions require the MLRO to be a resident or to meet specific qualification criteria before the regulator will accept the appointment. Lithuania’s FCIS, for example, has been known to push back on MLRO nominations where the proposed individual lacks demonstrable AML experience. Estonia’s FIU takes a similar position. When a licensing application stalls at the MLRO review stage, the delay is typically measured in months, not weeks.

The solution is either investing in a qualified MLRO hire; someone with ACAMS certification or equivalent AML credentials and hands-on experience in digital asset compliance; or sourcing one through a specialist firm. We assist clients with MLRO sourcing as part of our compliance infrastructure buildout, specifically because the quality of this appointment affects licensing timelines and ongoing regulatory relationships more than most founders realize.

What a Proper AML/KYC Review Actually Looks Like

When we assess a client’s existing compliance program before a licensing application, we are not running a quick checklist. We are examining whether the program reflects the actual risk profile of the business and whether every control described in the documentation can be evidenced in the operation.

The review covers: the BRA and whether it is current and specific; the customer risk scoring model and whether it aligns with the actual customer base; the transaction monitoring setup and whether the rules are calibrated to the business; the EDD file sample and whether the documentation quality is defensible; the sanctions screening setup and whether the process is genuinely real-time or running on a delay; the STR filing history and whether the volume and pattern of filings is consistent with the business’s risk profile; the MLRO’s qualifications and independence; the training records; and the internal audit schedule.

In a recent review of a Central European crypto brokerage preparing for a MiCA CASP authorization, we identified that their transaction monitoring system had not had its alert thresholds reviewed in 14 months. 

During that period, the business had expanded from serving retail clients in three countries to retail and institutional clients across twelve. The original alert thresholds; set for a small, homogenous retail book; were generating thousands of alerts per month on legitimate institutional transactions, while simultaneously missing several typologies relevant to the new retail markets they had entered. 

The fix required a full rule review and recalibration with a specialist transaction monitoring provider. That process took eight weeks and pushed back the licensing timeline accordingly.

The lesson is not that the business was doing something wrong. It is that compliance programs need to scale with the business, not sit static while the business grows around them.

Conclusion

Crypto compliance is not a document you file and forget. It is an operational infrastructure that needs to match your business model, your regulatory environment, and your risk profile; and it needs to stay matched as all three evolve. 

The founders who treat AML KYC compliance as a launch-day task rather than an ongoing operational discipline are the ones who end up rebuilding it under regulatory pressure, at significant cost, and with a compliance history that follows them into future licensing applications.

At LegalBison, our compliance team; AML compliance officers, qualified attorneys, and licensing specialists; designs compliance programs that are built for the actual business, not the generic version of it. 

We work across 50+ jurisdictions, which means we understand not just what good compliance looks like in theory, but what a specific regulator in a specific market will actually scrutinize when they examine it. If you are building a regulated crypto business and want a compliance infrastructure that holds up when it matters, that is exactly what we do.