Product Wiki
What this covers / who it's for. The index and reading path for product people — PMs, designers, support, compliance stakeholders — and AI agents reasoning about the platform at a product level: what Stables does, for whom, why, and the mechanics that shape behavior, latency, and failure modes. No implementation detail; the engineering view lives in
wiki/engineering/.
Stables is a multi-tenant stablecoin banking platform. A business signs up as a tenant (workspace), passes KYB/KYC, and gets accounts, wallets, deposits, payouts, and FX views — executed by an underlying regulated finance rail and governed by a compliance backbone (cases, freezes, regulatory filings, an immutable audit trail). Central operators run support and compliance from a backoffice.
Reading path
Start here (the platform):
- Platform overview — what Stables is, the value proposition, and the capability map.
- Personas & access — the two user populations (client users in a tenant workspace vs central operators), teams, roles, and MFA.
- Tenant lifecycle — from self-service registration through KYB/KYC to active, and the suspended/frozen/closed states.
- Plans & entitlements — the tier model (starter/growth/elite), jurisdiction gating, and quotas/limits/fees.
The money (the journeys):
- Money movement — accounts & wallets, deposits (with travel-rule holds), payouts (maker/checker/co-sign), orders, exports & statements, the master balance.
- Compliance & trust — what the platform guarantees: case handling, account freezes, SAR/CTR/travel-rule filings, the tamper-evident audit trail, and the encrypted document vault.
- Notifications & comms — the in-app inbox, email, consent and preferences, and the durable comms record.
- Operator backoffice — what central operators can do today (an API-first surface; the operator UI is being rebuilt).
Under the hood (the mechanics cluster) — how the platform actually behaves, at a mechanics level, for product reasoning:
- Providers & rails — which capabilities Stables executes itself vs offloads to the finance rail (Conduit); what we own vs what the provider owns; why our view can briefly lag theirs.
- Where data lives — the primary database, document storage, write-once audit exports, and what reaches the provider.
- Async by design — what is deliberately not instant (exports, statements, document forwarding, provider actions) and how request-then-poll works for an end user.
- Communications delivery — how email and notifications leave the system, what is logged, and how long it is kept.
- Dependencies & failure modes — the centerpiece: capability → underlying dependency → user-visible impact when it is slow or down → what to check first.
- Data lifecycle guarantees — retention windows, pruning, right-to-be-forgotten, and what freeze/closure actually does to data.
Reference:
- Glossary — domain terms and every user-visible status, grounded in the code.
- Capability → module map — the bridge into the engineering wiki for each product capability.
All pages
| Page | One-line scope |
|---|---|
| platform-overview.md | What Stables is, for whom, capability map |
| personas-and-access.md | Client users vs operators; teams, roles, MFA |
| tenant-lifecycle.md | Registration → KYB/KYC → active → frozen/closed |
| plans-and-entitlements.md | Tiers, jurisdiction gating, quotas/limits/fees |
| money-movement.md | Deposits, payouts, orders, balances as journeys |
| compliance-and-trust.md | Cases, freezes, filings, audit, vault as guarantees |
| notifications-and-comms.md | Inbox, email, consent, comms record |
| operator-backoffice.md | The operator surface today |
| mechanics/providers-and-rails.md | Execute vs offload; the mirror model |
| mechanics/where-data-lives.md | DB, object storage, WORM, provider-held data |
| mechanics/async-by-design.md | The not-instant surfaces; request-then-poll |
| mechanics/communications-delivery.md | Outbound comms mechanics |
| mechanics/dependencies-and-failure-modes.md | The dependency map (centerpiece) |
| mechanics/data-lifecycle-guarantees.md | Retention, RTBF, freeze/closure effects |
| glossary.md | Terms + status glossary |
| capability-module-map.md | Capability → module bridge |