Security & privacy by design
Minimal data inputs, no PII, HMAC-signed requests, replay protection, and optional mTLS so your integration stays secure and compliant.
Aim
To minimize the security and privacy surface of the integration: we want to enable strong risk detection without requiring sensitive data (no PII), and to protect request/response integrity and prevent replay or tampering. We aim to support enterprise requirements (mTLS, tenant isolation, audit logs) without forcing a single deployment model.
We are designed so you can integrate without sending identity or unnecessary data. Inputs are blockchain address and chain, asset and amount, and an optional user_risk_tier that you define (e.g. new user, high limit)—we don’t need names, emails, or KYC data. Requests are HMAC-signed and we support replay protection via nonce and timestamp so they cannot be replayed or tampered with. For enterprise deployments we offer optional mTLS, and we store configuration and policy per tenant in isolation so your rules and thresholds stay separate from other clients. Decision logs are append-only and replayable via decision_id and version metadata, which supports both audit and deterministic debugging. By keeping inputs minimal and responses structured, we reduce the security and privacy surface of the integration while still delivering the detection depth you need for withdrawals, deposits, and trading.
How we do it
- Authentication: API requests are authenticated with HMAC (e.g. HMAC-SHA256 of method, path, timestamp, nonce, body). You store an API key and secret; the client signs each request. We verify signature and reject expired or replayed requests (timestamp and nonce window). Optional API key in header is supported for simpler setups with TLS-only protection.
- Replay protection: each request includes a nonce (unique per key) and timestamp. We reject requests outside a short time window (e.g. 5 minutes) or with a nonce we have already seen. This prevents capture-and-replay attacks even if a single request is intercepted.
- Data minimization: request body only includes fields needed for the decision—addresses, chain, asset, amount, optional user_risk_tier. We do not request or store names, emails, IPs, or device ids. Responses include only risk_score, recommended_action, reason_codes, evidence pointers, decision_id, model_version.
- Transport and isolation: we support TLS 1.2+ and optional mTLS for enterprise. Configuration and per-tenant policy are stored in tenant-isolated namespaces. Decision logs (if enabled) are append-only and retention-limited; they do not include raw request bodies, only digests or identifiers needed for replay.
Outcomes
- •No PII required: address, chain, asset, amount; optional user_risk_tier you define
- •HMAC-signed requests and replay protection (nonce and timestamp)
- •Optional mTLS for enterprise; tenant-isolated configuration and policy
- •Append-only decision logs and versioned metadata for audit and replay