Wallet-as-a-Service (WaaS) is infrastructure that lets banks, fintechs, and enterprises embed onchain wallets into their products without building custody, key management, or transaction signing from scratch. Modern WaaS providers ship four security primitives together: passkey authentication, allow lists, dual-control approvals, and full audit logs. Visa's VSP includes WaaS. Turnkey, Fireblocks, Dfns, and Privy are the other names an institution will evaluate.
​

Visa's July 16, 2026 launch of the Visa Stablecoin Platform put WaaS in front of every bank product team at once. Passkeys, allow lists, and dual-control approvals are not new concepts, but bundling them into a bank-defensible package that also handles minting, redemption, and card rail integration is the shift. This piece walks through what WaaS actually is, the security primitives every serious provider ships, how the institutional providers compare, and when a bank should pick WaaS over building custody in-house.
​

A wallet, at the infrastructure level, is a signing surface tied to key material. Wallet-as-a-Service turns that surface into an API. The provider runs the key management (typically MPC, HSM, or a hybrid), enforces policy on who can sign what, and exposes wallet creation, transaction construction, signing, and broadcast as endpoints an institution can call from its own backend.
​

The alternative shapes are self-custody (the institution runs its own signing infrastructure end to end) and full custody (a qualified custodian holds keys and the institution instructs). WaaS sits between: the provider runs the signing infrastructure, but the institution stays operationally in control. For most banks and fintechs entering stablecoin operations in 2026, WaaS is the shape that clears vendor risk review fastest while still delivering the programmability of onchain rails.
​

Passkey authentication replaces the "seed phrase written on paper" model consumer wallets grew up with. A passkey is a public-key credential bound to a device (Face ID on iPhone, Windows Hello on laptop, a hardware security key), synced across the user's devices through a platform authenticator, and validated with WebAuthn. Institutional WaaS providers use passkeys for user-facing wallet approvals (the treasurer approving a transfer from her phone) and increasingly for operator-side controls too. The point is not that passkeys are fashionable. The point is that they eliminate the two failure modes bank security teams flag first: shared secrets and phishable credentials.
​

An allow list restricts a wallet's outbound counterparties to a preapproved set of addresses. If the wallet does not know an address, it cannot send to it. Institutional providers ship allow lists at multiple scopes: per-wallet, per-workspace, and per-policy. The operational value is not preventing every conceivable attack. It is turning "a compromised operator credential drains the wallet" into "a compromised operator credential does nothing useful, because outbound addresses are already fixed." Combined with dual-control, allow lists collapse a whole category of insider and credential-theft risk into a much smaller one.
​

Dual-control (sometimes called two-person integrity) requires that no single operator can move funds alone. Every transaction over a policy threshold needs a second approver, from a second device, before the wallet will sign. Institutional WaaS providers implement this as a policy engine that sits in front of signing: initiator, reviewer, approver, and any number of custom roles above that. The dual-control primitive is the piece that maps most directly to existing wire transfer controls inside a bank. If a bank operations team already runs four-eyes on high-value wires, WaaS dual-control is the same policy, applied to onchain transactions.
​

Every wallet creation, policy change, approval, and signed transaction lands in an immutable log the institution can export for compliance, reconciliation, and incident response. The specific format varies by provider (Fireblocks exposes a rich event stream, Turnkey exposes structured JSON logs), but the requirement does not: no audit trail, no bank use case. Onchain data is publicly verifiable, but "the transaction hash exists on Base" is not sufficient for a compliance officer who needs to know which operator initiated it, who approved it, and what policy allowed it.
​

The right answer depends less on which vendor has the best marketing and more on which one already integrates with the specific rails, chains, and policy shapes an institution needs. A bank running card programs on Visa will look at VSP first for gravity reasons. A crypto-native trading firm will look at Fireblocks first for the same reason.
​

Pick WaaS when the institution wants operational control over transactions and policy but does not want to run key management, quorum ceremonies, or HSM operations in-house. This is the median case for a bank offering stablecoin services to corporate clients in 2026. The bank keeps the operator experience, the customer relationship, and the compliance ownership. The provider runs the signing infrastructure.
​

Pick self-custody when regulatory posture or a specific business reason requires that key material never touch a third party. This is a smaller set of institutions (some qualified custodians, some sovereign programs) and it comes with a much larger operational burden. The tradeoff is real: self-custody means the institution runs its own MPC or HSM stack, its own quorum policy, and its own incident response for lost or compromised key shares.
​

Pick full custody when the institution wants exposure to stablecoin balances but does not want to run any operational infrastructure. A qualified custodian holds keys, and the institution instructs. This is common for asset managers holding stablecoin positions inside a fund structure. It is uncommon for payments or treasury use cases where the institution needs to send transactions frequently.
​

For deeper context on the underlying custody models, see Treasury Custody: Multi-Sig vs MPC vs HSM.
​

Three limits worth stating plainly.
​

WaaS does not decide policy. The provider ships primitives (allow lists, dual-control, thresholds). The institution decides which addresses to allow, which thresholds trigger four-eyes, and which operators sit in which roles. Bad policy on a great WaaS platform still produces bad outcomes.
​

WaaS does not orchestrate across issuers or chains. A wallet on VSP holds Open USD. A wallet on Fireblocks can hold many assets on many chains, but Fireblocks does not decide which stablecoin to route through for a given payment. Routing is a separate layer. Institutions that want to move flows across USDC, USDT, USDG, and Open USD across chains combine WaaS with an orchestration layer. See What Is Stablecoin Orchestration? for the neutral routing pattern.
​

WaaS does not eliminate operational risk. Compromised operator credentials, misconfigured policies, and social engineering are all still in scope for the institution's security team. WaaS shrinks the attack surface and shifts it. It does not delete it.
​

A pragmatic path for an institution evaluating WaaS in the second half of 2026:

Visa investor announcement. Visa Perspectives: VSP simplifies onchain operations. Coverage: Bloomberg, Decrypt, CoinDesk, Fortune (July 16, 2026).
​