What you need to open a virtual account: KYC or KYB, the extra fields and source of funds documents the bank reviews, who owns each step, and timelines.
To open a virtual account, the account holder first passes KYC (for individuals) or KYB (for businesses). Then the provider and its bank review the account itself: what it's for, the industry code, expected revenue, who owns the business, and where the money comes from, backed by documents like bank statements or tax returns. Plan for two reviews, not one.
Most delays come from treating the second review like a formality. It isn't.
A named virtual account is a set of bank details issued in your customer's name, so the bank behind it needs to know who that customer is and what the account is for. US anti-money laundering rules require exactly that. The provider runs the process for you, but it can't skip it. (New to how these accounts route into a master account? Start with what is a virtual account.)
Two FinCEN rules do most of the work. The customer identification program (CIP) rule requires banks to collect, at minimum, a customer's name, date of birth for individuals, address, and identification number, and to verify identity (FDIC summary). The customer due diligence (CDD) rule adds beneficial owners: each person who owns 25% or more of a legal entity, plus one person who controls it, such as a CEO or managing member. It also requires understanding the nature and purpose of the relationship and monitoring it over time. That's where the account purpose and revenue fields come from.
One recent change: in February 2026, FinCEN granted relief from re-verifying beneficial owners each time an existing legal entity customer opens a new account. Verification still happens at the first account, when earlier information looks unreliable, and under risk-based procedures. Providers and banks can still ask for more under their own policies, and how any of this applies to your platform is a question for counsel.
KYC (know your customer) verifies an individual: name, date of birth, address, government ID, and often a selfie. KYB (know your business) verifies a company: that it legally exists, where it's registered, and which people own or control it. For a business, KYB includes KYC on each beneficial owner.
| Check | Who it covers | Typical documents |
|---|---|---|
| KYC | Individuals, and every owner of a business | Government ID (passport, ID card, or driver's license), proof of address under 90 days old, selfie, tax ID |
| KYB | Businesses | Articles of organization or certificate of incorporation (all pages), share register showing owners and percentages, proof of business address under 90 days old |
| Account review | The virtual account itself | Account purpose, industry code, revenue band, source of funds and source of wealth documents |
The third row is what most teams miss. BlindPay's KYB document list states it directly: virtual account requests go through a separate evaluation with their own documentation, on top of KYB.
The bank reviews the expected activity of the account: why it exists, what business it serves, how much money will move, and where that money comes from. Deposits that later don't fit that baseline are what trigger holds.
| Field or document | Individual (sole proprietor) | Business | Why the bank asks |
|---|---|---|---|
| Account purpose | Required | Required | Sets the expected use, such as collecting client payments or treasury |
| Industry code (NAICS) | No | Required | Must match the activity in the incorporation documents |
| Business type and description | No | Required | Confirms the legal structure and what the company sells |
| Estimated annual revenue | No | Required | Gives a volume baseline for monitoring |
| Source of wealth | Required | Required | How the owners built their wealth: earnings, prior ventures, investments |
| Source of funds documents | A supporting document with the request: service agreement, salary slip, or bank statement | Bank statements, financials, tax returns, contracts, or invoices | Proves where the money flowing into the account comes from |
| Owners, percentages, and titles | No | At least one owner | Identifies who benefits from and controls the account |
| Publicly traded flag | No | Required | Listed companies carry a different risk profile |
Source of funds and source of wealth sound alike. They aren't. Source of funds is where this money comes from (client payments, operating revenue, investment capital). Source of wealth is how the business or its owners got their money in the first place. Accepted documents for each are in BlindPay's virtual account requirements and source of funds guide.
All three, for different parts. You know your customer and collect their information. The provider verifies identities, reviews each account, and monitors transactions. The bank makes the final call on every account and can ask for more.
| Party | What it owns |
|---|---|
| You (the platform) | Collecting accurate customer data and documents, getting terms accepted, answering information requests on time, and keeping each account's money tied to that customer |
| The provider | KYC and KYB review, the compliance review of each virtual account, transaction monitoring, and holds |
| The bank | Final approval, extra document requests, and the right to reject an application |
One line is worth reading twice. At BlindPay, information requests go to your team, not to your customer: collecting the documents is your job as the partner (information requests). If your customer doesn't reply, you're the one holding the deadline.
The other line is about whose money it is. A virtual account should only receive money that belongs to the customer it was issued to. Using one customer's account to collect for that customer's own clients, who were never onboarded, is called nesting, and it gets accounts frozen. BlindPay's rule and quick test are in nested payments.
Approval is not the end. Every deposit gets checked against what the customer declared, so expect transaction monitoring, sanctions screening on the parties involved, and periodic reviews of the customer file.
At BlindPay, a deposit flagged by transaction monitoring lands on_hold. If compliance can't clear it internally, you get a request for the relationship between sender and customer, the purpose of the payment, and its expected outcome. If that request isn't answered within 24 hours, the deposit may be returned to the sender (on-hold transactions).
Customer files get revisited too. A request on an approved customer can run without pausing them (approved_rfi), while a blocking request (compliance_request) stops payins and payouts until you respond. Either way you have 27 days, with reminders on days 7 and 17. A blocking request that's still unanswered on day 27 rejects the customer automatically.
Mismatches and silence cause most of it: one document contradicts another, a document is stale, or a request goes unanswered. BlindPay publishes its rejection reasons, and the fixable ones repeat:
Delays have one extra cause: when the bank asks for more documents during its review, the SLA clock restarts from the day you submit them. Companies in higher-risk sectors, including money services, fintech, and digital assets, should also expect enhanced due diligence and more document requests.
Automation removes the back-and-forth, not the review. Collect the account review fields during onboarding so the request goes in complete, and catch bad files before a human sees them. The sequence that avoids rework:
pending_review).verifying).approved), the account details are issued, and you share them with payers.Two features help at steps 4 and 5. BlindPay's API rejects an account request with missing_required_fields, naming each blank field, so validation can happen in your form instead of a review queue. And a document analysis endpoint returns a low, medium, or high approval rate for a file, so you can ask for a better scan before it's submitted (KYC requirements). For the broader picture of software running these checks, see compliance agents in fintech.
Here's an illustrative example. The company, names, and dates are made up. The fields and stages are real.
Harbor Code LLC is a US software studio that builds apps for US clients and wants a virtual account for incoming ACH and wire payments, settled to USDC. It has two owners, both US residents: Ana owns 60% and is managing member, and Ben owns 40%.
What it fills in:
What it uploads: all pages of the articles of organization, an operating agreement showing the 60/40 split, a utility bill for the office dated last month, ID and proof of residence for both owners, the last 3 months of business bank statements, and two signed client contracts.
Illustrative timeline:
| Day | What happens |
|---|---|
| Monday | Customer created. KYB enters manual review |
| Tuesday | KYB approved. Account request submitted, pending_review |
| Wednesday | Compliance approves, verifying (bank review begins on a 3 to 5 business day SLA) |
| Following Monday | The bank asks for a signed copy of one client contract. Harbor uploads it the same day and the SLA clock restarts |
| Following Thursday | Bank approves, approved. Routing and account numbers are issued |
Ten days, end to end, and the restart after one unsigned contract added about three of them. An industry code like "financial services" would have been worse: a mismatch with the articles is a listed rejection reason.
BlindPay issues US virtual accounts in your customer's own name. They receive ACH, wire, and SWIFT, depending on account type, and deposits settle as USDC or USDT to a wallet you link. Each account costs $1.50 per month and goes through compliance review, then bank review, with SLAs of 24 hours or 3 to 5 business days by account type.
The requirements are public: create a virtual account lists the required fields, and the virtual account requirements list the documents. Development instances approve accounts instantly, so you can build onboarding before any real review. If you're still deciding whether a virtual account fits next to your existing bank, see can a virtual account replace a bank account.
Take the field table above and add every row to your onboarding form today, marked required by customer type. Then create a test customer on a development instance and request an account with create a virtual account. If the API returns missing_required_fields, your form is missing something.
This article is for general information only and is not legal, tax, or financial advice.
Stablecoin transfers settle final in minutes and cannot be reversed. That finality proves custody at every step, but it also opens a fraud gap on the fiat side of the payment.
A side-by-side comparison of automated and manual KYC/KYB for fintechs: onboarding time, false-positive rates, cost per verification, scaling across jurisdictions, and audit-trail quality, plus the cases where a human reviewer is still required.
How compliance agents apply FinCEN, MiCA, FCA, MAS, and Banco Central do Brasil rules to cross-border stablecoin payments: jurisdiction table, the FATF Travel Rule, multi-list sanctions screening, the four components of a compliant program, and questions to ask a compliance provider.