TL;DR
A white label crypto wallet is wallet infrastructure an institution brands and ships as its own. For a regulated buyer the branding is the least interesting part — what matters is where the custody perimeter falls, which is decided by one question: who can produce a valid signature. That answer determines your licensing obligations under MiCA and comparable regimes, your segregation and reconciliation duties, your audit surface, and whether you can leave. This guide covers the custody models, the key management architectures underneath them, the diligence questions procurement should be asking, and the exit criteria to settle before signing.
Search results for "white label crypto wallet" are written for a buyer who wants to launch quickly. That buyer exists, but they are not the one signing the contracts that matter. The institutional buyer — an exchange, a payment service provider, a broker, a neobank adding digital assets — is asking a different question, and the branding answer does not address it.
For a regulated institution, a white label crypto wallet decision is a custody perimeter decision. Everything downstream — licensing, segregation duties, reconciliation, audit scope, insurance, whether you can ever leave the vendor — falls out of one determination: who can produce a valid signature over client assets.
This guide is written for that evaluation.
What a white label crypto wallet actually is
Wallet infrastructure built and operated by a specialist, branded and shipped by someone else. The provider runs key generation, storage, signing, recovery, chain connectivity and transaction routing. The institution owns the brand, the customer relationship, the product surface — and, usually, the regulatory obligations.
Three layers, as with any white label arrangement:
- Provider infrastructure — hardened key management, signing, multi-chain connectivity, fee handling. Years of work and a stack of audits you would otherwise commission yourself.
- Integration surface — APIs and SDKs the institution builds against, plus whatever administrative interface the institution's own staff and clients use.
- The institution's product — the exchange, the payment platform, the banking app, presented entirely under its own brand.
The white label part is the third layer. The consequential part is the first, and specifically what the provider retains the power to do.
Who is actually buying this
The consumer-facing framing — games, loyalty programmes, consumer apps — is a real segment but a different one. The institutional buyers are:
- Exchanges and brokers issuing deposit addresses to retail users, sweeping to treasury, paying withdrawals from a hot wallet
- Payment service providers and stablecoin fintechs settling merchant flows, holding float, running payouts across corridors
- Neobanks and EMIs adding a digital asset line to a licensed banking product
- Remittance operators moving stablecoins across borders and cashing out into local rails
- Platforms reselling wallet infrastructure to their own business clients — a distinct architecture covered in the multi-tenant wallet infrastructure requirements
What unites them: assets belong to somebody else, a regulator has a view on how they are held, and an auditor will eventually ask for evidence.
The custody perimeter decides everything
Three arrangements exist. They look similar in a product demo and are entirely different in a regulatory filing.
| Who can sign | Regulatory position | Typical use | |
|---|---|---|---|
| Provider-held | The provider, on your instruction | The provider is the custodian; you rely on their licence and their failure is your incident | Fast launch, no custody permissions of your own |
| Institution-held | You, using key material the provider cannot reconstruct | You are the custodian; obligations attach to you | Exchanges, PSPs, anyone with or seeking custody permissions |
| End-user-held | Only the end user | Nobody is a custodian; you are a software provider | Non-custodial products, self-directed wallets |
The middle row is where most institutional deals land, and it is the one most often mis-sold. A provider can describe an arrangement as "your wallets, your control" while retaining the technical ability to sign — at which point the provider is in the perimeter regardless of the language.
Ask it precisely: can the provider, acting alone or with its own infrastructure, produce a valid signature over our client assets? Not "do you have access to our funds." The signature question has one true answer.
Two regime notes worth carrying into the conversation. Under MiCA Article 75, custody obligations — segregation of client assets, reconciliation, sub-custody disclosure, liability for loss — attach to whoever is holding on behalf of clients; a sub-custody relationship with your wallet provider is a disclosable arrangement, not a way to shed the duty. Under the GENIUS Act, if you are holding regulated payment stablecoins rather than issuing them, you inherit downstream constraints from the issuers' compliance programmes: sanctions screening on counterparties, redemption pathways, reporting. Both land in the same place operationally — a policy engine and an audit trail on the signing path. The treasury wallet guide covers the balance-sheet side of the same question.
Key management architectures
Under any of the three arrangements sits one of a few key models. The distinction that matters is what has to happen for a signature to exist.
MPC. The private key is split into shares held by different parties; a threshold must cooperate to sign. No single share is a key, and the full key is never assembled in one place. The security property is cryptographic; the policy lives wherever signing is coordinated. Ask how many shares, who holds each, in what jurisdiction, and what happens when one is lost.
HSM or enclave. Keys are generated and used inside tamper-resistant hardware or a trusted execution environment that will not export them. Well-understood by auditors and familiar to banking risk teams. Ask for the attestation, not the marketing claim.
Smart accounts. Authorisation moves on-chain. The account is a contract with rules about which signers may do what, so limits, allowlists and approval thresholds are enforced by the chain rather than by an off-chain service — and the authorised signer can be rotated without moving a single asset. That last property is the cleanest exit mechanism available, and it is why institutions increasingly pair a smart account for policy with MPC or an HSM for the key itself.
These are not mutually exclusive, and the strongest institutional setups combine them: hardware or MPC protecting the key, a smart account making the rules provable and the vendor replaceable.
Segregation and the reconciliation burden
How client assets are addressed on-chain determines what you can prove.
Omnibus pools client assets in one address, with entitlements tracked in the institution's internal ledger. Cheap to operate, minimal gas, few addresses. The difficulty is evidentiary: proving segregation to an auditor means proving your ledger, and a discrepancy between ledger and chain is discovered rather than prevented.
Per-client addressing gives each client its own on-chain address. Segregation is directly observable, reconciliation is arithmetic, and an auditor can verify it independently. The costs are operational: many addresses to provision, sweeping to consolidate, gas on every sweep.
The common institutional pattern is a hybrid — per-client deposit addresses that sweep on rules into an omnibus treasury. You keep the observable audit trail at the point of receipt and limit the number of hot balances you are operating. That pattern has requirements of its own, particularly around sweep thresholds and gas funding for addresses that only ever hold tokens; the multi-tenant requirements guide works through the mechanics.
Operational requirements
Beyond custody, the machinery that determines whether the thing is runnable in production:
- Programmatic address issuance — unlimited addresses, one API call each, with a data model where a single client identity can own many addresses across chains
- Policy enforced before signing — caps, allowlists, screening and approval thresholds evaluated server-side, so a leaked API credential costs one bounded transaction rather than a hot wallet. See programmable wallet controls
- Reliable event delivery — webhooks on incoming transfers with at-least-once semantics and replay, because reconciliation is downstream of them
- Complete audit trail — what was requested, which rule approved it, which signer executed, when, retained for your retention period and exportable in a format an auditor accepts
- Role separation — the person who authors a policy should not be the person who approves the transaction that policy governs, and the system should enforce that rather than document it
- Chain coverage, at two levels — signing support and fee abstraction are different capabilities, and providers frequently have the first without the second. Ask separately, and ask about Tron early if any part of your flow settles USDT in emerging markets
Procurement diligence
The questions a security and compliance function should be putting to the provider:
- Can you, acting alone, produce a valid signature over our client assets?
- Where do key shares physically reside, and under which jurisdictions?
- What is the audit history — auditor, date, scope, and a link to each report?
- Is the signing infrastructure open source or otherwise independently attestable?
- What is the penetration testing cadence, and who performs it?
- What are the incident and breach notification terms, in hours?
- Is there insurance, what does it cover, and who is the named beneficiary?
- What is the uptime commitment, and what is the remedy when it is missed?
- What is the sub-processor list, and how are changes to it notified?
- What is the documented exit procedure, and can we test it before go-live?
Question 4 deserves emphasis in this category. Open-source signing infrastructure changes the diligence conversation from trusting a description to reading an implementation — and gives you the option of running it yourself if your perimeter later demands it.
Exit criteria
Settle this before signing, not during an incident. Three requirements, each testable:
- Key export using your own credentials, without the provider's participation
- Recombination of those shares into a working signer in infrastructure you control
- Continuity without on-chain migration — addresses keep working, client assets do not move
Smart-account architectures add signer rotation, which lets you replace the provider without touching a single balance or asking a single client to do anything.
The test is simple and worth applying bluntly: if leaving requires the provider to still be operational and cooperative, that is not an exit path. Run the export once, into a staging environment, before go-live. A procedure that has never been executed is a paragraph.
Build or buy, at institutional scale
The usual framing — engineering months versus integration days — misses what actually drives the decision for a regulated buyer.
Building means permanently owning the audit scope, the key ceremony, the pen test cadence, the chain integration backlog, the on-call rotation, and the incident response. You cannot inherit anyone else's attestations. That is correct when custody is itself the regulated product you sell — a qualified custodian, a specialist trust company.
Buying, with signing authority retained on your side, gets the control without the permanent audit surface. You inherit the provider's audits as a starting position, you keep the ability to sign, and your engineering effort goes into the product your customers actually pay for. That is the right shape for an institution where wallets are the means and payments, trading or banking is the end.
The failure mode is the middle: buying, believing you retained control, and discovering during a regulatory review that the provider was in the perimeter the whole time.
How Openfort fits an institutional evaluation
Against the questions above, concretely and with the limits stated:
- Smart accounts with signer rotation — policy enforced on-chain, and the provider replaceable without moving assets
- OpenSigner, open-source key management — readable, independently reviewable, and self-hostable inside your own perimeter if that is what your risk function requires
- Four independent security audits — Certik, Omniscia, Cure 53 and Quantstamp, with reports available
- Server-side policy evaluation — spending limits, allowlists and approval rules applied before signing, on backend wallets and smart accounts alike
- Programmatic address issuance — unlimited wallets, one identity able to hold many addresses across chains
- Key export — your key material, exportable with your credentials, recombinable on your own trusted execution environment
- Chain coverage — EVM chains and Solana today, with gas abstraction on Arbitrum, Avalanche, Base, Beam, BNB Chain, Ethereum, Optimism, Polygon and Solana. Bitcoin, Tron and Stellar are not supported and are scoped as per-chain integrations
If you are reselling wallet infrastructure to your own business clients rather than serving end users directly, the isolation requirements are different and stricter — start with the multi-tenant requirements checklist.
Getting started
Everything above works in test mode at no cost, which is the right way to run the evaluation: provision addresses, apply a policy, execute a withdrawal against it, and export your key material into a staging environment before anyone signs anything.
For an institutional evaluation with a defined chain list and a compliance review attached, talk to the team or read the enterprise deployment options — self-hosted key management is the usual starting point when the perimeter has to sit inside your own infrastructure.
