For the broader pattern where one party operates both the FI layer and the platform layer themselves, see the Marketplaces guide.
How Tazapay Helps
VAs at every layer
Provision Virtual Accounts on the FI and on every sub-entity, with consistent attribution down the chain.
Local rails + SWIFT
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.
Real-time webhooks
Every credit fires a webhook with the sub-entity, currency, amount, and reference — enabling instant downstream automation.
Multi-layer reconciliation
Every collect and payout carries the right sub-entity identifier — clean books at the FI layer and at every sub-entity beneath it.
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.1
Provision VAs in funding currencies
Call the 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.
2
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.
3
Funding parties transfer
Funds arrive in the VA 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.
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 (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).1
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.2
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.
3
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.4
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.
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.
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.1
Onboard the sub-entity
The FI calls the Create Entity API to onboard each business as a sub-entity, including KYB and beneficial ownership details.
2
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.
3
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.
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 VA.
5
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.6
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.
Choosing the Right Pattern
APIs Involved
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