> ## Documentation Index > Fetch the complete documentation index at: https://partners.docs.polymarket.us/llms.txt > Use this file to discover all available pages before exploring further. # Funds handling > Why an IB may not hold customer funds, what account structure that leaves you, and the unresolved omnibus position. **IBs are prohibited from accepting or holding customer funds.** Design your money path from that sentence; a flow in which your firm receives a customer's deposit is not a flow we can enable for you. Prerequisites: * [What you own, what we own](/ib/start#what-you-own-what-we-own) — the responsibility split, * an active Wallet Co entity, which must exist before your firm's API credentials are enabled — see [Path to production](/ib/start#path-to-production). ### What that leaves you: one pool, one direction The money structure is the same as the ISV structure, with one identity added. | Thing | Whose money | What it does | | -------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------ | | **Wallet Co** | Yours | Your funding entity. Must exist and be **active before your firm's API credentials are enabled** | | **Your pooled balance with us** | Yours, pre-positioned | The source of every `Transfer`. `GetFundingAccountBalance` is its source of truth | | **Participant clearing account** | The customer's, in our custody | Holds their cash, positions, released collateral and settlement credits | | **IB anchor DCO account** | Your clearing identity | The account structure addition that an ISV does not have | The flow has exactly one shape: **you pre-position your own funds in the pool, then move cash into a participant account with a `Transfer` call.** The cash stays there. Fills, realized profit, released collateral and settlement credits all land in the participant's clearing account and become buying power, so nothing needs sweeping after a fill or a settlement. `CashMovementService` is **firm-scoped — do not send `x-participant-id`** on it. Reasons are `DEPOSIT`, `WITHDRAWAL` and `VENDOR_FEES`, and **direction is fixed by the reason**. You name only the participant account; we resolve your funding account from your configured relationship. **Transfers to your own firm, between participants, or to an external destination are structurally impossible** — which is also what keeps you from accidentally building a path that has you holding customer money. Production deposit rails are **wire only** as of August 2026. **`CheckoutAPI` and Aeropay return `403 method not permitted` for ISVs — they are not entitled.** Whether either surface is available to an IB is not recorded either way. Do not build a deposit UX around them before you have that in writing. ### Wallet Co segregation You carry a **Wallet Co segregation requirement** on top of the entity itself. The pool you fund is your own money, and it has to stay distinguishable from anything of your customers' that you are not permitted to hold in the first place. **The segregation requirement is not specified in writing.** The requirement exists and its content is not published. Get it, and the evidence we expect, named in your shared Slack channel before you open the account — after Wallet Co is active this becomes expensive to restructure, because credential enablement is already gated on it. ### The omnibus question **An omnibus account at our DCO is possible for licensed intermediaries.** An ISV cannot hold one at all. Those two statements are the entirety of the recorded position, and neither of them approves a particular structure. **The authoritative position on an IB omnibus or reserve-pool structure is not settled. `VERIFY` before you build.** An omnibus reserve pool is reported to have been implemented by at least one partner, and the structure is reported to have been contested internally. Neither the implementation nor its resolution is in our verified ledger, so **this page does not tell you whether that structure is permitted.** We are not stating a compliance conclusion we have not made. What to do: describe the exact structure you intend to run — whose name the account is in, whose funds sit in it, and how customer entitlements are tracked — and get a written answer before you build it. Do not infer approval from another partner having shipped something. The related fact you can rely on is narrower and still useful: **the transfer surface cannot move money to your firm or to an external destination.** Whatever structure is eventually approved, it will not be reachable by pointing `Transfer` somewhere new. ### Precision, and why your balance sheet will not reach zero **Transfers accept at most 2 decimal places. Balances carry more** — `172.395` and `1377.57275` have both been observed. **There is no sanctioned handling for the sub-cent residue.** A participant account holding a sub-cent residue cannot be emptied with a `Transfer`. For an IB this is a reconciliation and reporting problem, not just an engineering one: carry it as a named, quantified difference in your reconciliation rather than forcing it, and raise the aggregate with your integration lead. → [Reporting pack](/regulatory#reporting-pack) ### Which balance number is which `GetAccountBalance` returns `balance`, `capitalRequirement`, `excessCapital`, `buyingPower`, `unsettledFunds` and `marginRequirement`. Two partners independently asked which one is spendable cash, and the definition has been given three different ways across three of our own pages. **One canonical spendable-cash formula is not published.** Three definitions are live: `free cash = account cash − collateral locked by open orders and positions`; `spendable balance = account cash − accrued, uncollected vendor fees`; or use `buyingPower` / `excessCapital` from `GetAccountBalance`. **The real gate composes all three.** Do not publish a figure to a customer from one of them alone. Two more facts that bite on the reporting side: * `GetAccountBalance` returns `InvalidArgument: invalid account` for a **participant clearing account** while succeeding for a firm account. Partners derive the number from the newest balance-ledger entry's `afterBalance` instead — a ledger scan standing in for a one-field read. * **Whether an open short carries a collateral requirement, and where it is exposed, is unanswered.** An open short carries an obligation of up to **\$1.00 per contract**, and `balance_reservation` and `margin_requirement` came back **empty** on the ledger entries for one. **A customer could withdraw funds backing an open short.** Until the field is named, do not compute withdrawable cash for a customer with open short positions from the balance fields alone. Hold back \$1.00 per open short contract in your own model and say so in your risk-monitoring overview. ### What can go wrong | Symptom | Cause | What you do | | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Your design has your firm receiving the customer's deposit | IBs may not accept or hold customer funds | Redesign. Customer cash reaches a participant clearing account, in our custody, by `Transfer` from your pool | | `PERMISSION_DENIED` on a cash movement | `x-participant-id` sent on a firm-scoped call | Remove the header. `CashMovementService` is firm-scoped | | `NOT_FOUND: customer relationship claim failed` | The relationship is established server-side by KYC and there is **no claim or link RPC**. Root causes seen: a shared test SSN across users, an incomplete server-side setup step, and a half-provisioned firm that can read the pool but move nothing out of it | Report which of the three you can rule out; it needs work on our side | | A retry after a terminal reject does nothing new | **A terminally-rejected `idempotency_key` replays its stored rejection** | Use a new key after a terminal reject. Never reuse one to "try again" | | Your API credentials are not enabled | Wallet Co does not exist or is not active | That gate blocks credential enablement, not just funding | | Your pool is empty in preprod | Preprod pools are funded manually by us on a Slack request | Ask, and plan for the round trip. There is no self-service test funding | | A balance you reported to a customer disagrees with ours | You used one of the three published definitions of spendable cash | Reconcile against the ledger and report the difference rather than the derived figure | **The transfer rate limit is not settled and no number can be published.** The limit is not settled, and one candidate is a ceiling **shared across all partners** rather than per firm. Ask for your firm's value and its scope in writing before you size your funding loop. This is the single statement of the unsettled transfer rate limit for the IB space. [Move cash](/funding#move-cash) and [Rate limits](/limits-and-errors#rate-limits) cross-reference it rather than restating it. ## Where the mechanics live The calls themselves are identical for an ISV and an IB, so they are not restated here: * [Move cash](/funding#move-cash) — `CashMovementService`, the reason-fixed direction, the four statuses, idempotency and the two-decimal limit. * [Which number is spendable](/balances#which-number-is-spendable) — the six balance fields and which one gates a withdrawal. Two IB-specific consequences to carry into those pages: * The sub-cent residue is a **reporting** problem for you, not only a reconciliation annoyance — see [Reporting pack](/regulatory#reporting-pack). * Hold back **\$1.00 per open short contract** in your own model and say so in your risk-monitoring overview. Whether an open short carries a collateral requirement on our side, and where it is exposed, is unanswered. ## Next [Regulatory](/regulatory)