Crypto Card Architecture: Custody, Settlement, and Privacy Trade-Offs

Crypto cards have seen incredible growth over the last few years, going from processing $100 million a month in early 2023 to over $1.5 billion a month by late 2025. Visa's overall stablecoin-linked card spend reached a $3.5B annualized run rate in Q4 2025. 

All this demonstrates that crypto cards have achieved clear product market fit, offering users an easy way to make everyday purchases with crypto—especially useful for those in jurisdictions where crypto is a more reliable way to make payments.

Reflecting this demand, there are now hundreds of crypto card offerings globally. While all of these operate through Visa or Mastercard infrastructure, there are a few different design decisions underneath, each of which presents the user with trade-offs regarding custody, privacy, and settlement.

Let’s reflect on the size of the crypto card market and take a look at the trade-offs presented by each crypto card design.

The Crypto Card Landscape

Every crypto-linked payment card ultimately does the same thing: lets someone spend crypto-denominated value at a merchant that accepts Visa or Mastercard. The differences are in when custody transfers, where settlement happens, and what's visible to whom.

This breakdown classifies card programs by architecture, specifically three dimensions:

• Custody model: Who holds the user's assets, and when does control transfer?
• Settlement layer: Does settlement happen onchain, offchain, or both?
• Privacy profile: What's exposed, to whom, and at which stage?

Let’s explore some of these models along the lines outlined above.

1. Custodial, Offchain Settlement

Examples: Coinbase Card, Binance Card, Bybit Card, KAST

The user deposits crypto into a custodial account, whether that's an exchange account or a dedicated spending app. The custodian holds the funds from deposit through spend. When the user swipes the card, the custodian converts the selected crypto to fiat on its internal ledger. The fiat amount is routed through Visa or Mastercard rails to the acquiring bank and merchant, identical to any traditional card transaction.

Whether the custodian is a major exchange or a standalone crypto spending app doesn't change the architecture. The custody model, settlement path, and privacy properties are the same.

Custody model: Fully custodial. The user's assets sit with the provider from deposit through spend. The provider controls the keys, manages conversion, and handles all settlement.

Settlement layer: Traditional banking rails. No onchain settlement occurs. The crypto-to-fiat conversion happens within the provider's internal ledger before the transaction touches the card network.

Privacy profile: The provider has full visibility into every transaction: amount, merchant, timestamp, asset converted. The card network (Visa/MC) sees the same data any traditional card issuer would share. Because settlement flows through closed banking systems, settlement volumes, reserve positions, and counterparty relationships are not publicly observable. The privacy exposure here is between the user and the custodian, not between the custodian and the market.

2. Self-Custodial, Onchain-to-Offchain Settlement

Examples: Gnosis Pay, MetaMask Card, Ledger Card (CL Card), Ready Card

The user holds crypto in a self-custody wallet and retains control of their keys until the moment of payment. When a card transaction is initiated, the wallet triggers an onchain transfer that moves funds from the user's wallet to the card program's settlement address. From that point, the transaction follows standard card rails: the card program (or its banking partner) converts the stablecoin or crypto to fiat if needed, routes the payment through Visa or Mastercard, and settles with the acquiring bank.

There's meaningful variation within this category. Some implementations do a straightforward onchain transfer at swipe time. Others use pre-signed authorizations or smart contract escrows that the card program can draw from. These variants have different latency, gas cost, and custody-transfer profiles, but they share the core property: the user retains custody until the card is used, and the user-to-program leg is onchain.

Custody model: Self-custodial until point of payment. The user controls their keys and assets right up until the card transaction is initiated. At that point, custody transfers to the card program or its banking partner for conversion and settlement.

Settlement layer: Mixed. The user-to-program transfer is onchain and publicly visible. The program-to-network settlement is typically offchain through traditional banking rails, though some implementations may settle onchain depending on their banking partner arrangement.

Privacy profile: This is where the architecture creates a direct tension with the product's value proposition. Self-custody wallets market themselves on user sovereignty (your keys, your crypto, your control). But the moment the card is used, several privacy boundaries are crossed. The onchain transfer from the user's wallet to the card program's address is publicly visible, linking the user's self-custody address to a known card program contract. Anyone watching the chain can see the timing and amount. The card network sees full transaction details (merchant, amount, timestamp) as with any card payment. And if the program-side settlement is also onchain, that leg is public too.

3. Pre-Funded Fiat Load

Examples: Various prepaid Visa/Mastercard programs funded via crypto off-ramps (Wirex prepaid mode, some Revolut crypto-to-card flows)

The user converts crypto to fiat before the card is loaded. The off-ramp happens first through an exchange, a DEX-to-fiat bridge, or a P2P sale, and the resulting fiat is deposited onto a prepaid card. From that point forward, the card is a standard fiat prepaid card. There is no crypto involvement at the point of sale.

This is the simplest architecture and the one most often overlooked in crypto card taxonomies, precisely because it doesn't feel like a "crypto card" at all. But it's how a significant number of crypto holders actually spend.

Custody model: Fiat custodial (after off-ramp). The crypto-to-fiat conversion is a separate event from the card usage. Once loaded, the card program holds fiat in a standard e-money or prepaid account. The user's crypto custody model during the off-ramp stage depends on the method used (exchange, DEX, P2P).

Settlement layer: Entirely traditional. The card is a fiat instrument. Settlement between the card issuer and the network is standard banking infrastructure.

Privacy profile: The off-ramp and the card usage are decoupled, which creates an interesting privacy property. The blockchain records the off-ramp transaction (if it was onchain), but there's no onchain link between that off-ramp and any subsequent card purchase. The card network sees standard fiat transactions with no crypto provenance. The main privacy exposure is at the off-ramp itself: if the user off-ramped through a KYC exchange, that exchange knows the user converted crypto to fiat, but doesn't see what the user subsequently buys. If the off-ramp was through a DEX or P2P, even the conversion itself may not be linked to the user's identity.

4. Onchain Settlement Programs

Examples: Rain, Reap

These programs settle the issuer-to-network leg onchain in stablecoins. When a cardholder makes a purchase, the transaction routes through the card network as usual, but behind the scenes, settlement between the card program and its banking or network counterparties happens as stablecoin transfers on public blockchains (Base, Solana, Polygon, Arbitrum, etc.)

Some of these programs hold principal memberships with Visa or Mastercard (settling directly rather than through a sponsor bank), while others operate under a bank's BIN. The principal membership is a licensing distinction. The architectural differentiator is the onchain settlement itself, which could in principle exist under either licensing arrangement.

Custody model: Configurable. Onchain settlement programs can offer both custodial and self-custodial card products depending on the target market and regulatory context. The settlement architecture doesn't dictate the user-facing custody model.

Settlement layer: Onchain stablecoin settlement. This is the defining characteristic. Settlement flows are transfers on public blockchains. Every settlement transaction is permanent and publicly visible.

Privacy profile: This architecture has the most acute privacy exposure on the issuer side. While the cardholder-to-merchant transaction flows through the card network (and is as private as any traditional card payment from the cardholder's perspective), the settlement layer is completely transparent. Competitors, researchers, and the general public can observe settlement volumes, timing, counterparty addresses, and reserve flows. For the card program itself, this means operating with a level of financial transparency that no traditional card issuer faces.

The Onchain Settlement Tradeoff: Custody Vs. Privacy

Traditional card settlement is opaque by design. When a consumer swipes a Visa card at a merchant, the settlement between the issuing bank and the acquiring bank flows through closed systems like Fedwire (US), CHAPS (UK), or SEPA (EU). These settlement networks are visible only to the counterparty institutions and regulators. No competitor can observe another issuer's settlement cadence, reserve position, or transaction volume. This opacity is a structural feature that protects competitive positioning. But when these cards are backed by crypto, users sacrifice custody: while they may be spending with their crypto balance, for all intents and purposes they are transacting as they would with a standard card, meaning they sacrifice financial autonomy and give spending data to their card issuer.

Onchain settlement inverts this entirely. For full-stack issuers now settling onchain (e.g., Rain on Base, Solana, Polygon, and other networks), the settlement transactions are fully public. Anyone monitoring the chain can observe in real time:

• Which issuers are settling with Visa and on what cadence: daily, weekly, or otherwise.
• Reserve movements that signal operational decisions before they are made public; such as capital raises, liquidity crunches, or volume spikes.
• The exact amounts flowing between issuer wallets and Visa settlement addresses, revealing program-level economics.
• Counterparty relationships that disclose which blockchain networks and stablecoin reserves an issuer relies on.
• Competitive benchmarking by rivals who can reconstruct an issuer's growth trajectory, market share, and unit economics from public data alone.

The same challenge exists with non-custodial cards that are linked to wallets. With crypto often swapped for fiat often on a per-transaction basis, analytics sites have begun to provide dashboards of live crypto card transactions, even assigning a potential spending category to each one. This is even more exposure than just sending a transaction from your wallet to another address: at least then the address is not often linked to a shop or business.

The Compliance Squeeze

A plethora of privacy solutions have sprung up to solve the issue of onchain transparency. These could be integrated into the flow by providers of cards that are non-custodial or those which settle onchain. 

However, many of these solutions take an all-or-nothing approach. While great for privacy, many users require a level of disclosure. Businesses might need to show a regulator or auditor transactions; the same goes for employees spending on a company card. 

Solutions like Inco can provide selective disclosure, with crypto card issuers able to build third-party disclosure mechanisms into their designs that users can then leverage. For a detailed treatment of how privacy and compliance coexist in blockchain-based financial systems, refer to Inco's compliance research report published in partnership with Predicate.

Types of Privacy

There are various forms of privacy that are useful to keep in mind for both users and issuers.

Conventional public blockchains operate on the principle of pseudonymity. Everything is public and transparent, but most addresses are simply hashes, meaning identities are not know by default. However, many analytics companies and onchain sleuths tie these addresses back to identities, so as soon as your address is known, so is everything else about you.

Confidentiality involves addresses being public but transaction data being public. For many use cases, including crypto card payments, this can be enough. People might know you’re transacting, but they won’t be able to see how much or what you’re buying, although they will be able to see who you’re buying from. 

Anonymity involves keeping addresses private while everything else stays public. People can see that funds are being transferred, but they can’t know the parties.

Finally, total privacy combines confidentiality. No details are known at all.

Each of these levels presents its own tradeoffs regarding privacy, useability, and compliance processes. Card providers need to work out the level that’s right for them and their users and make sure their chosen solution. Some solutions, like Inco, can provide each level of privacy along with customization around decryption rules and computation upon encrypted data without decryption, so companies can retain compliance and operational flexibility..

Why Each Party Needs Privacy

Privacy is important for every party involved in crypto card transactions, but for different reasons.

Cardholders don't want their spending history, balances, or financial behavior publicly observable. On a transparent blockchain, anyone can profile a wallet's activity, infer income from balances, or track spending patterns across merchants. Cardholders want at minimum the same baseline privacy they already get from a traditional debit card, where their bank sees their transactions but the general public doesn't.

Merchants don't want competitors seeing real-time sales volume, average transaction sizes, supplier payments, or customer traffic patterns. If payment or settlement flows happen onchain, a competitor can watch a merchant's receiving address and reconstruct peak hours, seasonal trends, and revenue run rate. Traditional card settlement is closed precisely because this data is commercially sensitive.

Issuers don't want their settlement volumes, reserve positions, counterparty relationships, or margin structures exposed to every competitor, analyst, and journalist watching the chain. No traditional card issuer operates under that level of transparency. At the same time, they need to offer privacy to cardholders and merchants as a product feature while maintaining the ability to selectively disclose data to regulators. They aim to balance privacy with controlled disclosure. Some issuers who have prioritized privacy have done so by forgoing KYC (Know Your Customer) processes: this puts them and their customers in a regulatory grey zone (or worse).

Card networks don't want onchain settlement layers creating compliance gaps or data leakage that undermines the trust model merchants and banks already rely on. 

Stablecoin issuers don't want mint and redemption flows becoming free signals for speculators. A large card program redeeming $50M in USDC is visible on a transparent chain and could be read as a shift in settlement strategy or a liquidity event.

The most important and demonstrable consideration here is that of users: the popularity of solutions like Payyy shows that privacy is a real attractor for consumers, and is therefore something that every other party should work towards.

Conclusion

The future of crypto cards is bright, representing a key area for adoption. While the current market is mostly those in jurisdictions where crypto payments are more practical than fiat offerings or crypto-native users, more and more companies are leveraging stablecoins, making cards that settle onchain increasingly practical. Privacy is currently a key issue to address, but privacy solutions like Inco present a clear path forward.

If you’re a crypto card issuer exploring how to integrate privacy into your architecture, please get in touch.