Crypto exchange security: what regulators and banking partners actually expect

This guide exists because of a pattern we kept meeting: exchanges that treat compliance and security as two separate projects, bought from two vendors who never speak. The result is controls that pass individually and fail together. Having sat on both sides — as MLRO reviewing files and as the engineering team building an exchange from the first commit — here's the whole stack in one place.

Why banks ask harder questions than regulators

Regulation gives you the floor: registration or licensing as a VASP/MSB depending on jurisdiction, AML program requirements, reporting obligations. But the test most platforms fail isn't the regulator's — it's the bank's. A banking partner taking on a crypto client inherits its risk, so their due diligence goes deeper than the statute: they want to see the program working, not just written. De-risking is real, and the platforms that keep accounts are the ones that can produce evidence on request, quickly, in the format compliance officers expect.

Layer 1 — KYC and onboarding: identity as architecture

Onboarding is where compliance and engineering must be one team, because every shortcut here compounds downstream. A defensible 2026 onboarding flow includes: identity verification (document + liveness for individuals; registry extracts, ownership structure, and UBO identification for entities), screening at onboarding against sanctions lists (OFAC and applicable international lists), PEP status, and adverse media, and risk scoring that assigns each customer a tier driving everything after — limits, review frequency, enhanced due diligence triggers.

The engineering detail that separates real programs from theater: screening isn't a one-time gate. Lists change daily; your customer base must be re-screened continuously, and the match-handling workflow (fuzzy matches, false positives, escalation, documented dispositions) needs to be a designed system, not an inbox. When we build KYC/AML tooling, the disposition audit trail is a first-class feature — because that's the first thing a reviewer samples.

Layer 2 — Transaction monitoring and the Travel Rule

Monitoring is where most programs are weakest, because it's where volume meets nuance. A working setup combines rule-based detection (structuring patterns, velocity anomalies, high-risk jurisdiction exposure, mixer and darknet-market proximity via chain analytics) with risk-based review queues sized so analysts actually clear them — an alert backlog is a regulatory finding waiting to be written. Every alert needs a documented disposition; every disposition needs to be retrievable years later.

Then there's the FATF Travel Rule (Recommendation 16): transmitting originator and beneficiary information alongside transfers between VASPs. In practice this means choosing an interoperability protocol your counterparties actually use, handling the long tail of unhosted wallets according to your jurisdiction's rules, and — the part nobody warns you about — building the data-handling so that personal information moves securely between platforms without becoming a breach vector itself. Compliance data is attractive loot; treat the compliance stack with the same security rigor as the trading engine.

Layer 3 — Custody and key management: where crypto differs from fintech

Everything above applies to any financial platform. Custody is where crypto is its own discipline, because a key compromise is irreversible in a way a database breach is not. The 2026 baseline: hot/cold segregation with the overwhelming majority of assets in cold storage and hot wallets sized as operating float, not treasury; no single-person spend authority — multisig or MPC so that no individual (including the founder, especially the founder) can move treasury funds alone; withdrawal controls — allowlists, velocity limits, time-delayed large withdrawals, and out-of-band confirmation for anomalies; and documented signing ceremonies for cold-storage operations, with hardware under physical control and recovery material geographically split.

The failure mode we design against isn't exotic cryptography — it's process collapse under pressure: the "emergency" that convinces someone to bypass the ceremony. Your custody design is only as strong as its worst authorized exception.

Layer 4 — Platform security: the exchange as a target

An exchange is a web application with a bounty on it. The program that matches the threat: secure development lifecycle — threat modeling before features, code review with security gates, dependency and secrets scanning in CI; authentication built for hostile conditions — phishing-resistant MFA offered (and required for high-value accounts), session controls, anti-ATO measures like device fingerprinting and withdrawal re-authentication; infrastructure hardening — segmented environments, immutable deployment, DDoS protection sized for extortion-grade attacks; and regular offensive testing — at minimum an annual penetration test scoped to the platform plus retest, with scope and cadence rising with assets under custody. Banking partners increasingly ask for the pen test report by name; ours are written to be handed over. (What that report should contain — and cost — is covered in our pricing guide.)

Layer 5 — Internal access: the insider is a threat model, not an insult

Exchange incidents split roughly between external compromise and internal failure — malicious or negligent. Controls that address both without paralyzing a small team: least-privilege access with quarterly reviews; dual control for money movement and production changes; separate admin identities with hardware-key MFA; session recording on privileged access to custody and compliance systems; and offboarding that actually executes the same day, because a departed engineer's lingering access to a trading platform is a headline waiting to happen. None of this requires enterprise bureaucracy — it requires identity architecture designed once, properly.

Layer 6 — Governance: if it isn't written, it didn't happen

The layer that converts everything above into survivable audits: a written AML program with a named MLRO and real authority; policies that match practice (a policy you don't follow is worse than none — it's documented non-compliance); risk assessments refreshed on schedule and after material changes; training with records; and an evidence pipeline — the ability to produce, within days, the artifacts any reviewer requests: screening logs, alert dispositions, access reviews, pen test reports, restore tests, board minutes on risk. Platforms heading toward institutional clients typically add a SOC 2 path; the controls above are most of the distance.

What due diligence actually asks for

When a bank, payment processor, or institutional partner opens due diligence, the request list is remarkably consistent. Having the following ready — current, versioned, and honest — cuts weeks off the process:

A useful mental model: every artifact on that list is either generated automatically by systems built right, or reconstructed painfully by humans under deadline. The build choice happens long before the bank asks.

Frequently asked questions

Discuss your platform Our KYC/AML tooling practice

General information reflecting FATF-aligned practice and field experience, not legal advice. Licensing and reporting obligations vary by jurisdiction — confirm specifics with counsel in yours.