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

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	Top up balance to fund downstream cross-border payouts
Reusable Virtual Accounts for customer collections	End-payers (the entity’s own customers)	The FI, with attribution tracked by entity ID. Check Collect Webhooks.	Invoice collections, recurring billing, customer payments

How Tazapay Helps

Virtual Accounts at every layer

Provision Virtual Accounts on the FI and on every entity, with consistent attribution down the chain.

Local rails + SWIFT

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.

Real-time webhooks

Every credit fires a webhook with the entity, currency, amount, and reference — enabling instant downstream automation.

Multi-layer reconciliation

Every collect and payout carries the right entity identifier — clean books at the FI layer and at every entity beneath it.

---

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.

1. Provision Virtual Accounts in funding currencies

   Call the 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.

2. 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.

3. Funding parties transfer

   Funds arrive in the Virtual Account via the rail appropriate to that currency and account type.

4. Funds credited to FI balance

   Tazapay credits the FI’s balance and fires a collect.succeeded webhook with the amount, currency, and source details.

5. 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.

If your funding parties settle in stablecoins, you can provision a USDC or USDT stablecoin wallet instead of a Virtual Account. The same prefund flow applies — wallet address replaces bank account details, and credits fire the same collect.succeeded webhooks.

---

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.

1. Onboard the entity

   The FI calls the Create Entity API to onboard each business as an entity, including KYB and beneficial ownership details.

2. 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 for the full list of supported currencies and rails.

3. 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.

4. 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.

5. 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.

6. Entity settles

   The FI initiates a payout to the entity’s bank account from the FI’s Tazapay balance.

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.

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.

---

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	/v3/entities
Provision a Virtual Account	Create Collection Account	/v3/collection_account
Track incoming credits	Collect Webhooks	collect.*
Create a payout	Create Payout	/v3/payouts
Reconcile a specific transaction	Fetch Balance Transactions	/v3/balance_transaction/{id}

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 and KYC/KYB on entities, and Collections on Behalf Of (COBO) attribution down the chain
• Multi-layer reconciliation so the FI and every entity see clean books at their layer