Building a SOC for a crypto exchange from scratch

Why exchange SOCs are different

A generic SOC is built to detect SaaS-style threats: phishing, lateral movement, data exfiltration, ransomware. A crypto exchange SOC needs all of that plus an entire category of threats that don't apply anywhere else:

Wallet drainer JavaScript injected into the trading UI.
Custody-key compromise via subprocessor supply chain.
Address poisoning attacks against high-net-worth account holders.
Front-running by privileged employees with read access to the order book.
Smart contract approval phishing tricking retail users.

If you're standing up a SOC for a regulated exchange in 2026, here's the runbook we deploy with Managed SOC clients on day one. The detection content overlaps heavily with what we ship for licensed casino operators — the threat surface is different, the detection logic is mostly the same.

The detection layers

We bias toward five layers, in priority order:

Trading + custody pipeline integrity — the most important to catch fast.
Withdrawal flow — most expensive single category of fraud.
Identity + access — both customer and employee.
Public surface — web, mobile, API.
Subprocessor + supply chain — long-tail, lowest frequency but worst blast radius.

Most generic SOCs spend 80% of their attention on layer 4 because it's noisiest. For exchanges this is exactly backwards.

Layer 1: trading + custody pipeline

Detection: unexpected wallet outflow

Baseline your hot wallet outflow per hour, per day, per week. Alert at the 99th percentile. Alert harder at any single transaction above a hard threshold.

ALERT custody.hot_wallet.outflow_spike
WHEN sum(outflow_eur) over 1h > 99th_pct(outflow_eur_1h, 30d)
SEVERITY P1
RUNBOOK runbook://custody/outflow-spike.md

Detection: cold-to-hot replenishment outside schedule

You replenish hot wallets from cold storage on a defined schedule. Any unscheduled replenishment is either a treasury mistake or theft. Alert always.

ALERT custody.replenishment.unscheduled
WHEN cold_to_hot_transfer.timestamp NOT IN approved_schedule
SEVERITY P1
ESCALATE custody-ops, ciso

Detection: wallet drainer JS injection

Sentinel the public JS bundles served by your trading UI. Any change in the bundle hash that isn't tied to a verified deploy commit is a red alert.

ALERT frontend.js_bundle.hash_mismatch
WHEN current_bundle_hash NOT IN approved_deploy_hashes(last 24h)
SEVERITY P1
RUNBOOK runbook://frontend/bundle-tamper.md

This is the single highest-ROI detection an exchange can have. Wallet drainer attacks have killed otherwise solid exchanges in 90 minutes.

Layer 2: withdrawal flow

Detection: withdrawal-address change + withdrawal in same session

This is the canonical credential-stuffing-to-cashout pattern. Catch it.

ALERT user.withdrawal.address_change_then_withdraw
WHEN account.withdrawal_address.last_change < 24h
 AND account.withdrawal_initiated.timestamp = now
 AND account.withdrawal_amount > threshold
SEVERITY P1
ACTION freeze_withdrawal_pending_review

Detection: withdrawal to known mixer or sanctioned address

Subscribe to a chain-analytics feed (Chainalysis, Elliptic, TRM Labs, take your pick). Match every outgoing withdrawal address against the feed before broadcast.

ALERT withdrawal.destination.flagged
WHEN withdrawal.destination IN chain_intel.high_risk_addresses
SEVERITY P0
ACTION block_withdrawal, escalate_compliance

P0 because regulatory exposure on this is severe.

Detection: address poisoning at the user level

Address poisoning attacks send a $0 transaction from an address that looks visually similar to one the user has recently used. The user later copy-pastes from history and sends to the attacker.

You can't fully prevent this client-side, but you can:

Warn the user UI-side if they're sending to an address that has never been the recipient of an inbound transaction.
Force a re-confirmation step for first-time recipient addresses.

This isn't a SOC detection per se, but it's the kind of cross-team finding the SOC should escalate to product when they see incoming reports.

Layer 3: identity and access

Detection: privileged employee accessing order book on customer account

Read access to customer account state is operationally legitimate (support, compliance, fraud) but it's a front-running vector.

ALERT employee.access.account_view_then_trade
WHEN employee.viewed_account = account.with_open_orders
 AND employee.placed_trade.timestamp - employee.viewed_account.timestamp < 5min
 AND employee.trade_correlation_with_viewed_orders > 0.6
SEVERITY P1
ESCALATE compliance, hr

This rule has a high false-positive rate at first. Tune the correlation threshold for your operation.

Detection: customer login from new device + immediate withdrawal

ALERT user.login.new_device_high_value_action
WHEN account.login.device_fingerprint IS new
 AND account.subsequent_action IN [withdrawal_initiate, withdrawal_address_change, password_change]
 AND time_between < 30min
SEVERITY P1
ACTION step_up_auth_challenge

Detection: employee privilege escalation

Standard AD-style detections, no exchange-specific tuning needed. Watch for service accounts being assigned to humans, watch for Domain Admins group membership changes, watch for Kerberoasting.

Detection: security management console login from an unrecognized source

Your SIEM and firewall management consoles carry more privilege than almost anything else in the estate — an authentication bypass in Check Point's SmartConsole is the current reminder of why. Baseline the source IPs that legitimately log into those consoles and alert on anything outside that list.

ALERT security_console.login.unrecognized_source
WHEN console.login.source_ip NOT IN approved_admin_ips
SEVERITY P1
ESCALATE ciso

Layer 4: public surface

This is well-trodden ground for any SOC. The exchange-specific tuning:

Sentinel your withdrawal API endpoint with stricter rate limits than the rest of the API.
Log every approved API key creation; alert on creation of a new key with broad permissions.
Monitor the OAuth scopes granted to third-party integrations daily — sudden scope expansion is a compromised partner.

Layer 5: subprocessor + supply chain

The slowest, but highest blast-radius category.

Detection: subprocessor unexpected DNS / connection

If your custody platform talks to a known set of external IPs and ASNs, alert on any new ones.

ALERT custody.outbound.new_destination
WHEN custody_service.outbound_connection.dest NOT IN approved_destinations
SEVERITY P1

Detection: software supply chain — new dependency in a deploy

Hook your CI/CD to flag any newly-introduced npm/pip/go dependency. Manual review before merging.

This is policy-level not real-time, but it's saved at least two of our clients from supply chain attacks in the last 18 months.

On-call structure

For a regulated exchange we recommend:

Tier 1 (24/7): alert triage, runbook-driven response, escalation only.
Tier 2 (follow-the-sun): incident commander, deep-dive investigation, coordinated response.
Tier 3 (on-call): senior engineer + CISO for P0/P1 events.

P0 (active funds loss in progress) calls the entire stack. P1 (high-confidence imminent risk) calls Tier 2 + Tier 3. P2 (suspicious but not confirmed) Tier 1 only.

Median time-to-page should be under 90 seconds from alert fire. Median time-to-action under 5 minutes.

What we deliver during a SOC standup

When we run a SOC standup engagement for an exchange client:

Week 1: SIEM integration + base detection content + runbook drafts.
Week 2: tuning against your traffic; reducing false-positive rate from typical ~60% to under 10%.
Week 3: tabletop exercise against three likely attacker scenarios.
Week 4: full 24/7 monitoring goes live.

The tabletop exercise is where most clients realise their existing runbooks are wishful thinking. We rewrite them on the spot.

If you're standing up a SOC for an exchange this year, reach out — we've done this enough times that we can hand you a 90% complete detection content pack on day one. Most clients also retain us for Incident Response as the escalation path when a P0 fires before the in-house team is fully trained.