---
title: "How to give every neobank customer their own US bank account details"
seoTitle: "Give every neobank customer US bank account details"
description: "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."
date: "2026-10-09"
updated: "2026-10-09"
category: "payments"
author: "BlindPay Team"
howto:
  name: "How to give a neobank customer their own US account details with BlindPay"
  steps:
    - name: "Collect terms of service acceptance"
      text: "Send the user to BlindPay's hosted terms of service page. When they accept, your redirect URL receives a tos_id and a tos.accept webhook fires."
    - name: "Create the customer and run KYC"
      text: "Create the customer with the tos_id and identity data. Wait for kyc_status to reach approved before you request any account."
    - name: "Fill the account compliance fields"
      text: "Make sure account_purpose and source_of_wealth are set on the customer. Businesses also need industry, revenue band, and owner details."
    - name: "Link the settlement wallet"
      text: "Add the blockchain wallet where deposits will settle as USDC or USDT. It must belong to the same customer."
    - name: "Create the virtual account"
      text: "Request a US virtual account for the customer. It starts in pending_review, moves to verifying, then approved or rejected."
    - name: "Show the account details screen"
      text: "When virtualAccount.complete fires, read the routing and account numbers from the payload and show them in the app, with a copy button per field."
    - name: "Credit each deposit"
      text: "Every incoming transfer creates a payin. Credit the user's balance in your ledger from the payin webhooks, keyed by payin ID."
faq:
  - q: "Can a neobank give users a US bank account without a banking license?"
    a: "Yes, through a provider that issues virtual accounts with a banking partner. With BlindPay, each user gets a US account in their own name with its own routing and account number, after KYC and a compliance and bank review. Your own licensing still depends on what your product does with the money, so check that with counsel separately."
  - q: "Is a virtual account a real bank account?"
    a: "For the payer, yes. A BlindPay US virtual account has bank-issued routing and account numbers, and anyone can send ACH, wire, or SWIFT to it like any other account. For your user, the deposit does not sit there as a bank balance: each deposit becomes a payin that settles to their linked wallet as USDC or USDT."
  - q: "How long does it take to issue a US account to a user?"
    a: "On BlindPay the issuance SLA is 24 hours for the US account type that serves individuals and businesses with US and foreign senders. The two business account types, split by US senders and foreign senders, take 3 to 5 business days. Approval is not guaranteed at either the compliance stage or the bank stage, so design a rejected state."
  - q: "What does a US virtual account cost per user?"
    a: "BlindPay charges $1.50 per month per US virtual account. Deposits create payins: the BlindPay fee on a deposit below $100.00 accrues to your monthly invoice, and on a deposit of $100.00 or more it is charged at the time of the transaction and deducted from the delivered amount. US virtual accounts are part of the Business plan."
  - q: "Whose name is on the account?"
    a: "The customer's. BlindPay issues US virtual accounts in your customer's own name, and payouts originating from an account issued to an end user are sent under that user's name rather than a pooled account name. That matters for payers who check the beneficiary name and for originator information rules on the rails."
  - q: "Can I test the account details screen before going live?"
    a: "Yes. On a BlindPay development instance, virtual accounts skip both reviews and are created directly as approved. The routing number is always 110000000 and the account number is a fake 12-digit number derived from the account ID. They let you build the screen and webhook handling, but no real bank recognizes them."
---

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](/resources/more/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](/resources/more/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](/resources/more/neobank-kyc-kyb-onboarding-flow) 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](/resources/more/virtual-account-requirements-kyc-kyb) page lists what the bank reviews.

### Which US account type fits your users?

| Account type | Deposit methods | Senders | Issuance SLA | Price |
| --- | --- | --- | --- | --- |
| US, individuals and businesses | ACH, Wire, SWIFT | US and foreign | 24 hours | $1.50/month |
| US, businesses with foreign senders | ACH, RTP, Wire, SWIFT | Foreign only | 3 to 5 business days | $1.50/month |
| US, businesses with US senders | ACH, Wire, SWIFT | US only | 3 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.

| Status | What the user sees | What 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`. |
| `approved` | Routing number, account number, account holder name, bank name and address, copy buttons | Stores the numbers, enables deposit notifications |
| `rejected` | "We couldn't open a US account for you." Plus the next step you offer | Logs 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 sees | BlindPay term | Notes |
| --- | --- | --- |
| My US account | Virtual account (`va_...`) | One customer, one settlement wallet |
| Deposit received | Payin (`pi_...`) | One payin per incoming transfer |
| Send money to a bank | Payout | Quote first, then execute |
| Account holder | Customer (`re_...`) | Must be KYC approved |
| Balance | Wallet balance, mirrored in your ledger | Stablecoin behind the screen |
| Transfer fee | Fee fields on the payin or quote | Never hardcode a number |

[Banking terms vs blockchain terms](/resources/more/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 amount | Where the BlindPay fee lands | Payin field |
| --- | --- | --- |
| Below $100.00 | Your monthly invoice | `billing_fee_amount` |
| $100.00 or more | Deducted at the time of the transaction | `transaction_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](/pricing). [Virtual account fees](/resources/more/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](https://www.fdic.gov/news/fact-sheets/crypto-fact-sheet-7-28-22.html) it does not insure assets issued by non-bank entities, such as crypto companies. Settled funds are stablecoin.
- **Promising instant arrival.** [ACH](https://www.federalreserve.gov/paymentsystems/fedach_about.htm) moves in batches between banks, and even [Same Day ACH](https://www.nacha.org/content/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](/resources/more/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](/docs/virtual-accounts) show each status, and [create a virtual account](/docs/virtual-accounts-create) lists the required fields.