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 layers

We bias toward five layers, in priority order:

1. Trading + custody pipeline integrity — the most important to catch fast.
2. Withdrawal flow — most expensive single category of fraud.
3. Identity + access — both customer and employee.
4. Public surface — web, mobile, API.
5. 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.

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.