> ## Documentation Index
> Fetch the complete documentation index at: https://developer.tazapay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Financial Institutions

> White label Tazapay's collection accounts within your own customer flows for prefunding and customer collections

Both licensed and non-licensed institutions can white label Tazapay's [collection accounts](/collection-accounts/overview/introduction) within their own customer flows. Common use cases include automated top-ups and reconciliation, and dynamically generated Virtual Accounts for each of your business customers' own customers.

In this guide, **FI** refers to any Tazapay customer that acts as a financial institution to its own customers — banks, neobanks, payroll platforms, AR/invoicing platforms, treasury platforms, or marketplaces. The FI's business customers (the parties that hold balances and need their own reconciliation) are onboarded as [entities](/getting-started/core-concepts/creating-entities).

| Pattern                                            | Who funds the Virtual Account                 | Who receives the money                                                                                                    | Typical use                                                                          |
| -------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Prefund via local rails or SWIFT                   | The FI itself (from external funding sources) | The FI's own [Tazapay balance](/getting-started/core-concepts/balances/overview)                                          | Top up balance to fund downstream cross-border [payouts](/payouts/overview/overview) |
| Reusable Virtual Accounts for customer collections | End-payers (the entity's own customers)       | The FI, with attribution tracked by entity ID. Check [Collect Webhooks](/collection-accounts/incoming-payments/webhooks). | Invoice collections, recurring billing, customer payments                            |

## How Tazapay Helps

<CardGroup cols={2}>
  <Card title="Virtual Accounts at every layer" icon="id-card">
    Provision Virtual Accounts on the FI and on every entity, with consistent attribution down the chain.
  </Card>

  <Card title="Local rails + SWIFT" icon="arrow-right-arrow-left">
    Provision local Virtual Accounts (FAST, ACH, SEPA, Faster Payments, NEFT/IMPS) for in-country payers, or SWIFT Virtual Accounts for global cross-border collections — pick the rail per use case.
  </Card>

  <Card title="Real-time webhooks" icon="bolt">
    Every credit fires a webhook with the entity, currency, amount, and reference — enabling instant downstream automation.
  </Card>

  <Card title="Multi-layer reconciliation" icon="users">
    Every [collect](/api-reference/tazapay-api/collects) and [payout](/api-reference/tazapay-api/payout) carries the right entity identifier — clean books at the FI layer and at every entity beneath it.
  </Card>
</CardGroup>

***

## Pattern 1: Prefund via Local Rails or SWIFT

The FI provisions Virtual Accounts on its own Tazapay account to top up its operating balance. The FI's funding parties — treasury accounts, banking partners, parent company, or external liquidity providers — transfer funds into these Virtual Accounts. Funds credit the FI's Tazapay balance and are used for downstream cross-border payouts.

Local rails (ACH, SEPA, FAST, Faster Payments, NEFT/IMPS, etc.) settle instantly or same-day at low cost. SWIFT Virtual Accounts are also available where the funding party can only send via SWIFT.

<Steps>
  <Step title="Provision Virtual Accounts in funding currencies">
    Call the [Create Collection Account](/api-reference/tazapay-api/create-collection-account) API to provision a Virtual Account in each currency the FI wants to receive funding in — for example, USD on ACH, EUR on SEPA, SGD on FAST, GBP on Faster Payments. Specify SWIFT if the funding party will only send via SWIFT.
  </Step>

  <Step title="Share Virtual Account details with funding parties">
    The FI shares each Virtual Account's details (account number, routing number, sort code, IBAN, or SWIFT/BIC) with the parties that will be sending funds.
  </Step>

  <Step title="Funding parties transfer">
    Funds arrive in the Virtual Account via the rail appropriate to that currency and account type.
  </Step>

  <Step title="Funds credited to FI balance">
    Tazapay credits the FI's balance and fires a `collect.succeeded` webhook with the amount, currency, and source details.
  </Step>

  <Step title="Use balance for cross-border payouts">
    The FI initiates payouts to beneficiaries globally from its multi-currency Tazapay balance, with [FX conversion](/collection-accounts/incoming-payments/fx) handled where required.
  </Step>
</Steps>

<Frame>
  <img src="https://mintcdn.com/tazapay-58ae360f/hou37QksFwdJPvtp/images/diagrams/flow-fi-prefund.png?fit=max&auto=format&n=hou37QksFwdJPvtp&q=85&s=8255d9a09b5ed886bc0fe079df8e4320" alt="FI prefund flow" width="4040" height="960" data-path="images/diagrams/flow-fi-prefund.png" />
</Frame>

<Tip>
  If your funding parties settle in stablecoins, you can provision a [USDC or USDT stablecoin wallet](/collection-accounts/coverage/stablecoins) instead of a Virtual Account. The same prefund flow applies — wallet address replaces bank account details, and credits fire the same `collect.succeeded` webhooks.
</Tip>

***

## Pattern 2: Reusable Virtual Accounts for Customer Collections

An entity under the FI — for example, an end-business on an AR/invoicing platform — needs to collect payments from its own customers. Each entity gets one or more **reusable Virtual Accounts** scoped to it. The entity shares the Virtual Account details on invoices, payment links, or customer onboarding flows. Funds flow in via local rails or SWIFT and credit the FI's Tazapay balance. Every collect is tagged with the entity's entity ID, so the FI can attribute each credit to the right entity and maintain entity balances in their own system.

<Steps>
  <Step title="Onboard the entity">
    The FI calls the [Create Entity](/api-reference/tazapay-api/create-entity) API to onboard each business as an entity, including [KYB](/getting-started/core-concepts/kyb-overview) and beneficial ownership details.
  </Step>

  <Step title="Provision named Virtual Accounts per entity">
    Call Create Collection Account scoped to the entity. The Virtual Account type depends on where the entity's payers sit and how they pay:

    * **Local Virtual Accounts per currency** — for entities with payers in known geographies. Provision a local Virtual Account in each currency the entity collects in (e.g., USD on ACH for US customers, GBP on Faster Payments for UK customers, EUR on SEPA for EU customers, SGD on FAST for Singapore customers). Payers transfer at local rail cost and speed and the entity appears local in each market.
    * **SWIFT Virtual Accounts** — for entities with global, low-volume, or high-value B2B payers where maintaining local coverage isn't justified. A single SWIFT Virtual Account accepts wires from anywhere.
    * **Both** — many entities use local Virtual Accounts in their top 2–3 markets and a SWIFT Virtual Account as a global catch-all for everything else.

    The right mix depends on the entity's volume per market, payer expectations, and cost sensitivity. See [Virtual Account coverage](/collection-accounts/coverage/virtual-accounts) for the full list of supported currencies and rails.
  </Step>

  <Step title="Entity shares Virtual Account details with its payers">
    The entity adds the Virtual Account details (account number, IBAN, routing, beneficiary name) to invoices, customer portals, or payment instructions.
  </Step>

  <Step title="Payers send funds">
    Payers transfer via local rails for in-country payments, or via SWIFT for cross-border. Each credit lands in the right named Virtual Account.
  </Step>

  <Step title="Funds credited and attributed">
    Tazapay credits the FI's balance and fires a `collect.succeeded` webhook that includes the entity's entity ID and payment reference. The FI uses this entity ID to update the entity's balance in their own system and surface the payment in the entity's dashboard.
  </Step>

  <Step title="Entity settles">
    The FI initiates a payout to the entity's bank account from the FI's Tazapay balance.
  </Step>
</Steps>

<Frame>
  <img src="https://mintcdn.com/tazapay-58ae360f/hou37QksFwdJPvtp/images/diagrams/flow-fi-customer-collections.png?fit=max&auto=format&n=hou37QksFwdJPvtp&q=85&s=340da04584e3bb6241a1c0c6a87dd7d8" alt="Customer collections flow" width="4040" height="960" data-path="images/diagrams/flow-fi-customer-collections.png" />
</Frame>

<Tip>
  For entities facing reconciliation ambiguity (no reference fields on local rails, duplicate payments, mixed-amount invoices), provision a **Virtual Account per invoice or per order** instead of a single persistent Virtual Account. The Virtual Account number itself becomes the reconciliation key — when a credit lands, the platform knows exactly which invoice it's for.
</Tip>

<Tip>
  If an entity's payers prefer settling in stablecoins, provision a USDC or USDT stablecoin wallet scoped to that entity. Credits fire the same `collect.succeeded` webhook with the entity ID — attribution works the same way as with Virtual Accounts.
</Tip>

***

## Choosing the Right Pattern

| Situation                                                                                              | Pattern                                          |
| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------ |
| FI funding its own balance to do downstream payouts                                                    | Pattern 1 — Prefund                              |
| Entity's customers send payments the FI attributes via entity ID                                       | Pattern 2 — Reusable Virtual Accounts            |
| Entity needs strict per-transaction reconciliation (e.g., no reference fields, duplicate payment risk) | Pattern 2 variant — Per-invoice Virtual Accounts |

***

## APIs Involved

| Purpose                          | API                                                                                | Endpoint                       |
| -------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------ |
| Onboard an entity                | [Create Entity](/api-reference/tazapay-api/create-entity)                          | `/v3/entities`                 |
| Provision a Virtual Account      | [Create Collection Account](/api-reference/tazapay-api/create-collection-account)  | `/v3/collection_account`       |
| Track incoming credits           | [Collect Webhooks](/api-reference/tazapay-api/collect-webhook)                     | `collect.*`                    |
| Create a payout                  | [Create Payout](/api-reference/tazapay-api/create-payout)                          | `/v3/payouts`                  |
| Reconcile a specific transaction | [Fetch Balance Transactions](/api-reference/tazapay-api/fetch-balance-transaction) | `/v3/balance_transaction/{id}` |

<Info>
  **Tazapay handles end-to-end:**

  * Virtual Account provisioning at the FI and at every entity layer
  * Both local rails and SWIFT coverage for prefund and customer collections across major currencies
  * [Compliance](/collection-accounts/incoming-payments/holds) and KYC/KYB on entities, and [Collections on Behalf Of (COBO)](/collection-accounts/integration-guides/collections-on-behalf-of) attribution down the chain
  * Multi-layer reconciliation so the FI and every entity see clean books at their layer
</Info>