Why Your HSM Is Stealing Your Alpha

The Anatomy of a Cloud HSM Request

When your trading system signs a transaction through AWS KMS, here's what actually happens:

1. Your app serializes the request         ~0.5ms
2. TCP connection to KMS endpoint          ~1ms (same AZ)
3. TLS handshake (if new connection)       ~3ms
4. Request queued behind other tenants     ~5-50ms (variable!)
5. HSM processes signing operation         ~2ms
6. Response traverses network back         ~1ms
7. Your app deserializes response          ~0.5ms
                                   ─────────────
                            Total: 13-58ms (typical)
                            P99:   150-350ms (reality)

Step 4 is the killer. Cloud HSMs are shared infrastructure. Your signing request waits behind every other customer's request. During peak hours, that queue time explodes.

The P99 Problem

Averages lie. Your SLA might say “5ms average.” But trading systems live in the tail:

Your worst 1% of trades are 30× slower than your average. That's not jitter — that's a structural deficiency.

What 150ms Actually Costs

Consider a quantitative equity strategy trading $10M daily across 500 orders:

• Average order size: $20,000
• Market moves in 150ms: ~2–5 bps (battle-tested estimate)
• Slippage per order: $4–10
• Daily cost: $2,000–5,000
• Annual cost: $500K – $1.3M (just from signing latency)

Now multiply by the P99 tail events. On volatile days (earnings, FOMC, geopolitical events), that 150ms becomes 350ms, and market moves in that window can be 10–50 bps.

The Compliance Angle

SEC Rule 15c3-5 requires “risk management controls and supervisory procedures” for market access. If your signing infrastructure introduces uncontrolled latency variance that affects execution quality:

1. Best execution obligation: Are you providing best execution if your signer adds 150ms of uncontrolled latency?
2. Operational risk: A cloud HSM outage during market hours is an operational risk event that should be in your risk register.
3. Audit trail: Can you prove what your signing latency was on any given day? Most cloud HSMs don't provide per-request latency metrics.

The Alternative: Sovereignty

Sovereign signing means the signing key lives in hardware you control, on compute you own, with latency you can measure and guarantee.

Action Items

1. Measure it: zcp audit --volume YOUR_DAILY_VOLUME
2. Document it: Add signing latency to your operational risk register
3. Present it: Show your CRO the annual cost estimate
4. Fix it: Deploy sovereign signing on your existing AWS infrastructure

The numbers in this article are estimates based on publicly available market data and standard slippage models. Your actual impact depends on strategy, volume, and market conditions. We encourage you to measure your own latency with the open-source zcp tool.