Platform Overview
What this covers / who it's for. The one-page answer to "what is Stables?": what the platform does, who uses it, the full capability map, and the handful of behaviors that shape everything else. Start here if you are new to the product; every capability links to a deeper page.
What Stables is
Stables is a multi-tenant stablecoin banking platform for businesses. A business signs up as a tenant — a self-contained workspace with its own team, roles, accounts, and data — and, once verified, gets stablecoin banking capabilities: virtual accounts and wallets, deposits, payouts, currency conversion, and FX views.
Stables does not itself custody funds or run payment rails. Money capabilities are executed by an underlying regulated finance rail (today: Conduit, with identity verification via Persona). Stables is the product layer on top: the workspace, the team and permission model, the compliance backbone, the durable records, and the operator tooling. The platform keeps its own queryable mirror of everything the rail holds — the provider stays authoritative, and Stables' copy is synced continuously (see Providers & rails).
Who it serves
| Population | Who they are | Where they work |
|---|---|---|
| Client users | The business's people — owners, admins, approvers, members — inside one tenant workspace | The tenant SPA (self-service registration, team management, money journeys) |
| Central operators | Stables staff — support, compliance, platform administration | The operator backoffice (a separate, central surface with its own accounts and roles) |
The two populations are fully separate: separate account records, separate sign-in surfaces, separate role systems. A person can hold both kinds of account (even on the same email) — they are still two distinct identities. See Personas & access.
Capability map
| Capability | What it gives the user | Deeper page |
|---|---|---|
| Onboarding (KYB/KYC) | Self-service workspace registration, then a country-specific, requirements-driven business-verification flow with document upload, RFIs, and identity verification | Tenant lifecycle |
| Accounts & wallets | Virtual accounts, wallets, signers and signing quorum, with balances projected into a queryable view | Money movement |
| Deposits | Incoming funds mirrored as transactions, with travel-rule sender-information holds when compliance data is missing | Money movement |
| Payouts & orders | Outgoing payments with a maker/checker approval lifecycle, on/off-ramp conversion orders, registered addresses and whitelisted recipients, searchable transaction history, exports & statements | Money movement |
| FX & master balance | Fresh exchange rates (≤ 20 s freshness guarantee) and a whole-workspace balance rollup converted to one base currency | Money movement |
| Compliance | Cases with SLA tracking, account freeze/closure, SAR/CTR/travel-rule regulatory filings — the trust backbone behind every money flow | Compliance & trust |
| Documents | An encrypted vault holding Stables' own copy of every document (KYB packs included), with signed-URL-only download and per-access logging | Compliance & trust |
| Notifications | An in-app inbox plus email, with consent/preferences and a durable record of every communication sent | Notifications & comms |
| Operator backoffice | Staff management, customer-support lookups, compliance operations, feature overrides — the central operator surface (API-first today) | Operator backoffice |
The Capability → module map bridges each of these into the engineering wiki.
How it fundamentally behaves
Six behaviors recur through every capability. Internalize these and most product questions answer themselves:
- Mirror of a rail, not a ledger of record. For money and verification state the provider is the source of truth; Stables holds a continuously-synced local copy so the product is fast, queryable, and searchable. The copy can briefly lag the rail; a reconciliation backstop heals any missed update. See Providers & rails.
- Async by design. Anything involving the provider — KYB decisions, payouts clearing, document forwarding — and anything heavy — exports, statements — is deliberately not instant: the platform accepts the request, works in the background, and the user polls or is notified. See Async by design.
- Compliance first. Compliance actions override everything else: a jurisdiction can deny a feature no plan can buy back, a compliance freeze blocks every action regardless of workspace state, and sensitive actions require step-up re-authentication. See Compliance & trust and Plans & entitlements.
- Hard tenant isolation. One tenant can never see another's data — enforced in the database itself (row-level security), not just in application code, and continuously verified by the test gates. See the engineering Tenancy & RLS page.
- Everything is recorded. Domain actions land on a tamper-evident audit trail, document access is logged per serve, and every notification sent is durably recorded — with defined retention and right-to-be-forgotten paths. See Where data lives and Data lifecycle guarantees.
- Entitlements are two-axis. What a tenant can do = what its jurisdiction permits (regulatory, non-negotiable) ∩ what its tier entitles (commercial: starter / growth / elite, plus per-tenant overrides). See Plans & entitlements.
Where to go next
Follow the product wiki reading path: Personas & access for who the users are, Tenant lifecycle for how a workspace comes to life, then the money journeys. For "what happens when X is slow or down", jump straight to Dependencies & failure modes.