Guidance on nested payments & onboarding

​

What “nesting” means

Nesting is the use of a virtual account to serve customers of the account holder without those customers being onboarded and monitored as Fin customers in their own right. It is a form of hidden financial intermediation, and it is prohibited by Fin’s regulators and banking partners. Nesting is prohibited if you:

• collect funds from multiple third parties into a virtual account you hold, and then pay those parties out to different recipients on their behalf; or
• use your virtual account to run any activity typical of a bank, money services business, payment service provider, e-money institution, virtual asset service provider, prepaid provider, or similar business, unless you have disclosed that activity to Fin in advance and received written acceptance.

These commitments are set out in Fin’s Virtual Account No-Nesting Terms, which every developer and every end customer accepts at Virtual Account onboarding.

---

​

How Fin works with developers and their customers

Fin is a B2B infrastructure platform. Developers integrate with Fin’s APIs to offer financial services to their own customers. Here is how the relationship works:

1. Fin onboards the developer. We perform KYB on the developer’s business, review their AML policies, onboarding criteria, and customer risk assessment framework. Once approved, the developer can use Fin’s APIs. At onboarding, the developer also accepts Fin’s Developer No-Nesting Terms.
2. Each end customer must be onboarded individually. Fin requires every customer (individual or business) to go through KYC or KYB via Fin’s platform before they can receive a virtual account or transact. There are no exceptions to this. At onboarding, each end customer also accepts Fin’s Customer No-Nesting Terms.
3. Virtual accounts are issued per onboarded entity. Once a customer passes verification and meets our banking partner’s eligibility criteria, they receive their own virtual account. The developer themselves also receives a virtual account as part of their onboarding, if eligible.

---

​

Every account holder must be the beneficial owner of funds

Every account holder must be the beneficial owner of the funds in their virtual account. That means the funds must belong to the account holder, even if they are paid in by a named third party such as a customer, supplier, or payment processor. The account holder must also be onboarded with Fin. What Fin does not support is nesting, meaning using a virtual account to receive funds that beneficially belong to someone else who has not been onboarded with Fin. This includes pooling funds from multiple third parties, operating as a money services business, payment service provider, or financial institution through Fin’s infrastructure, or otherwise acting as an intermediary for undisclosed downstream customers.

​

What “beneficial ownership” means in practice

The funds in a virtual account must beneficially belong to the account holder. Where they are paid in by a named third party, the account holder must be able to demonstrate a legitimate business relationship with that third party. Example: Agency or drop-shipping business A drop-shipping store onboarded with Fin receives a payment from a supplier or buyer. This is acceptable if:

• The payment is tied to a specific invoice or contract.
• The account holder can provide documentation (invoice, purchase order, contract) linking the payment to their business activity.
• Compliance may request these documents for any inbound transaction that does not originate from the account holder’s own named bank account.

Example: Funds received from a payment processor (Stripe, Nuvei, etc.) A business sells products online and collects payments through a payment processor like Stripe or Nuvei. The processor then settles funds into the business’s Fin virtual account. This is permitted, provided:

• The business has a verified account with the payment processor under the same legal name as the entity onboarded with Fin.
• Fin will require a letter or document confirming the account relationship between the business and the payment processor.

Because the funds beneficially belong to the account holder even though they arrive via a processor, this is permitted. Example: Nested flow (not supported) A developer or account holder receives a virtual account and instructs multiple third parties to send funds directly into it, pooling money from parties who have not themselves been onboarded with Fin. This is not permitted. Each transacting party must be individually onboarded and issued their own virtual account. Example: Disclosed financial intermediary (permitted with prior acceptance) If your business is a licensed money services business, payment service provider, or similar financial intermediary and you wish to use a virtual account in that capacity, you must disclose this to Fin in advance during onboarding. Fin will assess the relationship separately and either accept, condition, or decline it. Do not begin transacting on that basis without written acceptance from Fin.

---

​

Documents Fin may request for higher-risk or high-volume activity

For payments that are high in value, high in volume, or that raise compliance questions, Fin will request the following if they were not already provided at onboarding:

1. Purpose of the payment.
2. Proof supporting the purpose (e.g., invoice, contract, or purchase order).
3. Source of funds.
4. Proof of source of funds.
5. For customers based in or transacting to higher-risk jurisdictions, Fin may also request additional recipient and counterparty information.

These requirements apply to any transaction pattern or jurisdiction that triggers a compliance review, regardless of the individual payment size.

---

​

Restricted business activities

Certain business types and activities cannot be facilitated through Fin. See Restricted and High-Risk Businesses for the full list.

---

​

Frequently asked questions