How to offer named USD accounts to your merchants.What the payer sees, what the bank checks, what breaks.

To offer named USD accounts, sign with a bank or regulated provider. It must be able to open accounts in each merchant's name. You collect KYB on every merchant and share what the provider asks for. Then you create one account per merchant by API and match every credit by account number.

General information, not legal advice. Check current rules with your providers and your own counsel.

This guide is for PSPs and platforms that serve many merchants. For the basics of in whose name a virtual account sits, start with the general guide.

Why do merchants ask for an account in their own name?

Merchants want the payer to see their company, not yours. A buyer who sees an unknown name may stop, or call to ask why.

The same holds on the way out. When a supplier's statement shows an intermediary's name, the supplier struggles to match the payment to its invoice. Some platforms with many merchants make the merchant's name a condition for every collection account. Their rule: the payer sees only the bank and the merchant.

Which account model should you offer?

There are three common models. Each one shows the payer a different name.

A dedicated number still matches every credit to one merchant. The account number does the work, not a reference the payer must type.

Each account comes with details per rail. One provider's API returns a routing number for ACH and Fedwire. It also returns a SWIFT code for international wires.

Some platforms use one master account, with a sub-account per merchant. The currency and the market often decide the model. In one market, accounts show the platform's name for every merchant. In the same setup, USD SWIFT accounts show each merchant's own name.

Names have limits too. In some markets the account must carry the provider's name as a prefix, such as "Provider - Merchant". The provider's KYC is tied to the account, so its name stays. A bank's name field may not fit three names.

What KYB does the bank need for each merchant?

Where the provider reviews each merchant, expect full company due diligence. One merchant onboarding list seen in practice asks for these documents:

• Certificate of incorporation
• Registers of directors and shareholders
• Articles of association
• Proof of address and proof of activity
• Recent bank statements
• ID and proof of address for each beneficial owner

When the merchant is the US bank's own customer, the bank works to a known standard. FinCEN's customer due diligence rule has applied to company customers since 11 May 2018. The bank must identify and verify their beneficial owners (31 CFR 1010.230). A beneficial owner is anyone with 25% or more of the equity. It also includes one person who controls the company. Since a FinCEN order of 13 February 2026, banks need not repeat this at every new account. They check when a company first opens an account, and again when facts or risk call for it. In August 2026, FinCEN said it still has to revise the CDD rule. A proposed revision went to OMB for review on 17 September 2026. It was still pending review on 26 October 2026.

The common bottleneck is a mismatch. The KYB you collected from merchants often falls short of what the bank needs. That means a round of missing documents, and identity checks on directors. Ask the provider for its exact list before you onboard your first merchant. Then collect to that list from day one.

Providers differ on who does the checks. Some review every merchant themselves. One provider's docs say approval is typically completed within 24 hours, with a webhook on the result. Others open named accounts without onboarding each merchant. They ask for documents, such as an invoice or a contract, when a payment raises a question. A provider that reviews merchants can decline one.

What happens when someone else pays your merchant?

Third-party payers are the case to plan for. A third-party payment comes from a sender whose name differs from the account name.

One provider's docs show three outcomes.

• Hold and ask. One provider's docs describe an automatic request for information. The money settles if the answer arrives within 48 hours. If nobody answers, the payment goes back to the sender.
• Approve the sender. Once cleared, that sender goes on an approved list. Later payments from it settle on their own.
• Refuse it. The same docs say accounts held by a licensed financial institution cannot receive third-party payments. Those payments are returned.

Write a rule for this before launch. Tell merchants who may pay into their account. Give your support team the provider's deadline for answers.

What does a US wire check on the name?

In general, not much. For wires over Fedwire, Regulation J applies Article 4A of the Uniform Commercial Code (12 CFR 210.25).

Section 4A-207 covers a name and a number that point to different people. In general, the beneficiary's bank may rely on the number, if it does not know of the mismatch. It need not check that the two match (UCC 4A-207).

So a named account helps the payer trust the details. It does not stop a payment sent to the wrong number. Your reconciliation should flag credits where the payer's name looks wrong for that merchant. For payments over SWIFT, see how to read an MT103.

How do you reconcile hundreds of merchant accounts?

Match on the account number first. Each merchant has its own number, so each credit has one owner.

• One event per credit. Ask for a webhook with the amount, the payer's name and the account number. Then confirm the payment through the provider's query API before you credit your ledger.
• One account per currency. One provider allows one account per merchant per currency by default. Plan your data model around that.
• Statuses. Track pending, active, suspended and closed accounts. A payment into a suspended account needs its own path.
• Held payments. Keep a queue for credits under review. Show them to the merchant as pending, not as money.

For the collection side in local currency, see how to choose a collections API.

Who owns the account when a merchant leaves?

The merchant's name is on the account. But your platform holds the contract with the provider. Settle these points in writing before the first account opens.

1. Who may ask to close the account: you, the merchant, or both?
2. Where does the balance go on closing, and to whose account?
3. What happens to a payment that arrives after closing?
4. Can the merchant keep the account details if it moves to another platform?
5. How long does the provider keep records, and who can request them?

What should you ask a provider before you sign?

1. In which currencies can you open accounts in each merchant's own name?
2. What exact name will the payer see, including any prefix?
3. Which rails reach the account: ACH, Fedwire, SWIFT?
4. What KYB do you need per merchant, and can you rely on the platform's own checks?
5. How long does merchant approval take, and how are refusals reported?
6. How do you treat a payment from a third party?
7. What triggers a review, and how long can a payment be held?
8. What does the webhook for a credit contain?
9. How are accounts suspended, reactivated and closed?
10. Can the same merchant account also pay suppliers in your merchant's name?

FAQ

For PSPs and platforms

Your merchants need USD accounts in their own names? Talk to our team about USD accounts in your merchants' names. Nilos offers accounts in your client's name in USD, EUR, GBP, AED, KES and XOF. See how virtual accounts work, or what Nilos builds for PSPs and fintechs.