> ## 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. # IB: start here > What the IB space covers, the responsibility split that defines this path, and the gate sequence to production. This space is the implementation reference for Introducing Brokers connecting to Polymarket US: your own customers, your own KYC, our exchange and clearing. Prerequisites: a shared Slack channel with us and a named integration lead. Everything on this page moves through that channel — see [Getting help](#getting-help). You do **not** need a signed IB Agreement to start — see [Path to production](#path-to-production). [What you own, what we own](#what-you-own-what-we-own) has no prerequisites of its own. Read it before [Path to production](#path-to-production) and [You own KYC](/kyc-ownership). ### Who this is for Engineers and compliance staff at a firm that is registered, or registering, as an Introducing Broker and will route customer orders to us as the DCM. If you own the end user's KYC and are prohibited from holding their funds, you are in the right space. If your firm collects a KYC payload and we decide, you are an ISV, not an IB, and the ISV space applies instead. **Ask your integration lead to confirm, in writing, which partner type your firm is recorded as.** The partner-type taxonomy is unresolved internally and has leaked to partners as mislabelled tickets and wrong account structures. A fourth type, TSP, is also in use internally — one partner was labelled ISV and was actually a TSP. "What makes an IB different from an ISV?" was asked internally at least three times over two months. A wrong label produces a wrong account structure, and the account structure is expensive to change after go-live. ### Most of this space is the ISV path The technical surface is the same. Authentication, the two-firm identity model, `CreateVendorOrder`, `Transfer`, the gRPC streams, the wire scales and the error catalog do not change because you are an IB. Six areas fork, and they are the reason this space exists: | Forked area | Why it forks | | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | [You own KYC](/kyc-ownership) | You own the end-user identity decision. An ISV does not | | [Funds handling](/funds) | You are prohibited from accepting or holding customer funds, and omnibus is available to licensed intermediaries | | [What you own, what we own](#what-you-own-what-we-own) | Support, suitability, KYC and funds-handling rows all move | | [Path to production](#path-to-production) | Your licensing status interacts with access, and you sign an IB Agreement rather than a VCA | | [Regulatory reporting pack](/regulatory#reporting-pack) | Ten named reports, an NFA/CFTC demo and a risk-monitoring overview that ISVs never ask for | | [Naming and record requirements](/regulatory#naming-and-record-requirements) | NFA reports error on records an ISV would never notice | Sections in this space that are still marked as being forked carry a note saying so. They are accurate on the shared surface and incomplete on the IB-specific detail. ### The four things that break IB integrations 1. **KYC ownership does not mean KYC substitution.** You own the decision for your own customer; every participant you send us is still verified on our path until a reliance model is signed off, and no timeframe for that is committed. → [You own KYC](/kyc-ownership) 2. **You cannot accept or hold customer funds, and the omnibus position is unresolved.** Design the account structure before you build the money path, not after. → [Funds handling](/funds) 3. **Record naming breaks NFA reports.** At the account and user level the legal name must be a physical person's name. One partner's production record was entered as the company name. → [Naming and record requirements](/regulatory#naming-and-record-requirements) 4. **There are three identities, not one.** You get a participant firm and a clearing-member firm, and an IB adds an anchor DCO account. Confusing a DCO clearing-member ID with a DCM firm name has stalled an onboarding outright, with no error returned to you. → [Naming and record requirements](/regulatory#naming-and-record-requirements) The thing most likely to move your go-live date is none of the four: it is the reporting pack. Several of the ten reports have no delivery mechanism today. Read [Regulatory reporting pack](/regulatory#reporting-pack) in week one, not in the week before launch. ### What "beta" means here Concretely: RPCs have been removed without a changelog entry. `CreateFundedOrder`, `PreviewFundedOrder` and `OdfSweep` were removed on 2026-08-06 and a partner discovered it through gRPC reflection when their money path broke. Subscribe to the changelog and pin the proto bundle you build against. For how to reach us and what to include, see [Getting help](#getting-help). ## What you own, what we own Read this before you design your ledger or your account structure. Two rows below — KYC ownership and funds handling — are the reason the IB path exists, and one of them has caused partners to ship settlement code switched off in production rather than risk a double payout. ### You may not accept or hold customer funds **IBs are prohibited from accepting or holding customer funds.** That is the constraint the rest of your money design follows from, and it is not a preference we can waive per partner. In practice: you hold one pooled balance with us, funded by your funding entity (Wallet Co), and you move cash into a participant's account with a `Transfer` call. The cash sits in the participant's clearing account from that point on. Fills, realized profit, released collateral and settlement credits all land there and become buying power. Nothing needs sweeping after a fill or a settlement. Transfers are structurally one-directional. You name only the participant account; we resolve your funding account from your configured relationship; direction is fixed by the reason (`DEPOSIT`, `WITHDRAWAL`, `VENDOR_FEES`). Transfers to your own firm, between participants, or to an external destination are impossible. See [Funds handling](/funds). **We credit the participant's clearing account at resolution.** Winning contracts settle at $1.00, losing contracts at $0.00, and the credit is applied by us. **Do not pay your customer from your own ledger at resolution.** If you credit your customer and we credit the participant account, every settled position pays out twice. As an IB you also cannot legitimately hold the funds you would pay from. This is being confirmed in writing. Until your integration lead confirms it, do not enable independent settlement crediting. This is the single statement of the settlement-responsibility position for the IB space. [Settlement](/settlement) cross-references it rather than restating it. ### Responsibility table | Area | You own | We own | | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | End-user app, UX, order entry | Everything the customer sees and every order you submit | Nothing | | **End-user KYC** | **The decision for your own customer.** You run your policy and you own the outcome | Running our own identity check on every participant you send, until a reliance model is signed off. → [You own KYC](/kyc-ownership) | | **Relying on your own KYC** | Your policy, your records, your AML programme | The AML sign-off that a reliance model depends on. **No timeframe is committed** | | KYC decline reasons from our side | Communicating *something* to your customer | Not exposed to you at all — retrieving one needs a human to open a Socure thread | | **Suitability** | **All of it.** Customer appropriateness, disclosures and any suitability determination your registration requires | Nothing | | **End-user support** | **First line, all of it.** Every customer question reaches us through you, in your shared Slack channel | Partner-facing support only. → [Support and escalation](/operations#support-and-escalation) | | **Accepting or holding customer funds** | **Nothing. You may not accept or hold customer funds** | Custody of all participant balances | | Funding entity (Wallet Co) | The entity, its segregation, and keeping the pool funded ahead of demand | The funding relationship configuration, and `GetFundingAccountBalance` as the pool's source of truth | | Participant identity | Recording the `participantId` we hand you, and the anchor DCO account and firm strings | Issuing all of them, and owning the SSN → account mapping | | **Market resolution and settlement credit** | Reading settlement values and reconciling | **Resolving the market and crediting the participant's clearing account at resolution** | | **Regulatory reporting** | Your filings, your retention, your reconciliations | Supplying what the platform can supply, which is not all ten reports today. → [Regulatory reporting pack](/regulatory#reporting-pack) | | **Record naming** | Entering a physical person's legal name at the account and user level | The reports that error when you do not | | Vendor fees | Tracking your own accruals. The platform never knows your fee basis and accrued fees are not on the API | The daily Vendor Fees report | | **Payment capture branding** | The GUI | The requirement that the customer knows funds go to Polymarket Exchange | | **Erroneous orders, busts, refunds** | Your own customer communications | See the warning below | | Legal agreements to the end user | Presenting the four QCX LLC / QC Clearing LLC documents from `polymarketexchange.com` | Issuing and versioning them | **No correction, bust or refund policy is published.** There is also no statement of whether institutional participants are in scope when retail positions are refunded after an outage. Do not promise your customers a busted-trade process. Raise any erroneous order in your shared Slack channel immediately and say it moves money. **R-3 of the end-user agreement requirements forbids hosting modified, excerpted or re-rendered copies** of the four legal documents. Link to the copies on `polymarketexchange.com`. Do not serve them from your own storage or a Drive folder. The current ISV page violates this by serving the participant agreements from Google Drive — do not copy that pattern. ### The omnibus position **An omnibus account at our DCO is possible for licensed intermediaries.** It is not available to ISVs at all. That is the whole of the recorded position. **The authoritative omnibus position for an IB is not settled.** Do not read "possible for licensed intermediaries" as approval of a specific structure. Get the structure you intend to run confirmed in writing before you build against it. → [Funds handling](/funds) ### Payment capture branding You own the deposit and withdrawal GUI. We are the DCM, and **both the NFA and the CFTC care what that screen says: the customer must know funds are going to Polymarket Exchange.** This applies to the payment capture flow specifically, including anything that looks like your firm taking the deposit — which, as an IB, you may not do. **The branding rules are not yet published.** Send screenshots of your deposit and withdrawal screens to your integration lead before launch. This has never been written down, so a self-review is not possible. Production deposit rails are **wire only** as of August 2026. ### Where an IB differs from an ISV The same six rows, from your side, are on [Who you are](/who-you-are#the-six-differences) — along with an index of every page in this space that carries an IB-specific callout, so you can work through them in one pass. ### What can go wrong | Symptom | Cause | What you do | | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Your customer is paid twice on a settled market | You credited from your own ledger and we credited the participant account | Disable independent settlement crediting and raise it as a money issue | | You designed a flow where your firm receives the customer's deposit | IBs may not accept or hold customer funds | Redesign before build. → [Funds handling](/funds) | | Your balance sheet cannot reach zero | Transfers accept at most 2 decimal places, balances carry more (`172.395`, `1377.57275` observed) | There is no sanctioned handling for the residue. Track it as a known reconciliation difference and raise it | | You verified a customer yourself and we still declined them | A reliance model is not in force yet | Send the payload; our check still runs. → [You own KYC](/kyc-ownership) | | A customer cannot be re-verified | One SSN maps to exactly one exchange account platform-wide, and there is no re-KYC or PII-update path | Raise it in Slack; it needs manual work on our side | | An NFA report errors on your records | The account or user legal name is not a physical person's name | Fix the record. → [Naming and record requirements](/regulatory#naming-and-record-requirements) | ## Path to production Start your preprod build now, in parallel with licensing and legal. The single most expensive mistake on this path is running the gates in series. **Preprod access does not require a signed agreement.** One partner lost roughly three weeks believing it did. Ask for preprod credentials on the day you have a Slack channel and a keypair. **Whether completed NFA registration is a precondition for preprod access is not published.** The recorded fact covers the agreement, not the registration. One IB ran the NFA process to completion before signing, and the sequencing question — whether preprod could have been granted at any point during it — has never been answered in writing. Ask your integration lead to state in the channel whether your preprod credentials are blocked on registration. If they are not, request them this week. IB provisioning is **fully manual** on our side. The institutional portal's self-service API keys and upload forms are built for market makers and do not apply to you. No turnaround is published for any gate below. **Turnarounds are not yet published.** Every gate below is marked `VERIFY` for turnaround. Ask for a date per gate and hold the plan to it; do not assume same-day. ### Run these three tracks in parallel | Track | Gates | Blocks what | | -------------- | ------------------------------------------------------------------- | ----------------------------- | | **Technical** | Intake, preprod keypair and credentials, scopes, preprod build, UAT | Nothing in legal or licensing | | **Legal** | IB Agreement, W9 and CP575, Wallet Co entity | Production credentials | | **Regulatory** | CFTC/NFA registration, the reporting pack, the NFA/CFTC demo | Production traffic | The technical track is the one partners delay unnecessarily. Nothing in it waits on the other two. ### The gates **You submit:** legal name, email address, phone number, business address, and the legal name of your funding entity (Wallet Co). **The exact intake form is not yet published.** There is no published route for a prospective partner, which has produced inbound from entities claiming agreements that do not exist. Confirm the current field list with your integration lead. **You also ask for:** confirmation in writing of the partner type your firm is recorded as. The taxonomy is unresolved internally and a wrong label produces a wrong account structure. **We return:** a shared Slack channel and a named integration lead. **Owner:** you. **Turnaround:** `VERIFY` **You submit:** the **public** half of an RSA 2048 keypair you generate yourself. ``` openssl genrsa -out -preprod-private.pem 2048 openssl rsa -in -preprod-private.pem -pubout -out -preprod-public.pem ``` **Keys are per environment.** A preprod keypair does not work in production; you generate a second keypair at Gate 7. **We return:** your Client ID and your firm strings — the participant firm and the clearing-member firm. Record both, verbatim. → [Firms, participants and accounts](/identity) **How credentials reach you is being confirmed.** Two channels are in use today and we are consolidating to one. Ask your integration lead which one applies rather than waiting on the other. **Owner:** shared — you generate, we register. **Turnaround:** `VERIFY` **You submit:** an executed **IB Agreement**. An ISV signs a Vendor Connectivity Agreement and a Fee Agreement; you do not. Agreement completion is a repeated rejection loop. Before you send it back, check: * signature pages **8, 10, 11 and 15** are all signed, * the **W9 TIN matches the entry in the portal exactly**, * **CP575** is attached as EIN confirmation. Two clauses generate most of the questions on this gate, and neither has a published answer: **Attesting to registration that is close but not yet granted.** Do not sign an attestation you cannot support, and do not assume the attestation can be amended later. Raise the exact clause text with your integration lead and get the answer in the channel before signing. **Term and effective date.** If your registration is expected to land after signature, the effective date determines whether you are in term without being registered. Ask before signing. **We return:** a countersigned agreement. **Owner:** shared — your legal team and ours. **Turnaround:** `VERIFY` **You submit:** your Wallet Co legal entity details. **Your funding entity must exist and be active before your firm's API credentials are enabled.** This gate blocks credential enablement, not just funding — it is the one legal-track item that sits in front of the technical track. As an IB you also carry a **Wallet Co segregation** requirement on top of the entity itself, because the pool you fund is your own money: you may not accept or hold customer funds. **The segregation requirement is not specified in writing.** Get the requirement and the evidence we expect named in the channel before you open the account. → [Funds handling](/funds) **We return:** confirmation that the funding relationship is configured. We resolve your funding account from that relationship on every `Transfer`; you never name it. **Owner:** you. **Turnaround:** `VERIFY` **You submit:** the list of surfaces you need — market data, positions, reports, cash movements, KYC, gRPC reflection. **Scopes are granted server-side against your client. Do not request them on the token exchange.** After we add a grant you must re-mint your access token or you will keep getting `PERMISSION_DENIED`. Six of eight ISVs discovered their scope set by hitting that error. Ask for `read:reports` and `read:cash-movements` in this gate, not later — they are what your reporting work runs on. → [Reporting pack](/regulatory#reporting-pack) **We return:** the grants, on your client, in that environment. **Owner:** us. **Turnaround:** `VERIFY` **You submit:** a completed UAT test plan. Two things you cannot test in preprod, so plan around them now: * **Markets do not resolve in preprod.** Instruments reach `INSTRUMENT_STATE_EXPIRED` in large batches — 363, 455, 544 and 549 in a single session — and none resolve. One partner asked six times over 40 days to test a settlement flow and never could. * **Books are thin and intermittent.** `pmsim` is the only liquidity provider, coverage runs from \~48% of `astatc-` symbols down to \~0.1% of `aec-atp`, and depth sits at the edges ($0.98 offer, $0.06 bid). Because your order surface is fill-or-kill only, a thin book blocks you completely while market makers are unaffected. **How to manufacture a preprod fill is unresolved.** The only way to rest an order in a thin preprod book is the legacy `OrderEntryAPI/InsertOrder` path, and UAT §0 asks you to disavow exactly that. These two requirements contradict each other and you cannot resolve it alone — raise it with your integration lead. Preprod pool funding is done manually by us on a Slack request; there is no self-service test funding, and there is no preprod status page or health signal. **We return:** UAT sign-off. **Owner:** you, with our review. **Turnaround:** `VERIFY` **You submit:** the pack — the NFA/CFTC demo, flow of customer funds, a back and middle office overview, a risk-monitoring overview, and the ten named reports. This is the gate ISVs do not have, and it is the one most likely to move your date. Several of the ten reports have no delivery mechanism today, so start it in week one. → [Reporting pack](/regulatory#reporting-pack) **Owner:** you, with our input on what the platform can supply. **Turnaround:** `VERIFY` **You submit:** a **separate** production keypair's public half, generated fresh. Never reuse the preprod key. **We return:** production Client ID and production firm strings, plus your IB anchor DCO account. At the account and user level the legal name must be a **physical person's name**, or NFA reports error. One partner's production record was entered as the company name. Check every production record before first traffic. → [Naming and record requirements](/regulatory#naming-and-record-requirements) **Owner:** shared. **Turnaround:** `VERIFY` **You submit:** a wire from Wallet Co. Production deposit rails are **wire only** as of August 2026\. **We return:** the balance on `GetFundingAccountBalance`, which is the pool's source of truth. **Owner:** you. **Turnaround:** `VERIFY` Start with one real customer through the full loop: KYC submit → `kyc.approved` webhook → `Transfer` → `CreateVendorOrder` → drop copy fill → balance check → ledger entry. Production has a status page at `status.polymarketexchange.com`. Preprod has none. **Owner:** you. **Turnaround:** n/a. ### Participant type casing If you create participants through an administrative path, the spelling of the type matters and differs by path. The create path validates against a vocabulary that spells ISV **uppercase** and compares **case-sensitively**; adopt and provision endpoints normalize with `strings.ToLower`. The registry's canonical lowercase `isv` has been rejected with **HTTP 400** on the case-sensitive path. **`introducing_broker` is spelled identically in both vocabularies, so the IB path has only ever worked by orthographic accident.** Do not rely on that. → [Naming and record requirements](/regulatory#naming-and-record-requirements) ### Go-live checklist Copy this into your own tracker. * [ ] Shared Slack channel open, integration lead named * [ ] Partner type confirmed in writing as IB, not ISV or TSP * [ ] Intake submitted: legal name, email, phone, address, Wallet Co legal name * [ ] **Preprod credentials requested without waiting for the agreement** * [ ] Preprod RSA 2048 keypair generated; **public** half sent; private half never left your infrastructure * [ ] Preprod Client ID received * [ ] Both firm strings recorded: `...-api-participant` and `...-api-clearing-member` * [ ] IB anchor DCO account string recorded, and not confused with the DCM firm name * [ ] IB Agreement executed — signature pages 8, 10, 11, 15 signed * [ ] Registration attestation clause answered in writing before signature * [ ] Term and effective date confirmed against your expected registration date * [ ] W9 TIN matches the portal entry; CP575 attached * [ ] Wallet Co exists and is active; segregation requirement confirmed in writing * [ ] Scope list agreed and granted, including `read:reports`; token re-minted after the grant * [ ] Token client honours `expires_in` minus 30 s, with no hardcoded 180 * [ ] Both scales read per instrument from reference data; no hard-coded divisor * [ ] `PENDING` recovery path resubmits the same `idempotency_key` with a byte-identical body * [ ] `kyc.approved` webhook registered, signing secret stored, dedupe on `event_id` * [ ] `participantId` recorded against your customer row from the webhook, never constructed * [ ] No production SSN reuse; test SSNs never shared across users * [ ] Document verification enabled (`docv_eligible: true`), not deferred to a reliance model * [ ] Settlement crediting from your own ledger is **off** * [ ] No flow in which your firm receives or holds customer funds * [ ] Deposit and withdrawal screens reviewed with your integration lead * [ ] Legal agreements linked from `polymarketexchange.com`, not re-hosted * [ ] Ten reports mapped to a source, with the unsupported ones escalated in writing * [ ] NFA/CFTC demo environment agreed, given that preprod markets do not resolve * [ ] UAT test plan signed off * [ ] Production keypair generated separately; production Client ID received * [ ] Every production account and user record uses a physical person's legal name * [ ] Production pool funded by wire from Wallet Co * [ ] One end-to-end customer loop completed in production ### Getting help `institutional@polymarket.us` is the published route for new enquiries. It is **not** the right route once you are live on preprod — use your shared Slack channel. → [Support and escalation](/operations#support-and-escalation) ## Next [You own KYC](/kyc-ownership)