Account Structure & Fund Flow
This guide explains how funds are held and moved across your accounts, and how payments and deposits behave depending on which account is involved.
Account structure
- The Client holds a House Account, which carries the primary balance.
- Each Customer holds their own Sub-Account.
- Sub-Accounts are designed to sit at (or near) zero balance by default — fund movement between accounts is automated and near real-time.
CA does not currently expose an API to manually move funds between House and Sub-Accounts. All allocation is system-driven by the payment and collection flows below.
The following capabilities are planned for a future release:
- Sub-Account balance retention — Sub-Accounts will be able to hold a standing balance rather than always settling to zero.
- API-driven allocation — Clients will be able to move funds between any two Sub-Accounts, and between the House Account and a Sub-Account, directly via the API.
Payouts
Normal payment
- Source of funds: House Account
- Sender name seen by beneficiary: House Account holder
- Funds are deducted directly from the House Account and paid to the beneficiary.
POBO payment (Pay On Behalf Of)
- Source of funds: Sub-Account
- Sender name seen by beneficiary: Sub-Account holder
- Because Sub-Accounts hold no standing balance, the system first allocates the required amount from the House Account to the Sub-Account, then pays out from the Sub-Account.
This produces two transaction records: an internal transfer, and the payout.
Whenever funds move between a House Account and a Sub-Account, CA records it as a TRANSFER transaction. This is a dedicated transaction type in the CA system — any time you see a TRANSFER in the ledger, it represents an internal allocation between House and Sub-Account, never an external movement. You can view these entries in the Statement section of the Client Portal.
Worked example — paying out $100 on behalf of an underlying customer:
The House Account is debited $100; the Sub-Account receives $100 and immediately
pays it out, ending at $0. You trigger POBO simply by making the
payment in the context of an underlying customer (i.e. by
supplying that customer's clientId).
Pay-ins
Both House Accounts and Sub-Accounts can be assigned virtual accounts for collection.
Normal pay-in
- Payee: virtual account linked to the House Account
- Funds are credited directly into the House Account.
COBO pay-in (Collect On Behalf Of)
- Payee: virtual account linked to a Sub-Account
- Funds are first credited to the Sub-Account, then automatically transferred to the House Account.
This produces two transaction records: the Sub-Account credit, and the internal transfer to the House Account.
The internal movement from Sub-Account to House Account is recorded as a TRANSFER transaction — the same dedicated type used for all House / Sub-Account allocations. You can view these entries in the Statement section of the Client Portal.
Worked example — receiving $100 into a Sub-Account virtual account:
The Sub-Account receives $100 and immediately transfers it to the House Account, ending at $0; the House Account ends $100 higher.
See Deposits
for how COBO appears when you query deposits, and
Transactions for how the two records show
up in the ledger (a DEPOSIT and a TRANSFER).
Summary
| Flow | Trigger | Records generated |
|---|---|---|
| Normal payment | Pay from House Account | 1 (payout) |
| POBO payment | Pay in an underlying customer's context | 2 (transfer + payout) |
| Normal pay-in | Deposit to House Account virtual account | 1 (deposit) |
| COBO pay-in | Deposit to Sub-Account virtual account | 2 (deposit + transfer) |