BaaS

Who it's for. Regulated banking-as-a-service platforms, treasury products, OTC desks, and B2B fintech infrastructure providers whose own KYC'd customers need crypto-to-fiat or fiat-to-crypto rails. You operate the customer relationship; BRRR provides the settlement engine and the AML/risk layer.

The defining characteristic of this vertical: server-to-server, no end-user signing. Your customer's funds either arrive on-chain at a BRRR address (Deposit) or originate from a registered IBAN (OTC). Your application never holds private keys, never surfaces a wallet-connect prompt, and never asks for 2FA — those concerns live with you and your customers separately.

Typical scenarios

• Crypto cash-out as a feature. A regulated payments platform offers its KYC'd customers the ability to convert held crypto into EUR delivered to their own bank account. (Multi-tenant Settlement.)
• OTC desk routing. An OTC desk takes a customer order — "sell 10 ETH for EUR to IBAN X" — and routes the leg through BRRR. (OTC API.)
• Treasury product cash management. A B2B treasury tool periodically converts client crypto holdings to EUR and delivers via SEPA, on a programmed cadence. (Multi-tenant Settlement, scheduled by your system.)
• Compliance-driven Withdraw. A regulated platform funds customer wallets from registered IBANs for crypto-related products, with KYC tied to your own SumSub flow. (OTC API buy-EUR direction.)

Recommended stack

Need	Reach for
Settle crypto into customer bank accounts (your customers, not yours)	Multi-tenant Settlement API
Pre-settlement risk score on a customer wallet	Risk assessment — RISK_ASSESSMENT webhook + on-demand polling
Direct crypto ↔ EUR settlement against a single registered IBAN	OTC API
Server-side notifications of state changes	Webhooks — RISK_ASSESSMENT, SETTLEMENT_STATUS_CHANGE
Indicative rates for UI display ahead of a quote	Rates

The Multi-tenant Settlement and OTC APIs are deliberately low-level: they expose the quote → execute → status loop directly, with no opinionated UX layer in between. That's the right shape for a BaaS — your product surfaces the quote in your own UX, and you control retry, expiry, and reconciliation.

Architecture at a glance

   ┌────────────────────────────────────┐
   │         Your BaaS platform         │
   │   (your KYC, your customer DB,     │
   │    your treasury / orchestration)  │
   └────────────────┬───────────────────┘
                    │  X-Api-Key
                    ▼
   ┌────────────────────────────────────┐
   │             BRRR APIs              │
   │   api.brrr.network                 │
   │                                    │
   │   • Multi-tenant Settlement        │
   │     register → monitor → quote     │
   │     → execute → status             │
   │                                    │
   │   • OTC API                        │
   │     sell-crypto / buy-EUR          │
   │     against a registered IBAN      │
   │                                    │
   │   • Risk + monitoring + webhooks   │
   └─────┬─────────────────────────┬────┘
         │                         │
         ▼                         ▼
   ┌──────────────┐         ┌──────────────┐
   │  Customer    │         │  Customer    │
   │  IBAN        │         │  wallet      │
   │  (SEPA-out)  │         │  (token-in)  │
   └──────────────┘         └──────────────┘

The customer relationship — KYC, contracts, T&Cs, support — lives entirely on your side. BRRR's contribution is the settlement rail and the AML/risk overlay that sits between an on-chain transfer and a fiat payout.

Prerequisites

• A signed agreement with the partner program (no self-serve onboarding for Multi-tenant Settlement or OTC).
• Your own customers must complete KYC verification through SumSub with a GREEN status before they can be registered. BRRR does not begin monitoring or risk-assessing addresses until that status is confirmed. See Onboarding for the integration sequence.
• A webhook endpoint capable of validating signatures and handling out-of-order delivery.

Where to start

1. API Authentication — X-Api-Key and security best practices
2. Onboarding — register a customer and their first EVM address
3. Risk assessment — act on LOW / MEDIUM / HIGH / VERY HIGH outcomes
4. Settlement estimation and execution — the quote → execute → status loop

Where to next

• Multi-tenant Settlement section — full server-to-server lifecycle
• OTC API — IBAN-anchored direct settlement
• Webhooks — signatures, retries, event ordering
• Go-Live Checklist — production readiness