How Regulators Audit Crypto Exchanges: What They Check and How to Prepare

Table of Contents

• Why Most Exchanges Fail Their First Audit
• The Four Types of Regulatory Audit
• AML/KYC Controls: The Section That Sinks Most Exchanges
• Reserve Verification and Proof of Solvency
• Cybersecurity and Penetration Testing
• Operational Controls and Governance
• Record-Keeping: The Boring Part That Matters Most
• What Happens When You Fail
• The Pre-Audit Checklist That Actually Works
• How Your Tech Stack Makes or Breaks the Audit

Why Most Exchanges Fail Their First Audit

I’m going to tell you something that should scare you a little: roughly 60% of crypto exchanges that undergo their first formal regulatory audit receive material findings. Not minor observations. Material findings — the kind that can delay your license, restrict your operations, or trigger enforcement action.

We’ve watched it happen over and over. A team builds a solid trading platform, gets the matching engine humming, launches marketing, even signs up thousands of users. Then the regulator shows up for the first inspection and everything grinds to a halt because the exchange can’t produce basic transaction records from six months ago, or the AML policy on file doesn’t match what the system actually does.

The problem isn’t usually technical competence. It’s preparation. Most exchange operators treat compliance documentation as a checkbox exercise — something you write once to get through licensing and then forget about. Regulators treat it as a living system that should reflect your actual operations at any given moment.

Here’s the gap: your license application describes what you plan to do. The audit checks what you actually did. If those two things don’t match, you’ve got problems.

The good news? Every common audit failure is preventable. You just need to know what they’re looking for.

The Four Types of Regulatory Audit

Not all audits are the same, and knowing which one you’re facing changes how you prepare.

1. Pre-license inspection

Before some regulators grant your license, they send inspectors to verify your claims. VARA in Dubai does on-site assessments before issuing a full license. MAS in Singapore conducts technology risk assessments. The EU’s national competent authorities under MiCA are increasingly doing pre-authorization site visits.

What they check: Does your operation match what you described in your application? Do the people you named actually work here? Is the technology stack real or vaporware?

2. Routine supervisory audit

Once you’re licensed, most regulators schedule periodic audits — typically annually or every 18 months. The AMF in France, BaFin in Germany, and MAS all conduct routine supervisory reviews.

What they check: Ongoing compliance with license conditions. Have you maintained the controls you committed to? Are your AML reports filed on time? Have you reported any incidents properly?

3. Thematic review

Regulators sometimes pick a specific topic and audit multiple exchanges on that theme. In late 2025, ESMA ran a thematic review on crypto exchanges’ customer asset segregation practices across six EU countries. The FCA did something similar with financial promotions.

What they check: One specific area in depth. You might ace everything else and still get hammered on the one topic they decided to examine under a microscope.

4. For-cause investigation

Something triggered suspicion — a customer complaint, a suspicious activity report from a bank, unusual trading patterns flagged by market surveillance, or a whistleblower. The regulator shows up with specific questions and a much less friendly disposition.

What they check: Whatever prompted the investigation. These audits are targeted, fast, and come with a much higher probability of enforcement action.

For a broader view of what each jurisdiction requires for licensing, see our crypto exchange license guide.

AML/KYC Controls: The Section That Sinks Most Exchanges

If your exchange is going to fail an audit, it’s probably going to fail here. AML/KYC is the area where regulators have the most experience, the clearest expectations, and the least patience for gaps.

Here’s what auditors actually check:

Customer identification and verification

They’ll pull a sample of customer accounts — usually 20-50 from different risk categories — and trace each one through your onboarding process. Did you collect the required documents? Did you verify them? Did your KYC system flag any anomalies? How long did verification take? Did anyone start trading before verification was complete?

The killer question: “Show me a customer who was rejected during onboarding and explain why.” If you can’t produce rejected cases, auditors assume you’re approving everyone — which means your controls aren’t working.

Transaction monitoring

Auditors want to see your transaction monitoring rules and then test them. They’ll ask: “What triggers a suspicious activity alert?” Then they’ll look at your alert log. Then they’ll cross-reference your alerts against actual suspicious patterns in your data.

Common failure: having rules on paper that don’t match what the system does. If your policy says you monitor for structuring (breaking up large transactions into smaller ones to avoid thresholds), but your monitoring system doesn’t actually have a structuring rule, that’s a material finding.

SAR filing history

How many Suspicious Activity Reports have you filed? When? What triggered them? What was the outcome?

Zero SARs is a red flag. It doesn’t mean you’re clean — it means you’re not looking. Every exchange with meaningful volume will encounter suspicious activity. Auditors know this. If you claim you’ve never seen anything suspicious, they’ll dig harder.

Enhanced due diligence (EDD)

High-risk customers — PEPs (politically exposed persons), customers from high-risk jurisdictions, large-volume traders — should have additional scrutiny documented. Auditors will pull your high-risk customer list and check whether EDD was actually performed.

We’ve covered the full picture of what KYC and AML compliance looks like in practice in our KYC compliance guide. Read it before your audit, not after.

Sanctions screening

Are you screening against OFAC, EU, and UN sanctions lists? How often do you update your lists? What happens when there’s a match? Show me a case where you got a match and what you did about it.

Sanctions screening needs to be continuous, not just at onboarding. If a customer gets added to a sanctions list after they’ve already been verified, your system needs to catch that. Your compliance module should run batch rescreening at least daily against updated lists.

Reserve Verification and Proof of Solvency

Post-FTX, regulators care deeply about whether exchanges actually hold the assets they claim to hold. Several jurisdictions now require periodic proof-of-reserves attestations.

What auditors check:

• Asset segregation. Are customer funds held separately from operational funds? Can you demonstrate clear segregation at the wallet level? Most regulators want to see separate hot and cold wallets for customer assets versus company assets.
• 1:1 backing. Do your total customer liabilities (what you owe users) match your total assets (what you actually hold)? Auditors will compare your internal ledger against on-chain balances.
• Third-party attestation. Some jurisdictions require proof-of-reserves audits by independent accounting firms. Even where it’s not required, having one puts you ahead. Firms like Armanino and Mazars (before they stopped) have done these for major exchanges.
• Cold storage verification. Auditors may ask you to sign a message from your cold storage wallets to prove you control them. Have a procedure ready for this. You don’t want to scramble to find hardware wallet keys while regulators are sitting in your office.

The common mistake:

Using customer deposits as working capital. Even temporarily. Even if you intend to pay it back. If auditors find that customer BTC was moved to an exchange’s operational wallet — for any reason — that’s a material finding and potentially criminal in some jurisdictions.

Cybersecurity and Penetration Testing

Regulators increasingly expect exchanges to maintain security programs that rival traditional financial institutions. VARA’s technology assessment is particularly thorough. MiCA requires CASPs to have “sound ICT risk management.”

What auditors want to see:

• Penetration test reports. When was your last pentest? Who did it? What did they find? What did you fix? Annual pentests are the minimum expectation. Some regulators want to see quarterly vulnerability scans on top of annual pentests.
• Incident response plan. Not just a document — a tested plan. Auditors may ask about your last tabletop exercise or even your last real incident. “We haven’t had any incidents” isn’t reassuring — it suggests you aren’t detecting them.
• Access controls. Who has access to production systems? How is access granted and revoked? Is there multi-factor authentication? Are there audit logs of administrative actions?
• Key management. How are private keys generated, stored, rotated, and recovered? Multi-signature requirements? Hardware security module (HSM) usage?

Your security architecture should produce audit-ready documentation. If it doesn’t, you’re going to spend weeks assembling it manually before every audit.

For the technical details of what a strong security posture looks like, our security architecture deep dive covers the specifics.

The audit trail question:

Every action on your platform — administrative or otherwise — should be logged. Auditors will ask to see logs for specific events: “Show me the access log for your hot wallet for the last 30 days.” “Show me every admin action on this user’s account.” “Show me the change log for your fee configuration.”

If you can’t produce these logs, the auditor doesn’t know whether nothing happened or whether you just don’t have records of what happened. They’ll assume the worst.

Your admin dashboard is the front line here. It needs to log every action with timestamps, user identities, IP addresses, and the before/after state of any changes.

Operational Controls and Governance

Regulators want to see that your exchange is run by competent people with clear responsibilities and oversight.

Board and management structure:

• Who is ultimately responsible for compliance? Name them.
• Does your board (or equivalent oversight body) receive regular compliance reports?
• Is there a documented escalation path for compliance issues?
• Has anyone in management been subject to regulatory action before? (They’ll check.)

Policies and procedures:

Auditors will request your full policy suite. At minimum:

• AML/CFT policy
• KYC procedures
• Risk management framework
• Incident response policy
• Business continuity / disaster recovery plan
• Complaints handling procedure
• Conflict of interest policy
• Market abuse / surveillance policy
• Data protection / privacy policy

Each policy should have a version number, an owner, a last-review date, and evidence of staff training. Policies that were written two years ago and never updated are a red flag.

Change management:

Did you launch a new product or feature since your last audit? Auditors want to see that you assessed the compliance implications before launch, not after. “We added margin trading six months ago” followed by silence on the compliance review is a finding.

Record-Keeping: The Boring Part That Matters Most

Record-keeping gets the least attention during exchange buildout and causes the most problems during audits. Here’s what you need to retain — and for how long.

Transaction records: Every trade, deposit, withdrawal, and internal transfer. Most jurisdictions require 5-7 years of retention. MiCA specifies 5 years. VARA wants 8 years. MAS requires 5 years after the business relationship ends.

KYC records: All identity documents, verification results, EDD files, and ongoing monitoring records. Same retention periods as transaction records.

Communication records: Customer support interactions, internal compliance communications, and any communications related to suspicious activity investigations. Yes, this means you need to archive your support tickets and internal chat logs.

System logs: Access logs, error logs, change logs, and security event logs. At minimum 2 years, but 5 years is safer.

The format matters. Records need to be searchable and producible within a reasonable timeframe. “It’s all in our database but we need two weeks to extract it” is not acceptable. Auditors expect you to produce specific records within 24-48 hours of a request.

Build your record retention policy into your system architecture from day one. Retroactively implementing 5-year retention after you’ve already been purging data annually is… not a great conversation to have with a regulator.

What Happens When You Fail

Audit outcomes typically fall into four categories:

1. Clean opinion with observations. You passed. The auditor noted some areas for improvement, but nothing requiring immediate action. Celebrate quietly and fix the observations before the next audit.

2. Qualified opinion with material findings. You mostly passed, but there are specific areas where you don’t meet requirements. You’ll get a remediation timeline — usually 30-90 days for each finding. Meet the timeline or face consequences.

3. Adverse opinion. You failed. Multiple material findings, possibly systemic issues. The regulator may restrict your operations (no new customer onboarding, reduced trading volumes) until remediation is complete and verified. You’ll likely face an accelerated follow-up audit.

4. License revocation or suspension. The worst case. Your findings are so severe that the regulator questions whether you should be operating. In extreme cases, particularly where customer assets are at risk, regulators can force an immediate suspension.

The trajectory matters too. If your first audit has 3 findings and your second audit has 5 findings, that’s a bad trend. Regulators want to see improvement over time. Getting worse suggests management isn’t taking compliance seriously.

The Pre-Audit Checklist That Actually Works

Six weeks before your audit, start here:

Week 6-5: Documentation review

• Pull every policy document. Check version numbers and last-review dates
• Update any policy that’s more than 12 months old
• Verify that policies match actual system behavior (test this — don’t just read the document)
• Ensure all required policies exist (see the list in Operational Controls above)

Week 4-3: System testing

• Run your own transaction monitoring rules against sample data. Do they fire correctly?
• Pull a random sample of 30 customer accounts and trace them through KYC
• Check that your SAR filing log is complete and current
• Verify that you can produce transaction records for any date range within 24 hours
• Test your admin dashboard audit trail — can you show every admin action for the last 6 months?

Week 2-1: People preparation

• Brief your compliance officer on likely questions and evidence requirements
• Brief your CTO/technical lead on cybersecurity questions they may face
• Ensure key personnel are available during the audit window (no vacations)
• Prepare a data room (physical or virtual) with all documentation organized by topic

Day of:

• Have a designated point of contact who manages the auditors’ requests
• Respond to data requests promptly. Speed signals competence
• If you don’t know the answer to a question, say so. Don’t guess. “We’ll get back to you by end of day” is better than a wrong answer
• Take notes on everything the auditors ask. Their questions tell you what they’re focused on

How Your Tech Stack Makes or Breaks the Audit

Here’s something that doesn’t get said enough: your exchange software is the single biggest factor in whether you pass or fail an audit. Not your compliance team (though they matter). Not your policies (though those matter too). Your technology.

Why? Because auditors don’t care what your policy says. They care what your system does. And they verify by pulling data from your system.

What your tech stack needs to support:

• Built-in audit trails. Every user action, admin action, system event, and configuration change should be logged immutably. If your exchange software doesn’t log admin actions, you can’t prove governance.
• On-demand reporting. Auditors will ask for transaction reports, KYC status reports, SAR filing histories, and system access logs. If generating a report takes days of engineering work, you’re in trouble. Good exchange software ships with compliance reporting built in.
• KYC/AML integration. Your identity verification, transaction monitoring, and sanctions screening should be integrated into the platform — not bolted on as an afterthought. Auditors check integration points for gaps.
• Asset segregation at the infrastructure level. Your wallet architecture should enforce customer/operational fund segregation by design, not by policy. If a human error could accidentally commingle funds, that’s a design flaw.
• Configurable compliance rules. Different jurisdictions have different thresholds, reporting requirements, and monitoring expectations. Your system should let you configure these without custom development.

The exchanges that breeze through audits are the ones whose tech stack generates compliance evidence as a byproduct of normal operations. If your team has to manually compile audit evidence, something is wrong with your architecture.

---

Sources & Further Reading

• FATF Guidance for a Risk-Based Approach to Virtual Assets — Financial Action Task Force
• MiCA Regulation — Title V: CASP Obligations — European Parliament
• VARA Compliance and Risk Management Rulebook — Dubai Virtual Assets Regulatory Authority
• MAS Technology Risk Management Guidelines — Monetary Authority of Singapore
• IOSCO Report on Issues, Risks and Regulatory Considerations Relating to Crypto-Asset Trading Platforms — IOSCO