Solana neobank: how to start — architecture, phases, three patterns
How to start a neobank on Solana: working definition, architecture, custody patterns, phased build with exit criteria, and three reference systems — Backpack, Avici, and Rain — as systems not ads.
devrels.xyz/a/192short linkMost teams that say they want a “neobank on Solana” already have a wallet, an exchange, or a fintech wedge. What they lack is a precise definition of the system — and a build order that does not put yield ahead of reconciliation.
Solana neobank: how to start — for technical founders and senior engineers designing account products. Objective: a working definition, an architecture you can defend, a phased plan with exit criteria, and a clear read on three reference patterns (Backpack, Avici, Rain) as systems, not endorsements.
Companion: Crypto cards: landscape and product integration.
Context: what problem you are solving
Users want ordinary money verbs — hold, move, spend, sometimes earn — with a brand they trust. Solana can carry the cash leg (typically USDC) with fast settlement and programmable custody. The regulated edges (KYC, fiat ramps, card schemes) still sit with partners. The product is the orchestration that makes those pieces feel like one account.
If that context is wrong for you — pure protocol research, no consumer account — stop here. The rest assumes you own a customer relationship and a compliance boundary.
Architecture without ambiguity
Mobile and web talk to your API. Behind it: KYC, wallet/custody, double-entry ledger, ramp webhooks, card program manager webhooks, background workers, and Solana (ATAs, PDAs, indexer, transaction sender). The breadcrumb is intentional: every balance-changing event must be explainable as ledger entries plus, where relevant, a signature or a partner reference.
Invariant. The product ledger is source of truth for what the app shows; the chain is source of truth for tokens. Drift between them is not a cosmetics bug. It is a halt condition for new money features.
Custody chooses your constraints
Three patterns dominate. Non-custodial accounts keep keys with the user and push complexity into authorization latency and recovery UX. Embedded or MPC wallets improve UX and share control — legal analysis required. Custodial exchange-style systems use omnibus wallets and an internal ledger; cards debit the ledger while treasury rebalances USDC. None is universally “more Solana.” Each is a different risk and ops surface.
On-chain, prefer transfer_checked on USDC, idempotent ATA creation, dedicated fee payers, simulation before send, and an indexer that credits deposits without relying on the client to report them. Card authorization mode — optimistic versus wait-for-finality — is a configuration with metrics, not a hope. Detail on the card hot path: crypto cards guide.
A reasoned build order
Phase 0 fixes legal entity and geo: who is the regulated party? Phase 1 stands up KYC and account states. Phase 2 locks custody and USDC accounts. Phase 3 integrates one ramp your own team has used with real funds. Phase 4 ships transfers with ledger↔signature linkage. Phase 5 adds virtual cards, auth workers, and daily reconciliation against the program manager. Phase 6 is earn — only after recon has been clean and support can freeze cards without engineering. Phase 7 is multi-geo: new issuer program rows, not a boolean flag.
Exit criteria keep the trail honest: inbound USDC hits the ledger within SLO; auth p99 meets the PM contract; unexplained recon delta is zero for consecutive days; support exports history without a deploy. Skip criteria and the arc collapses into an advert for features you cannot operate.
Three reference systems
Backpack centers exchange and wallet. The account already holds trading and custody complexity; spend attaches as a partner rail (industry maps point at principal-member style issuance such as Bolt-class partners). The engineering lesson is modularity of a unified account — not a mandate to build a full venue on day one. backpack.exchange.
Avici centers spend-without-selling: credit against crypto collateral, self-custody posture, cards as the human interface. The deep system is LTV, oracles, liquidation, and auth checks before the scheme hears approval. That is a different center of gravity from an exchange order book — and a different staffing plan. avici.money · docs· Avici CLI/MCP article.
Rain centers L3: multi-tenant card and stablecoin payment APIs on licensed issuance. Most teams should read this as the default attachment point — own brand, ledger, and risk (L4/L5); rent BIN and scheme access. Concentration of crypto-card volume on a small set of rails is the practical argument, not a slogan. raincards.xyz.
Choose by fit to your wedge and existing trust, not by which homepage is loudest. Traders and KYC already in-house → super-app modular path. Consumer spend story → credit/collateral depth. Platform adding spend → rent L3.
Resources
Bottom line
A Solana neobank is not a whitepaper category. It is a ledger-backed account product with a USDC cash leg and rented connections to KYC, fiat, and cards. Define the layers, pick custody on purpose, sequence phases behind measurable gates, and treat partner failure as a designed state. Do that, and “neobank” stops being a pitch and becomes an operable system.
Keep reading
When a card program fails, the app often keeps working. Design for that: name the layers, pick a funding model, and build L4 as an event-driven payments system.
Install the Avici CLI or point MCP at https://mcp.avici.money/setup. Your agent can answer “what’s my balance?” and “what did the card spend?” — it cannot send, swap, or withdraw.
Sphere Labs sells SpherePay: one REST API for moving money between USD/EUR/BRL bank rails and USDC/USDT/EURC on Solana and other chains. The Solana-native bank API with PIX, Offloader Wallets, and Onramper virtual accounts. Integration model, code shapes, and honest caveats.
Get new articles in your inbox
Technical deep-dives on Solana tooling, infrastructure, and ecosystem. No noise.
