> ## Documentation Index > Fetch the complete documentation index at: https://docs.zennopay.in/llms.txt > Use this file to discover all available pages before exploring further. # Funds flow > USD pre-fund → FX → THB/VND payout. Where the money sits at every step. Zennopay operates in **USD only**. We never hold THB or VND. Local-currency conversion happens inside our licensed payout partner network for the destination corridor. ## The four account categories that matter Every transaction touches some subset of these. All Zennopay-side balances are USD-denominated. | Account | What it holds | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Partner FBO (at Unit)** | USD the partner has pre-funded for its end users. Held in a For-Benefit-Of account at Zennopay's US banking partner. Restricted custody. | | **Partner FBO liability** | The offsetting liability — Zennopay's obligation to return the partner's pre-funded balance. Always equals the FBO cash balance. | | **Payout-partner pre-funded receivable (per corridor)** | USD Zennopay has pre-funded to its payout partner for the corridor (one balance per corridor); drawn down as transactions in that corridor settle. | | **Zennopay commercial** | Where Zennopay's margin lands after the daily sweep from FBO. Operating income. | ## Custody posture * Zennopay holds USD in an FBO account at our partner bank (Unit). The funds remain attributable to the partner — and beneficially to the partner's end users — at all times. Zennopay holds them in trust-like fashion. * Zennopay is a US Delaware C-Corp registered with FinCEN as a Money Services Business (MSB), operating as a **payment facilitator (agent of payee)**. * Zennopay is **not** an e-money institution. We never co-mingle partner FBO funds with operating funds. * We are USD-only. All FX happens inside the payout partner network for the destination corridor. ## A \$100 transaction, step by step For a `$100` transaction in the Thailand corridor (`th_promptpay`): | Player | What changes | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------- | | End user | Sees `$100 USD` in their partner-app wallet decrease. Sees THB equivalent paid to merchant. | | Partner FBO | Drops by `$101.50` (`$100` user value + `$1.50` Zennopay margin). | | Zennopay margin accrual | Rises by `$1.50`. Swept to commercial at end of day. | | Payout-partner pre-funded receivable (TH) | Drops by `$99.00` — the `$100` Zennopay sends downstream, minus the corridor's `$1.00` pass-through fee. | | Corridor pass-through fee | Rises by `$1.00`. | | Thai merchant | Receives THB equivalent of `$99.00` at the payout partner's quoted FX rate. | In ledger terms, the journal entry at payout-partner success looks like: ```text theme={null} DEBIT CREDIT clearing.in_flight $101.50 receivables.payout_partner.th_promptpay $99.00 expense.provider_fee.th_promptpay $1.00 receivables.zennopay.margin $1.50 ─────── ─────── $101.50 $101.50 ``` The `clearing.in_flight` account was loaded earlier when the partner FBO was debited; it zeros out here when the payout partner confirms success. ## When things fail | Scenario | What happens to funds | | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Partner auth declines before debit | Nothing moves. The intent is logged as `failed`. | | Payout partner returns failure after FBO debit | The FBO debit is reversed. No margin recognized, no pass-through fee incurred. | | Payout-partner success, then settlement reported failed (CAPTURE\_REVERSED) | Step-by-step reversal. Net: partner FBO restored, payout-partner pre-funding restored, no margin, no fee. The intent ends in `failed` and we emit a `payment_intent.failed` webhook. | | User-initiated refund within the corridor's refund window (T+7 for TH, T+1 for VN) | The downstream payout partner refunds the merchant; Zennopay reverses the margin and credits the partner FBO. | | Refund requested after the corridor's refund window | Payout partner rejects. From Zennopay's books, no entries. Commercial-side resolution between partner and end user. | The full T-account walkthrough lives in Zennopay's internal ledger spec and is dry-run against the live ledger at each daily close. ## Pre-funding cadence | Movement | Trigger | Frequency | | ------------------------------------------------------------ | ------------------------------------ | ---------------------------- | | Partner → Partner FBO (top-up) | Float \< 1.2× daily burn | On demand; partner-initiated | | Zennopay commercial → payout-partner pre-fund (per corridor) | Corridor pre-fund \< 1.2× daily burn | Daily, automatic | | Partner FBO → Zennopay commercial (margin sweep) | End of day | Daily, automatic | Pre-funding shortfalls are caught by monitoring that fires before they actually go below the daily burn threshold. We do not run out of float mid-day for a partner in good standing. ## What you receive as a partner * A **monthly statement** showing transaction count, gross TPV, gross margin, and any commitment-fee passthroughs. * A **reconciliation report** per corridor, comparing Zennopay's ledger against the downstream settlement record. * A **monthly invoice** for any commitment fees due. See [Settlement & reconciliation](/concepts/settlement) for cadence and break-resolution flow.