Capability → Module Map
What this covers / who it's for. The bridge between the product wiki and the code: for every product capability, the module(s) that own it, the engineering wiki page that explains the machinery, and the product page that describes the behavior. Use it to answer "who owns this?" and "where do I read more?" in one lookup.
Modules live in app-modules/<module>/; each README is the current source of specifics for its
module. The engineering module catalog holds the full
per-module engineering view.
One capability, more than one provider
A module owns a capability; the external provider that executes it is chosen per (capability group × jurisdiction), so the same capability can be served by different vendors in different regions (ADR D94). Three capabilities are no longer single-vendor:
| Capability | Provider(s) today | Ship-state |
|---|---|---|
| Onboarding (KYB/KYC, UBO) | Sumsub for GB/EU · Conduit for ZA/NG/KE/US (and everywhere as fallback) | Sumsub live but pre-product, production-gated (D95) |
| Custody (wallets, signers) | Utila (routed — all six jurisdictions) · Conduit override-only (permitted, not an automatic fallback) | Utila live-in-code, deploy-gated, pre-product (D98) |
| Fraud / device intelligence | Fingerprint (primary) · SEON (permitted) — all six jurisdictions | Live-in-code, deploy-gated, default-disabled (D102) |
Every other money-rail capability resolves to Conduit. Fraud / device-risk is the odd one out — it sits off the money-rail umbrella entirely (a device-risk verdict never moves money), so it routes on its own Fingerprint/SEON seam rather than through the rails adapter. See Providers & rails for the product view and the engineering Provider integration page for the machinery. Decision rationale behind these boundaries lives in the decision log.