For exchanges, wallets & custody
Built for centralized exchanges, wallet providers, and custody and treasury—each with the same API and decision model, tailored to where risk appears in their flows.
Aim
To serve all platforms that move or hold crypto at scale with one API and one decision model, so they don’t need separate vendors for withdrawals, deposits, and trading. We aim to fit into existing architectures (exchange backend, wallet app, custody signing pipeline) with minimal data (no PII) and the same response shape everywhere.
BSBsec is built for the platforms that move and hold crypto at scale. Centralized exchanges use us for custodial trading, fiat onramps and offramps, and brokerage-style apps: we plug into withdrawal flows to prevent scam send-outs, into deposit pipelines for risk-aware crediting and AML visibility, and into trading UI to warn on risky tokens or honeypots. Wallet providers—MPC wallets, smart contract wallets, and self-custody mobile apps—use the same API to add risk UX: warn users when they paste a poisoned or scam address, or when they are about to interact with a risky token or contract. Custody and treasury teams use us for institutional custody, treasury transfer pipelines, and signing policy engines—so every transfer can be checked against our risk and exposure signals before it is signed. Across all three, the product is the same: one API, one decision model (risk_score, recommended_action, reason_codes, evidence), and one integration pattern (you hook us where risk decisions matter; you enforce the action). We don’t require PII: you can send a user_risk_tier that you define internally; we only need blockchain address, chain, asset, and amount to run our detection. That makes it easier to adopt without re-architecting your identity or KYC stack.
How we do it
- Single REST (or gRPC) API for all client types: the request schema supports withdrawal context (source, destination, chain, asset, amount), deposit context (depositing address, chain, asset, amount), or trading context (user address, token/pair, direction, amount). A single endpoint or a small set of action-specific endpoints return the same response shape: risk_score, recommended_action, reason_codes, evidence, decision_id, model_version.
- No PII: we do not require names, emails, or KYC identifiers. You can send an optional user_risk_tier (e.g. new_user, high_limit) that you compute internally; we use it only to tune sensitivity or step-up suggestions. This keeps integration simple for wallets and custody providers who may not want to send identity to a third party.
- Tenant isolation: each client has API credentials and optional tenant_id. Configuration (e.g. sensitivity thresholds, allowed actions) and policy overrides are stored per tenant. We do not mix data or config across tenants.
- Deployment options: we support a shared cloud API (multi-tenant) and, for enterprise, optional dedicated or on-prem–adjacent deployment. Same API contract; different SLAs and data residency. Webhooks or polling for blocklist/rule updates are available so you can keep local caches in sync if needed.
Outcomes
- •Centralized exchanges: withdrawal, deposit, and trading protection with one API
- •Wallet providers: same API for risk UX—address and token warnings without PII
- •Custody & treasury: signing gates and transfer checks for institutional flows
- •Minimal data: address, chain, asset, amount; optional user_risk_tier you define