FBO Pool Accounts

Provision identity-blind virtual accounts beneath a pooled master. Bankrail never learns who a holder is; every credit carries your own opaque reference back to you.

An FBO pool account is pooled custody: one master account at the bank, many virtual accounts beneath it, each attributed to an opaque holderRef that only you understand.

Bankrail never learns who a holder is. No name, no phone, no identity of any kind. Every credit that lands on a pool VA emits a balance-free funding event carrying your holderRef verbatim, and your ledger decides what it means.

This is not a persistent virtual account

A persistent virtual account identifies a customer to the bank — it takes a holder name and phone, and settles to your own account. An FBO pool VA identifies nothing, and settles into a master you hold for others. Different product, different vocabulary, different route.

Provision a pool account

curl -X POST https://api.posteering.com/api/v1/bankrail/fbo/provision \
  -H "Content-Type: application/json" \
  # ... HMAC signing headers ...
  -d '{
    "holderRef": "holder-ref-2026-0001",
    "purposeTag": "fbo_pool",
    "callbackUrl": "https://your-service.example/webhooks/bankrail/fbo-funding",
    "currency": "NGN"
  }'

Field	Required	Notes
`holderRef`	yes	Opaque to Bankrail; meaningful only to you. Returned verbatim on every funding-event callback.
`purposeTag`	yes	Your own tag. Conventionally snake_case. Echoed on every callback.
`callbackUrl`	yes	Where funding events are delivered. Must be a URL you control.
`currency`	no	ISO 4217. Defaults to `NGN`.
`bankCode`	no	Issuing-bank CBN code. Omit and Bankrail picks the default VA issuer for the currency — the FBO master is held at whichever participating bank the adapter resolves to.
`creatorMetadata`	no	Non-identity context, echoed back verbatim on every funding-event callback.

The response returns the allocated account:

{
  "trackingId": "46085b81-3e18-4720-9907-7cfc5d658db0",
  "virtualAccount": "9776507896",
  "holderRef": "holder-ref-2026-0001",
  "bankCode": "101",
  "provider": "providus",
  "providerChannel": "dcs",
  "purposeTag": "fbo_pool",
  "createdAt": "2026-07-09T19:00:02.962Z"
}

What arrives when money lands

Each credit fires a signed callback to callbackUrl with eventKind: fbo.funding, carrying the holderRef you chose. The event is balance-free — Bankrail reports that money arrived and who it was for, in your own vocabulary. It holds no position and takes no view on what the credit means.

That is the whole point of the pooled model: the bank sees one master account, Bankrail sees an opaque reference, and only your ledger knows there is a customer behind it.

Reaching it through the One API

If you are integrating through the One API, the product is bankrail-fbo, and the passthrough carries Bankrail's own path verbatim:

POST https://one.posteering.com/api/v1/one/products/bankrail-fbo/passthrough/api/v1/bankrail/fbo/provision

Everything after /passthrough/ is Bankrail's path from its host root, prefix and all. The body and the response are exactly as above — the gateway never reshapes them.

Callbacks — the signed notification you receive.
Virtual Accounts — the identity-carrying alternative.

Provision a pool account

What arrives when money lands

Reaching it through the One API

Next

On this page