Fintech apps and neobanks

Stablecoin wallets for fintech apps and neobanks

A wallet per user on every network, deposits that land once they're final, withdrawals under velocity limits, and keys in verifiable hardware enclaves.

Customers of fintech apps and neobanks increasingly ask to hold dollars as stablecoins, receive them from abroad, or send them to a friend's wallet. Adding that to an app means a wallet for every user, deposits that show up reliably, withdrawals under strict limits, and a ledger your finance team can trust, all without turning your engineering team into a custody team.

What an app needs

  • A wallet per user, created on sign-up or the first time they open "Receive".
  • Deposits that appear as "on its way", then land once they're final.
  • Withdrawals to outside addresses that are fast for normal amounts and stopped for unusual ones.
  • Balances from your ledger, consistent with what's actually held.

How it runs on Valtu

  • One call per user gives them addresses on every supported network: one EVM address for Ethereum, BNB Chain, Polygon, Base and Lisk, plus Tron and Bitcoin. Your user id is the wallet's externalId.
  • Deposits arrive as deposit.pending (show it as on its way) and deposit.confirmed (credit it, once). See finality.
  • Withdrawals go out from an operational hot wallet with your withdrawal id as externalId. Reserve the amount in your ledger before calling the API, and settle or release it when the webhook says CONFIRMED, FAILED, REJECTED or CANCELLED.
  • Sweeps collect user deposits into treasury, and a gas wallet pays the fees, so users never need a network's own coin to move their stablecoins.

Protecting users and the business

  • Velocity rules on the hot wallet, such as a maximum per hour and per day, plus approval above a per-withdrawal limit. See approval policy.
  • Screening of withdrawal destinations and deposit senders with your own KYT provider.
  • Address safety: only real token contracts are credited, so fake tokens sent to users' addresses are ignored. See address poisoning.
  • Keys generated and used only in hardware enclaves, with the running code verifiable through remote attestation.

In the app

  • Show the network next to every address and in every withdrawal form, and only offer the networks you support.
  • Show a deposit as pending until it's confirmed, and the network fee before a withdrawal is confirmed: the transfer preview returns it.
  • Keep keys on your servers. API keys never belong in a mobile app.

Rolling it out

  1. Start on testnets. Every workspace starts there with free test coins, the same dashboard and the same API.
  2. Launch with one coin on one or two networks, for example USDC on Base and USDT on Tron, so support has fewer cases to learn.
  3. Begin with low limits on withdrawals and raise them as you see real behaviour.
  4. Add networks and coins once deposits, withdrawals and reconciliation run without surprises.

Good to know

  • Supported networks and coins: the networks page.
  • Offering stablecoin balances may need a licence where you operate; that stays with you.
  • The external security audit isn't done yet; see the security page.

Build the deposit side with FastAPI, Django or Express.

Other use cases

Other ways teams use Valtu.

Tell us what you're building.

Start on testnets with free test coins, or talk to the team about your flows, networks and controls.