Skip to main content

​
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.
  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.
  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.
Image From Developer Fin
Fin does not contact a developer’s end customers directly. All customer communication is handled by the developer.

​
All transactions must be first-party

Every transaction processed through Fin must be first-party. This means the funds in a virtual account must belong to the account holder, and the account holder must be onboarded with Fin. Fin does not support nested flows. A developer cannot collect payments from multiple third parties into a single virtual account and operate as a money service business or financial institution through Fin’s infrastructure.

​
What “first-party” means in practice

A first-party transaction is one where the sender and the virtual account holder are the same entity, or where the account holder can demonstrate a legitimate business reason for receiving funds from a named 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.
Even though the transaction originates from “Stripe” or “Nuvei,” it is still considered first-party because the underlying funds belong to the onboarded customer. Example: Nested flow (not supported) A developer onboards with Fin and receives a virtual account. They then instruct their own customers to send funds directly into that single virtual account, pooling money from multiple parties. This is not permitted. Each customer must be individually onboarded and issued their own virtual account.

​
Documents required for high-volume first-party payments

For first-party payments that are substantially high in volume, Fin will require the following documents if they were not already provided during 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. In high-risk jurisdictions, Fin may also request recipient information (which, for first-party payments, refers to the account holder themselves).
These requirements apply regardless of payment size if the transaction pattern or jurisdiction triggers a compliance review.

​
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

It depends on the context. If you are receiving funds from a payment processor (like Stripe or Nuvei) where you have a verified account under your legal name, that is permitted with documentation. If you are collecting funds from multiple unrelated third parties without onboarding them, that is not supported. Every entity transacting through Fin must be individually onboarded.
Yes. Fin requires KYC (for individuals) or KYB (for businesses) on every customer before they can receive a virtual account or transact. You cannot use your own virtual account to receive funds on behalf of your customers.
No. This is a nested flow and is not supported. Each customer must be onboarded separately and issued their own virtual account. Using a single account to pool third-party funds would classify the activity as operating a money service business, which Fin cannot facilitate.
Yes, as long as you have a verified account with the payment processor under the same legal name as your Fin account. Fin will ask for a letter or document confirming this relationship. Since the funds ultimately belong to you, this is still a first-party transaction.
Fin’s compliance team may flag the transaction and request supporting documentation such as an invoice, contract, or proof of business relationship. If the payment cannot be verified as legitimate first-party activity, it may be returned or the account may be restricted.
Yes. As part of the developer onboarding process (KYB), if your entity meets the eligibility criteria of our banking partners, you will receive a virtual account automatically.
Fin may request: (1) purpose of payment, (2) proof of purpose (invoice, contract), (3) source of funds, (4) proof of source of funds. In high-risk jurisdictions, recipient information may also be required. These are standard compliance requirements and apply to all high-volume activity.
No. Fin does not support developers using virtual accounts to run money service businesses, payment processing operations, or financial institution activities. See the restricted business activities page for details.