Which mode fits your product?
External Wallet Access
- Wallet lives in
- The user's external wallet (MetaMask, Rabby, a smart contract wallet, or a non-custodial wallet the Partner provisions for the user).
- Who signs
- The end user, in their wallet, for each banking action.
- Onboarding
- The user's URID is minted to their own wallet address.
- Partner integrates with
- UR backend, plus chain and on-chain contracts for the user's wallet.
- Best fit
- Web3-native products — DeFi platforms, on-chain wallets, dApp ecosystems, self-sovereign users.
Managed Custody
- Wallet lives in
- A UR-managed wallet for the user's fiat, plus a Partner-managed wallet for the user's crypto.
- Who signs
- The Partner backend — the user never has to step into a wallet for a banking action.
- Onboarding
- The user's URID is minted into a UR-managed wallet.
- Partner integrates with
- UR backend only.
- Best fit
- Consumer fintechs, exchanges, smart wallets, neobanks consolidating banking behind their own UX.
Account Mode Architecture
External Wallet Access
One wallet, one signer. The user's URID, fiat, and crypto all live in the same external wallet; the user signs each banking action themselves.
Managed Custody
Two accounts, one orchestrator. The Partner Backend talks to UR for fiat actions and directly manages the user's crypto wallet on its own platform. The user never sees a signing prompt for fiat actions.
The banking verbs
Across both Account Modes, the user-facing operations are the same. At the API level, the authentication scheme and address parameters differ slightly.
Pay-in — money arriving from an external bank
The user wires fiat from their own bank to UR, and it lands in their fiat balance. UR shows the deposit-destination details and credits the user when the wire settles.
- 1User requests to view their deposit-bank details.
- 2User signs the request in their wallet so Partner can carry the signature when calling the API to fetch Profile + IBAN details.
- 3Partner shows the user the deposit-bank details (IBAN, BIC, payee).
- 4User initiates a SEPA / SWIFT transfer from their bank.
- 5The wire settles at UR; fiat balance arrives in the user's external wallet.
- 6Partner is notified that the deposit landed; the frontend reflects the balance update to the user.
- 1User requests to view their deposit-bank details.
- 2Partner calls the API to fetch Profile + IBAN details.
- 3Partner shows the user the deposit-bank details (IBAN, BIC, payee).
- 4User initiates a SEPA / SWIFT transfer from their bank.
- 5The wire settles at UR; fiat balance arrives in the user's external wallet.
- 6Partner is notified that the deposit landed; the frontend reflects the balance update to the user.
Three questions to lock in your mode
Other considerations for your integration.
- 1
Should the user's fiat live in their own self-sovereign wallet, or in a separate account controlled via API?
Fiat in the user's own wallet →External Wallet AccessThe user's URID identity and fiat balance live in their external wallet. Many banking actions require the user to step into their wallet to confirm.
Fiat in a UR-managed wallet →Managed CustodyUR provides a fiat account per user. Your UX shows the balance; confirmation on each action is invisible to the user — the Partner backend authorizes it.
- 2
When the user taps their card, do you want it to spend fiat, or to spend crypto?
Card spends fiat →Card Mode: Fiat OnlyCard swipes are authorized against the user's fiat balance. No Partner-side authorization step is required.
Card spends crypto →Card Mode: Crypto BackedPartner runs a real-time authorization callback, pre-funds a settlement account, and debits the user's crypto after the swipe.
- 3
What's your KYC model — does UR handle it end-to-end, or does the Partner pre-collect?
KYC Mode →TBD — currently in active spec workFor now, both Account Modes flow user KYC through UR-supervised vendors. KYC Mode formalizes how data collection is split between Partner and UR.