> ## 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. # Who you are > ISV or IB: which you are is set by your agreement, what it changes about the build, and where in this space the two implementations diverge. Your partner type is set by the agreement you sign, not by preference. It decides your account structure, who owns the end-user identity decision, whether you may hold customer funds, and what you have to be able to report. If you are not certain which you are, settle it with your integration lead before you build — the wrong assumption produces an account model you cannot have. **Everything in this space is written for both types unless a page says otherwise.** The implementation surface is genuinely 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 things do, and they are listed below. ## The six differences | | ISV | IB | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **End-user KYC** | **We own it.** You collect the payload; we run Socure and decide | **You own it.** Once licensed you may remit against your own policy, subject to AML sign-off. No timeframe is committed | | **Relying on your own KYC** | **Not possible.** Without an IB licence every participant is verified through Socure again, even one you already verified | Possible once licensed | | **Holding customer funds** | No | **No — IBs are prohibited from accepting or holding customer funds at all** | | **Omnibus account at our DCO** | **Not available to ISVs** | Possible for licensed intermediaries. Structure unconfirmed | | **Account structure** | Participant firm + clearing-member firm | Both of those, **plus an IB anchor DCO account** | | **Agreements** | Vendor Connectivity Agreement + Fee Agreement | **IB Agreement** | Your order surface does not change either way: `CreateVendorOrder`, fill-or-kill only, and you are always the taker. If your model depends on reusing your existing KYC or on an omnibus account, raise it before you build. As an ISV neither is available, and as an IB neither is confirmed in writing yet. ## What that changes about the build **As an ISV** you build the product and the order flow; we own identity and hold the funds. Your compliance surface is mostly presentation, and not double-crediting users at settlement. It is the shortest path to live and the most constrained account model. **As an IB** you take on a reporting obligation an ISV is never asked for — ten named reports, an NFA/CFTC demonstration, and a risk-monitoring overview. Budget for it as a programme rather than a document. You also own the end-user identity decision and the customer-facing explanation when a market settles, and you may not touch customer money at any point. ## How to read this space * **Unmarked text applies to you whoever you are.** That is most of it. * **Where the IB implementation differs, the page says so** in a callout that begins *"If you are an IB, this differs."* If you are an ISV, those callouts are not for you and you can skip them. * **Pages with no ISV equivalent** are grouped in the sidebar under *If you are an IB*: [You own KYC](/kyc-ownership), [Funds handling](/funds), [Regulatory](/regulatory) and [Support and escalation for IBs](/ib/support). ## Where the IB deltas are Every callout in the space, so you can work through them in one pass: | Page | What differs for an IB | | --------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [Environments and endpoints](/environments#maintenance) | Execution-history retention is a reporting hazard, not a testing annoyance | | [Authentication](/authentication#generate-your-keys) | The missing key rotation procedure is a compliance exposure you will be asked about | | [Authentication](/authentication#scopes-and-entitlements) | You need `read:reports` and `read:cash-movements` from day one | | [Firms, participants and accounts](/identity) | A third identity — the IB anchor DCO account — and the legal-name rule | | [Limits and errors](/limits-and-errors#rate-limits) | The ledger CSV limit is what your reporting work hits first. You do not have FIX | | [Limits and errors](/limits-and-errors#error-catalog) | Two IB-only failures, including onboarding stalling with no error returned | | [Place an order](/orders) | No modify or replace exists at all; day orders and GTD are unreachable here | | [Outcomes and recovery](/outcomes#order-outcomes) | You see four states, not the exchange's six. Say so to a reviewer | | [Funding and transfers](/funding#move-cash) | The pool is the whole of the permitted structure; the sub-cent residue is a reporting problem | | [Balances](/balances#which-number-is-spendable) | These fields feed two of your named reports, and one read fails on participant accounts | | [Settlement](/settlement#who-credits-the-user) | You have no ledger to pay from, and you own the customer-facing explanation | | [Certification](/certification) | A gate with no ISV equivalent: the regulatory pack and the NFA/CFTC demo | | [Running it](/operations#reporting-and-bulk-export) | These surfaces are where your reporting pack comes from | ## Next The four things that break most ISV integrations, the responsibility split, and the gates to production traffic. The same sequence with your responsibility split, your licensing interaction, and the IB Agreement.