Skip to main content
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. You do not need a signed IB Agreement to start — see Path to production.What you own, what we own has no prerequisites of its own. Read it before Path to production and You own KYC.

​
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: 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
  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
  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
  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
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 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.

​
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. We credit the participant’s clearing account at resolution. Winning contracts settle at 1.00,losingcontractsat1.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 cross-references it rather than restating it.

​
Responsibility table

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

​
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 — 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

​
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

The technical track is the one partners delay unnecessarily. Nothing in it waits on the other two.

​
The gates

1

Intake

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
2

Preprod keypair and credentials — do not wait for the agreement

You submit: the public half of an RSA 2048 keypair you generate yourself.
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
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
3

IB Agreement

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
4

Funding entity (Wallet Co)

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
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
5

Scopes and entitlements

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 packWe return: the grants, on your client, in that environment. Owner: us. Turnaround: VERIFY
6

Preprod build and UAT

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.98offer,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
7

Regulatory pack and NFA/CFTC demo

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 packOwner: you, with our input on what the platform can supply. Turnaround: VERIFY
8

Production keypair and credentials

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
Owner: shared. Turnaround: VERIFY
9

Fund the production pool

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
10

Production traffic

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

​
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

​
Next

You own KYC