How to offer US bank accounts to non-US residents
- Most fintechs give non-US users US bank details through named USD virtual accounts from a provider, not one-off bank accounts
- Each user gets account and routing numbers in their own name for ACH and wire, plus SWIFT details for payers outside the US
- Due issues USD virtual accounts through one API, with KYC, eligibility checks and settlement to USDC or local currency built in.
To offer US bank accounts to non-US residents, most fintechs do not open a bank account for each user. They issue named USD virtual accounts through a provider that already holds the US bank relationships. Each user gets a unique account number and routing number in their own name, so US payers can send them ACH and wire transfers.
Due provides this through a single API, alongside USD SWIFT details, KYC and KYB, and conversion to stablecoins or local currency.This guide explains what US account details mean for international users, why banks hold back, the three setups platforms use, and how to launch.
What a US bank account means for your non-US users
For a user outside the US, a "US bank account" usually means a set of receiving details rather than a full banking relationship. Those details need to work for a US payer, marketplace or payroll platform. In practice, international users need four components:
- Account number and ABA routing number. Together, these let US payers send domestic ACH and wire transfers. Our routing number guide explains how the nine-digit identifier works.
- An account name that matches the user. Payroll and marketplace platforms often verify that the payee name matches the account holder.
- Bank name and address. Domestic wire forms typically require both.
- SWIFT details, where relevant. Payers outside the US cannot originate domestic ACH payments, so they need a SWIFT route to send USD.
Each inbound rail suits a different type of payer. The table shows who uses each rail and the settlement times listed in Due's supported payment methods.
If most of your users get paid by US platforms, ACH and wire details cover the majority of inbound volume. If users invoice clients in Europe, Asia or Latin America, add SWIFT details as well. Our ACH vs SWIFT comparison covers the cost and speed trade-offs.
Why non-US residents struggle to open US bank accounts
No federal rule stops non-US persons from holding US bank accounts. The real barrier is the compliance work and risk each account brings, and at retail scale most banks decide it is not worth it. Four requirements drive that choice.
- Identity checks. Under the customer identification program rule, a bank can accept a passport number and country of issuance from a non-US person instead of a US taxpayer ID. It still has to verify that identity, even when the customer never visits a branch and brings documents the bank does not know well.
- Tax forms. Foreign individuals give financial institutions and payers Form W-8BEN to certify their foreign status for US withholding and reporting, while entities use Form W-8BEN-E. Banks must collect, check and store these forms.
- Sanctions and country risk. Banks screen customers and payments against OFAC sanctions lists, and providers add their own country restrictions on top. Due's geo-coverage policy, for example, lists 25 places it cannot onboard, including Iran, Lebanon, Venezuela and Zimbabwe.
- International payment flags. Nacha classifies ACH entries involving a financial institution outside the US as International ACH Transactions, which carry data on every party so banks can screen them for sanctions.
For a platform, this means you cannot simply send users to a US bank's website. You need a partner that already handles verification, tax documentation and screening for non-US customers, at a cost per account that makes sense for your users' balances.
Three ways to give international users US account details
Platforms generally use one of three structures. They differ in whose name payers see, who holds the bank relationship, and how much compliance work stays with you.
1. A direct sponsor bank program. You contract with a US bank, usually through a banking-as-a-service arrangement. You get the most control over account design, but you also take on the bank's due diligence, program oversight and audits. Many sponsor banks also limit how many non-US users they accept.
2. A pooled FBO account with your own ledger. The bank opens one FBO account in your platform's name, held for the benefit of your users. You track each user's balance in your own ledger. Users either share one set of details plus a reference code, or receive sub-account numbers that route into the pooled account. Payers see your platform's name rather than the user's.
3. Named virtual accounts from an infrastructure provider. The provider holds the bank relationships and issues each user unique account and routing numbers in that user's own name. Onboarding, sanctions screening and deposit attribution run through the provider's API, while you keep the customer relationship and product experience.
A direct program makes sense once you have the transaction volume and compliance team to support your own bank relationship. Pooled FBO accounts suit closed-loop products, where users mostly move money within your application. Named virtual accounts fit best when users share their details with outside payers, such as clients, marketplaces and payroll platforms.
What the Synapse collapse changed for pooled US accounts
The 2024 bankruptcy of Synapse, a middleware provider between fintechs and their partner banks, showed what happens when fintech ledgers and bank records stop matching. FDIC Vice Chairman Travis Hill said over 100,000 customers lost access to their accounts and that tens of millions of dollars appeared to be missing.
The FDIC responded with a proposed rule on custodial account records. It covers pooled accounts where end users can direct payments out. Banks holding these accounts would keep records of each beneficial owner and their balance, and reconcile those records at the end of each day.
Whatever form the rule takes, sponsor banks now look harder at how fintechs keep their ledgers. Before you pick a provider for US accounts, get clear answers to these questions.
How to launch US accounts for non-US users, step by step
The steps below follow the named virtual account route, using Due's API as the worked example. Requirements come from Due's documentation; other providers differ in detail but follow a similar flow.
- Decide who gets accounts and where they live. Choose whether you serve individuals, businesses or both, then map your user base against your provider's prohibited countries. Users you cannot serve should find out before they start onboarding.
- Onboard users with KYC or KYB. Individuals verify their identity and address. Businesses go through KYB, which covers company documents and checks on beneficial owners and directors. If users already passed Sumsub verification on another platform, Due can import it instead of starting over.
- Complete the USD account eligibility check. US account channels often need more data than standard KYC. On Due, this is called an endorsement. Individuals add nationality, residential address and an ID document. Businesses add a tax ID, a W-8 or W-9 form, financial statements and source-of-funds evidence. They also link at least one beneficial owner and one director.
- Create the account and show the details. Create the virtual account by API once eligibility is approved. USD details can be provisioned asynchronously, so listen for the update webhook or poll before showing them. Display the account name, account number, routing number and bank name in a copy-friendly layout.
- Test the details with a micro-deposit. Send a small test payment and confirm it lands in the right account before users share their details widely.
- Decide where deposits go. Set the destination when you create the account. Funds can convert to USDC in the user's wallet, settle as USD to a bank account, or convert and pay out in another currency.
- Set your pricing. Add an application fee in basis points to deposits, or subsidize fees to win users in competitive corridors.
- Monitor accounts and handle exceptions. Watch for returned payments, compliance requests for information, and deposits that do not match the user's expected activity.
Operational risks of offering US accounts to international users
Launching the accounts is the easier half; most of the ongoing operational work sits in five areas.
- Name mismatches. Payroll and marketplace platforms may reject or hold payouts when the account name differs from the payee. Accounts in the user's own name remove most of this friction.
- Who can send money. Some accounts only accept funds from the account holder, so check this for each currency. On Due, USD accounts accept first-party and third-party payments, while GBP accounts accept first-party payments only.
- Returns. ACH payments can bounce back, for example when an account is closed or invalid. Map the ACH return codes to clear messages in your app, so support teams do not decode them by hand.
- Fraud and money mules. Accounts that can receive dollars from anyone are attractive to fraudsters and money laundering networks. Set expected-activity profiles at onboarding and review deposits that fall outside them.
- Country and bank offboarding. Banks and providers can withdraw support for a country with limited notice, so keep a migration plan and a fast way to reach affected users.
How Due issues US account details to international users
Due lets platforms issue named USD accounts to individuals and businesses through one API, so users outside the US can receive dollars in their own name. Due works with platforms that serve consumers and businesses, from freelancer apps and neobanks to wallets and business platforms.
- Named USD accounts on US rails. Each user gets account and routing numbers in their own name for ACH and Fedwire. Accounts accept first-party and third-party pay-ins. See USD virtual accounts for business for the business setup.
- Named USD SWIFT details. Payers outside the US can send USD through USD SWIFT virtual accounts, with SWIFT reach in over 150 jurisdictions.
- Automatic conversion. Deposits can settle as USDC on Ethereum, Base, Arbitrum, Polygon, Solana and other chains, or pay out through local rails in 80+ countries.
- Built-in onboarding. KYC, KYB and USD eligibility checks run by API or through a hosted flow, and existing Sumsub verifications can be reused.
- Revenue controls. Application fees in basis points let you set your own margin on deposits.
- More currencies on one integration. Named EUR, GBP and AED accounts, plus local MXN, NGN, COP and AUD receiving details.
Planning to offer US accounts to users outside the US? Book a demo to walk through your user base, markets and pricing.
Can a non-US resident legally hold a US bank account?
Yes. US rules let banks open accounts for non-US persons using a passport number and country of issuance, or another government ID, instead of a US taxpayer ID. Whether a particular bank chooses to do so is a commercial and risk decision.
Do non-US users need an SSN or ITIN to get US account details?
Not under the customer identification rule, which accepts foreign government IDs for non-US persons. Providers may still request a tax identification number from the user's home country. Businesses usually submit a W-8 form to document their foreign status.
Is a USD virtual account a real bank account?
A USD virtual account is a set of unique receiving details at a regulated bank, linked to one user. Payers send money to it exactly as they would to any US account. How the funds are held behind those details depends on the provider, so ask whose name is on the bank account and who keeps the ledger.
Can US account details receive payments from outside the US?
ACH and Fedwire are domestic rails, so payers outside the US usually send USD by SWIFT. To cover both payer types, give users domestic details and SWIFT details for the same account.
Which countries cannot get US accounts through a provider?
Users in sanctioned jurisdictions are excluded everywhere, and each provider adds its own list of restricted countries. Compare your provider's restricted list against your user base before launch.
