How to give every neobank customer their own US bank account details

Build the flow that gives each neobank user a routing and account number in their own name: KYC, virtual account statuses, the details screen, and costs.

To give every neobank customer US bank account details, issue each verified user a virtual account: a US account in their own name with its own routing and account number. With BlindPay, each deposit to that account becomes a payin that settles to the user's wallet as USDC or USDT, and your app shows it as a dollar balance.

This page is the product build: who qualifies, the order of API calls, what the account details screen shows in each status, and what it costs per user. For where this sits in the whole product, start with how to build a neobank.

Key takeaways

  • A US virtual account gives each user a routing and account number in their own name. Payers see a normal US account.
  • KYC comes first. On BlindPay the customer must be approved before you can request an account.
  • Accounts go through a compliance review and a bank review. Design four screen states, not one.
  • US virtual accounts cost $1.50 per month per account on BlindPay, plus a fee per deposit that lands on your invoice or in the transaction depending on size.
  • Don't call the balance "FDIC insured". The user's money settles as stablecoin in a wallet.

What does "a US bank account in the app" mean for a neobank?

It means the user can hand out real US account details and get paid in dollars. They don't open an account at a branch, and you don't run a bank.

A virtual account is a set of bank account numbers issued by a banking partner through a provider, assigned to one customer, whose incoming transfers are tracked to that customer. On BlindPay, a US virtual account has its own routing and account number, accepts ACH, wire, and SWIFT, and settles every deposit as USDC or USDT to the wallet linked at creation.

For a neobank user, the result looks like this: a freelancer in Brazil gives a US client a routing number and account number, the client pays by ACH, and the freelancer's app shows the dollars a few days later. The stablecoin layer sits behind the balance. Stablecoin neobank vs traditional neobank covers that trade in full.

Who can get account details, and what do you need first?

Any customer who has accepted BlindPay's terms of service, passed KYC, and has the account compliance fields filled in. The order is fixed.

  1. Terms of service. The user accepts on BlindPay's hosted page. Your redirect URL receives a tos_id, and a tos.accept webhook fires.
  2. KYC approved. The customer's kyc_status must be approved. You can't request an account while KYC is still in review. Neobank KYC and KYB onboarding covers the screens.
  3. Compliance fields. Individuals need account_purpose and source_of_wealth. Businesses also need business type, description, industry (a NAICS code), estimated annual revenue, and at least one owner with ownership percentage and title. Sole proprietors attach a supporting document, such as a bank statement.
  4. A settlement wallet. A blockchain wallet that belongs to the same customer. USDT settlement needs the wallet on Polygon, Ethereum, or Solana.

The account review can ask for more, including source of funds documents. The virtual account requirements page lists what the bank reviews.

Which US account type fits your users?

Account typeDeposit methodsSendersIssuance SLAPrice
US, individuals and businessesACH, Wire, SWIFTUS and foreign24 hours$1.50/month
US, businesses with foreign sendersACH, RTP, Wire, SWIFTForeign only3 to 5 business days$1.50/month
US, businesses with US sendersACH, Wire, SWIFTUS only3 to 5 business days$1.50/month

A consumer neobank serving freelancers and remote workers usually starts with the first type. A business neobank picks by who pays its customers.

How do you build the flow from sign-up to account details?

Seven steps, and most of the waiting happens in steps 2 and 5.

  1. Show the terms of service and capture the tos_id.
  2. Create the customer with identity data, then wait for customer.update with an approved KYC status. BlindPay's automated KYC Standard typically finishes in about 60 seconds.
  3. Ask the account questions (purpose, source of wealth) in-app and write them to the customer.
  4. Add the settlement wallet.
  5. Create the virtual account. Store the va_... ID against your user ID.
  6. Listen for virtualAccount.complete. The payload carries the routing and account numbers, plus SWIFT and receiving bank details once approved.
  7. Render the account details screen and start crediting deposits from payin webhooks.

Create step 5 with an Idempotency-Key header, so a retried request after a timeout can't create a second account for the same user. A customer can hold more than one account on purpose; your retry logic should never create one by accident.

What should the account details screen show in each status?

Four states, mapped to BlindPay's account statuses. Users who see "Pending" with no explanation open support tickets.

StatusWhat the user seesWhat your backend does
pending_review"We're reviewing your account. Most reviews finish within a day."Waits. Shows the SLA for the account type.
verifying"Approved by compliance. Waiting for the bank."Waits for virtualAccount.complete.
approvedRouting number, account number, account holder name, bank name and address, copy buttonsStores the numbers, enables deposit notifications
rejected"We couldn't open a US account for you." Plus the next step you offerLogs the rejection, routes to support

On the approved screen, show the account holder as the user's legal name, exactly as KYC captured it. Payers type that name into their bank, and a mismatch is a common reason for a held wire. Show SWIFT details on a separate tab labeled "Receiving from outside the US", so domestic payers don't pick the wrong one.

How do banking terms map to BlindPay terms?

Your app speaks banking. The API speaks payments. Keep a map in your codebase so product and engineering use the same words.

What the user seesBlindPay termNotes
My US accountVirtual account (va_...)One customer, one settlement wallet
Deposit receivedPayin (pi_...)One payin per incoming transfer
Send money to a bankPayoutQuote first, then execute
Account holderCustomer (re_...)Must be KYC approved
BalanceWallet balance, mirrored in your ledgerStablecoin behind the screen
Transfer feeFee fields on the payin or quoteNever hardcode a number

Banking terms vs blockchain terms has the longer translation table.

What does it cost to give every user an account?

$1.50 per account per month on BlindPay, plus a fee per deposit. Where the deposit fee lands depends on size.

Deposit amountWhere the BlindPay fee landsPayin field
Below $100.00Your monthly invoicebilling_fee_amount
$100.00 or moreDeducted at the time of the transactiontransaction_fee_amount

Illustrative example. A neobank issues accounts to 2,000 users. Account cost is 2,000 × $1.50 = $3,000 a month, before deposit fees. If 1,200 of those users are active, the cost per active account is $3,000 ÷ 1,200 = $2.50. That ratio is why many teams issue the account at a moment of intent (first invoice, first employer) rather than at sign-up. US virtual accounts are part of BlindPay's Business plan, listed on pricing. Virtual account fees covers what the payer's bank may charge.

Common mistakes

  • Requesting the account before KYC is approved. The request fails. Gate the button on kyc_status.
  • Leaving compliance fields blank. The API rejects the request with missing_required_fields. Ask the questions in onboarding.
  • One screen for every status. Design pending, verifying, approved, and rejected states.
  • Calling the balance insured. The FDIC says it does not insure assets issued by non-bank entities, such as crypto companies. Settled funds are stablecoin.
  • Promising instant arrival. ACH moves in batches between banks, and even Same Day ACH means within hours, not seconds. BlindPay documents up to 5 business days for ACH and wire payins.
  • Testing with development numbers in production copy. The development routing number 110000000 is fake.

How BlindPay fits

BlindPay issues US virtual accounts in each customer's own name, with individual routing and account numbers that accept ACH, wire, and SWIFT. Every deposit creates a payin that BlindPay converts and sends as USDC or USDT to the wallet you linked, so your app credits a dollar balance without building a bank integration.

KYC, KYB, and sanctions screening run in the same API before an account is requested. A two-stage review (compliance, then the bank) sets the account to approved, and the virtualAccount.complete webhook hands you the numbers to display. Payouts that originate from an account issued to an end user go out under that user's name.

Accounts cost $1.50 per month each, and deposit fees show up on the payin itself. On a development instance, accounts are approved instantly with test numbers, so you can build the whole screen flow before production. See what is a virtual account for the basics.

What to do next

Create a development instance and run the seven steps above for one test user, ending on the approved account details screen. The virtual accounts docs show each status, and create a virtual account lists the required fields.

FAQ