A sportsbook supplier RFP is a request for proposal that turns an operator's requirements into answers the buyer can verify. It should identify the contracted product, permitted markets, decision owners, service commitments and evidence needed before launch. A feature list alone cannot establish which services are included or how an accepted bet will be handled during a failure.
This guide includes a 12-question worksheet for procurement, trading, technology and compliance teams. The questions and suggested tests are BetTimes editorial analysis, not a certification scheme or a ranking of suppliers. Public supplier documents illustrate the questions; we have not inspected private agreements or tested their live systems. British regulatory examples are bounded to Great Britain. Sources were checked on 11 October 2026.
Start the sportsbook supplier RFP with the actual product
Specify the countries, channels and products being considered, then ask for an itemised service schedule. An odds API, outsourced trading, a hosted sportsbook and an account-management system can have different responsibilities even when the vendor sells them together. Our odds feed versus managed trading guide explains those layers; this RFP concerns the evidence needed to accept a particular proposal.
Kambi's current portfolio separates Turnkey Sportsbook from Odds Feed+. Its turnkey product page describes trading, risk controls, front-end flexibility and optional additions, including its own PAM alongside the ability to use another PAM provider. These are company descriptions, not proof that every feature is included in a buyer's order. Ask the bidder to mark each requirement as included, optional, dependent on another service or unavailable.
The Sportradar account documentation provides another concrete distinction: subscribed API products contain packages, and trial and production access have different access conditions and limits. A working demonstration should therefore be tied to the exact product, package and production entitlement being quoted. Keep API credentials out of shared procurement sheets; record the product and evidence reference instead.
Twelve questions and the documents behind them
Record an answer and its supporting document, date and applicable scope. Where the bidder cannot provide evidence, retain the unresolved question rather than converting a sales assurance into a verified capability.
| Question | Evidence to request | Issue to resolve |
|---|---|---|
| Which legal entity and product are we contracting for? | Order form, entity details and itemised service schedule | Product name hides excluded modules or another contracting entity |
| Where may the proposed service be deployed? | Country, brand, channel and permission schedule | Supplier availability is mistaken for operator market access |
| Which data uses and onward deliveries are permitted? | Applicable rights clauses, competition coverage and restrictions | API access is treated as permission for every intended use |
| Who controls prices, exposure and bet acceptance? | Responsibility map, override permissions and decision logs | A managed function has no accountable decision owner |
| Which Bet Builder combinations and rules are supported? | Sport and market matrix, void rules and test cases | A headline feature does not cover the intended combinations |
| What exactly does the availability commitment measure? | SLA boundary, denominator, exclusions and incident record | Feed delivery is confused with successful customer bet placement |
| How does the system detect and handle stale in-play data? | Timestamp meanings, suspension logic and notification flow | A connected feed is incorrectly assumed to be current |
| How are missed and duplicate messages recovered? | Recovery specification and an observed replay test | Restored odds are mistaken for a complete settlement history |
| Who applies results, cancellations and corrections to tickets? | Versioned settlement rules and account-level reconciliation | A result message has no traceable effect on the accepted bet |
| What evidence can we retrieve for a disputed decision? | Sample audit export, identifiers, access rules and retention terms | A dashboard cannot produce the underlying decision record |
| What are the fees and change obligations for this scope? | Commercial schedule, minimums, add-ons and change process | Undisclosed dependencies prevent a comparable proposal |
| What happens to open bets and records when the agreement ends? | Exit assistance, export format, continuing service and deletion terms | A termination date leaves unresolved liabilities without an owner |
Download the sportsbook supplier RFP worksheet. Version 1, 11 October 2026, contains these same 12 questions with editable fields for the bidder's answer, evidence reference, review date, scope and unresolved issue. Blank fields mean information has not been supplied, not that a requirement has passed. Keep confidential contracts and personal customer data in the appropriate controlled repository rather than embedding them in a widely shared worksheet.
Ask for a coverage schedule rather than a global count
A useful coverage answer connects a competition to the relevant market types, pre-match or in-play service, channel and deployment territory. If player props or Bet Builder are needed, identify the combinations and exceptions that matter to the proposed operation. Ask how the supplier communicates a removed competition, changed data source or unavailable market.
The official sports data and rights guide explains why data, video, display and onward delivery need separate contract checks. Here the deliverable is a dated schedule attached to the proposal. A public portfolio description is useful for shortlisting, but it cannot answer whether a particular brand and country are covered by a customer's agreement.
For a Bet Builder, request worked rule examples covering a cancelled leg, a changed participant and a corrected result, as relevant to the offered product. The supplier should identify which rules govern the combined ticket and which system applies them. These are proposed acceptance questions, not findings that a named supplier's product handles an example incorrectly.
Separate service uptime from a usable betting journey
Require an SLA to name the measured component, observation point, time period and excluded events. A reachable API can coexist with missing markets or a failing bet-placement path. Define what counts as service failure for the contracted service, and what evidence the operator receives when an incident occurs. Do not insert an industry uptime benchmark or a generic launch deadline into an unanswered proposal.
In-play information introduces another boundary. British RTS 15 requires information explaining that live broadcasts are delayed and others may have newer information. It does not prescribe a universal end-to-end latency promise. A buyer still needs the technical meaning of each timestamp and a rule for suspending affected markets when freshness cannot be established. Our in-play delays and suspensions guide covers the player-facing distinction.
Rehearse recovery with an accepted ticket
Sportradar's Unified Odds Feed recovery documentation distinguishes current odds recovery from a complete history of price changes. It also warns that messages can arrive more than once and that settlements may be combined during recovery. Those are product-specific integration details. They show why a successful reconnection is insufficient evidence that every account entry is correct.
For a proposed acceptance test, use synthetic tickets and retain the sequence that matters: acceptance, disconnection, recovery, settlement and any subsequent correction. Request a replay of one previously processed settlement alongside a previously missed one. The test should show that the first does not credit the account again and that the second is applied under the correct ticket rules. Identify how the implementation recognises an already processed event; do not assume a particular identifier works for every provider.
In Great Britain, RTS 5 calls for reasonable steps to accept, process and settle gambles according to published rules and remedy faults affecting customers fairly. Its guidance includes testing against those rules and notifying customers about relevant errors. The bet-settlement explainer covers the underlying ticket states. For procurement, ask which party can reconstruct the accepted terms, result version, correction and resulting account entries.
Verify the scope of testing and accountability
The GLI standards index lists GLI-33 Event Wagering Systems v1.1. It also explains that jurisdictions set their own standards and may use GLI standards as a starting point. The existence of a laboratory standard does not establish that a proposed implementation has passed it or that it replaces the target market's rules.
Request the actual report or relevant evidence for the product version, tested components and jurisdiction, then compare that scope with the configuration being purchased. A report for one deployment should not silently become approval for a new integration. The Gambling Commission's equipment guidance describes functions such as bet capture, settling and account records, without prescribing one architecture. Use the system inventory to locate the interfaces that require review rather than relying on the front-end product name.
British LCCP 1.1.2 keeps licensees responsible for contracted third-party activities related to licensed business. It requires contractual compliance and information provisions, and prompt termination rights in the stated circumstances, subject to dispute-resolution provisions. Outsourcing a task therefore needs a documented accountability and evidence-access arrangement. Other markets need their own review.
Keep unresolved evidence separate from preference
Compare proposals against the same defined deployment. Mark which questions have documents, which have only a bidder's statement and which remain unanswered. A price advantage or attractive interface cannot resolve a missing permission or an unowned settlement process. Equally, an unavailable optional feature need not disqualify a service that meets the actual requirements.
Before choosing a supplier, nominate who approves the commercial schedule, technical tests and market-specific compliance review. Agree which exceptions prevent launch and which can be resolved through a documented change. This guide does not assign weights or scores: those depend on the buyer's needs, and a score must not hide an unresolved required condition.
Include exit testing in the proposal review. Specify who completes existing tickets after termination, what identifiers and histories are exported, and how the operator retains access to complaint evidence. Our casino platform migration guide gives the wider account-handover checklist; sportsbook exit planning adds the continuing ownership of accepted wagers.
Frequently asked questions
Does a sportsbook supplier licence authorise the operator?
Do not assume so. The proposal needs separate evidence for the supplier's activity and the operator's permission in the target market. A product being available, or a report describing its tested version, does not by itself establish that a particular operator may accept wagers through it.
Is a product demonstration enough to approve the RFP?
A demonstration is useful for examining a feature, but it should be matched to the proposed product, production package and configuration. Contract scope, rights, service commitments and acceptance-test evidence remain separate. Record exactly what was demonstrated and which unanswered requirements still need documents or testing.
What is the most useful recovery test to request?
Follow a synthetic accepted ticket through a connection loss, recovery and settlement, including a repeated message and a later correction. Reconcile the resulting account entries to the ticket and published rules. The implementation's product-specific specification determines the expected handling; this article does not report an executed supplier test.
Retain a proposal file that explains the decision
Keep the signed scope, dated evidence and accepted exceptions together with the test results and responsible reviewers. A sportsbook supplier RFP is useful when the buyer can trace a promised capability to an applicable contract or an observed implementation result. If that link remains missing, keep the question open rather than describing the service as verified.