> ## 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

> Use Collection Accounts to power three common FI patterns: prefund the FI balance, per-batch named VAs for batch payouts, and persistent named VAs for COBO collections

In this guide, **FI** refers to any Tazapay customer that acts as a financial it institution to its own customers — banks, neobanks, payroll platforms, AR/invoicing platforms, treasury platforms, or marketplaces. The FI's business customers (the entities that hold balances and need their own reconciliation) are onboarded as **sub-entities**. Tazapay provisions Virtual Accounts (VAs) at the FI layer and at each sub-entity layer, supporting three patterns FIs commonly need:

| Pattern                                   | Who funds the VA                                        | 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                    | Top up balance to fund downstream cross-border payouts      |
| Per-batch named VAs for payouts           | A funding party (e.g., an employer, a client of the FI) | The FI's balance, staged for batch disbursement | Payroll runs, vendor settlement cycles, claim disbursements |
| Persistent named VAs for COBO collections | End-payers (the sub-entity's own customers)             | The sub-entity's balance                        | Invoice collections, recurring billing, customer payments   |

For the broader pattern where one party operates both the FI layer and the platform layer themselves, see the [Marketplaces guide](/collection-accounts/use-case-guides/marketplaces).

## How Tazapay Helps

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

  <Card title="Local rails + SWIFT" icon="arrow-right-arrow-left">
    Provision local VAs (PayNow, FAST, ACH, SEPA, Faster Payments, NEFT/IMPS) for in-country payers, or SWIFT VAs 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 sub-entity, currency, amount, and reference — enabling instant downstream automation.
  </Card>

  <Card title="Multi-layer reconciliation" icon="users">
    Every collect and payout carries the right sub-entity identifier — clean books at the FI layer and at every sub-entity beneath it.
  </Card>
</CardGroup>

***

## Pattern 1: FI Prefund via Local Rails or SWIFT

The FI provisions VAs 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 VAs. 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 VAs are also available where the funding party can only send via SWIFT, but carry correspondent and lifting fees and 1–3 day settlement delays. Most FIs default to local rails and keep SWIFT as a fallback.

<Steps>
  <Step title="Provision VAs in funding currencies">
    Call the [Create Collection Account](/api-reference/tazapay-api/create-collection-account) API to provision a VA 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 VA details with funding parties">
    The FI shares each VA's account 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 VA 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 handled where required.
  </Step>
</Steps>

<Frame>
  <img src="https://mintcdn.com/tazapay-58ae360f/HgUgkiM58uq4iY2C/images/diagrams/usecase-fi-prefund.png?fit=max&auto=format&n=HgUgkiM58uq4iY2C&q=85&s=24bce841a5dcb5523cacfe45841eb4ab" alt="FI prefund flow" width="1043" height="70" data-path="images/diagrams/usecase-fi-prefund.png" />
</Frame>

***

## Pattern 2: Per-Batch Named VAs for Payouts

The FI needs to receive a known lump sum from a funding party and then disburse it to many beneficiaries — a batch payout. The FI provisions a **fresh named VA per batch** (per pay run, per settlement cycle, per claim batch, per funding round) via API. The funding party transfers the batch amount into that VA. Tazapay fires a webhook the moment funds arrive, so the FI's system instantly knows which batch was funded and for what amount — no manual reconciliation. A separate payout call then disburses to all beneficiaries.

The VA solves the **inbound problem**: which funding party sent what amount, for which batch, when. The outbound disbursement uses Tazapay's [Create Payout](/api-reference/tazapay-api/create-payout) API (or any other payout rail the FI prefers).

### Example: PayCo's monthly payroll

PayCo is a payroll FI on Tazapay. PayCo's clients include Acme (200 employees, AED 800k/month payroll) and Beta (50 employees, AED 200k/month).

<Steps>
  <Step title="Create a VA per pay run">
    For November, PayCo calls Create Collection Account twice: one VA tagged `ACME_NOV2025_PAYRUN` with expected amount AED 800,000, and one tagged `BETA_NOV2025_PAYRUN` with expected amount AED 200,000.
  </Step>

  <Step title="Share VA numbers with the funding parties">
    PayCo sends Acme its dedicated VA number and Beta its own. Each employer transfers their full payroll amount into the assigned VA.
  </Step>

  <Step title="Webhook on credit">
    Tazapay fires a `collect.succeeded` webhook the moment funds land. PayCo's system reads the tag, links the credit to the correct pay run, and verifies the expected amount was received — no human in the loop.
  </Step>

  <Step title="Trigger batch payout to beneficiaries">
    Once the VA is fully funded, PayCo initiates a batch payout via the Create Payout API — 200 transfers for Acme, 50 for Beta. Each employee receives salary directly in their personal bank account.
  </Step>
</Steps>

<Frame>
  <img src="https://mintcdn.com/tazapay-58ae360f/HgUgkiM58uq4iY2C/images/diagrams/usecase-fi-cobo-payout.png?fit=max&auto=format&n=HgUgkiM58uq4iY2C&q=85&s=5278589378d091de53a0d3ae2aa443ec" alt="Per-batch VAs for payouts" width="1326" height="70" data-path="images/diagrams/usecase-fi-cobo-payout.png" />
</Frame>

<Info>
  **Why a fresh VA per batch, not one VA per employer?**

  If Acme reuses the same VA every month, every credit lands in the same account. PayCo cannot tell whether an AED 800,000 deposit on November 1 is the November pay run, a late October payment, or an early December prefund — all are valid in principle. Expected-amount validation also breaks: a single VA accumulating funds across runs has no clean "expected total" to flag against, so under-fundings, duplicates, and off-cycle bonus payments get mixed into the same pot.

  A fresh VA per batch keeps each pay run isolated: one VA, one expected amount, one credit, one disbursement. Under-fundings and duplicates are flagged immediately because the VA itself encodes the batch identity.
</Info>

<Tip>
  The same per-batch VA pattern fits any flow where a funding party prefunds a known amount before batch disbursement: freelancer marketplaces (one VA per client funding round), vendor settlement platforms (one VA per settlement cycle), insurance claim disbursements (one VA per claim batch), and creator payout platforms (one VA per advertiser deposit).
</Tip>

***

## Pattern 3: Persistent Named VAs for COBO Collections

A sub-entity under the FI — for example, an end-business on an AR/invoicing platform — needs to collect payments from its own customers. Each sub-entity gets one or more **persistent named VAs** scoped to it. The sub-entity shares the VA details on invoices, payment links, or customer onboarding flows. Funds flow in via local rails or SWIFT and credit the right sub-entity's balance, with full COBO (Collection On Behalf Of) attribution.

Unlike Pattern 2 (where the VA is short-lived and tied to one batch), these VAs are **long-lived** and accumulate credits from many payers over time.

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

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

    * **Local VAs per currency** — for sub-entities with payers in known geographies. Provision a local VA in each currency the sub-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 sub-entity appears local in each market.
    * **SWIFT VAs** — for sub-entities with global, low-volume, or high-value B2B payers where maintaining local coverage isn't justified. A single SWIFT VA accepts wires from anywhere.
    * **Both** — many sub-entities use local VAs in their top 2–3 markets and a SWIFT VA as a global catch-all for everything else.

    The right mix depends on the sub-entity's volume per market, payer expectations, and cost sensitivity.
  </Step>

  <Step title="Sub-entity shares VA details with its payers">
    The sub-entity adds the VA 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 VA.
  </Step>

  <Step title="Funds attributed and credited">
    Tazapay fires a `collect.succeeded` webhook carrying the FI ID, sub-entity ID, and payment reference. The FI credits the sub-entity's balance and surfaces the payment in the sub-entity's dashboard.
  </Step>

  <Step title="Sub-entity withdraws or settles">
    The sub-entity requests a payout from its accumulated balance to an external bank account, or the FI settles automatically on a fixed schedule.
  </Step>
</Steps>

<Frame>
  <img src="https://mintcdn.com/tazapay-58ae360f/HgUgkiM58uq4iY2C/images/diagrams/usecase-fi-cobo-collect.png?fit=max&auto=format&n=HgUgkiM58uq4iY2C&q=85&s=9e8f6abafcc199fbc1b89ecba4cb3855" alt="COBO collections flow" width="1130" height="94" data-path="images/diagrams/usecase-fi-cobo-collect.png" />
</Frame>

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

***

## Choosing the Right Pattern

| Situation                                                                                                  | Pattern                             |
| ---------------------------------------------------------------------------------------------------------- | ----------------------------------- |
| FI funding its own balance to do downstream payouts                                                        | Pattern 1 — Prefund                 |
| Known funding party prefunds a known batch amount; FI disburses to many beneficiaries                      | Pattern 2 — Per-batch named VAs     |
| Sub-entity's customers send unpredictable amounts at unpredictable times                                   | Pattern 3 — Persistent named VAs    |
| Sub-entity needs strict per-transaction reconciliation (e.g., no reference fields, duplicate payment risk) | Pattern 3 variant — Per-invoice VAs |

***

## APIs Involved

| Purpose                          | API                                                                                | Endpoint                       |
| -------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------ |
| Onboard a sub-entity             | [Create Entity](/api-reference/tazapay-api/create-entity)                          | `/v3/entities`                 |
| Provision a VA                   | [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:**

  * VA provisioning at the FI and at every sub-entity layer
  * Both local rails and SWIFT coverage for prefund, batch payouts, and COBO collections across major currencies
  * Compliance, KYC/KYB on sub-entities, and OBO attribution down the chain
  * Multi-layer reconciliation so the FI and every sub-entity see clean books at their layer
</Info>