Process structure only. Certification scope, testing regimes, permitted parameters and submission routes are set per market by the regulator and its recognised testing houses — confirm current requirements there and through product-level legal advice.
The five gates
A launch date is only as real as its slowest gate, and the gates have different owners, different failure modes and — critically — different counterparties:
| Gate | Owner | External dependency |
|---|---|---|
| Commercial | Business | Contracts, content rights and territories with each supplier |
| Legal / permission | Compliance | Regulator processing, on the regulator's own timetable |
| Technical certification | Engineering + compliance | Testing-house queue, review rounds and re-submission |
| Operational integrations | Payments, data, support | PSP onboarding, reporting channel, exclusion register where one exists |
| Operational readiness | Operations | Trained staff, runbooks, incident and complaint paths |
Notice that four of the five depend on someone outside the company. That is why an internal delivery estimate is not a launch date, and why the honest version of a plan states each gate separately rather than collapsing them into one bar on a slide.
What certification covers — and what it does not
Certification establishes that the system behaves as specified against a defined test scope. It does not grant permission to operate, does not confirm your commercial rights, and does not validate the parameters you chose within the permitted range. Operators who treat a certificate as a green light discover the gap at the point of the first regulator query.
Establish two things early, in writing:
- The scope boundary. Which components, integrations and parameter ranges are inside this certification.
- The change rule. What kinds of change require re-submission, and what turnaround that carries. This single rule sets the ongoing cost of compliance changes for the life of the market — see why a configurable product wins here.
Sequencing: run the external dependencies in parallel
Most slipped launches are not caused by a hard task. They are caused by discovering a lead time serially — payment onboarding started after certification, reporting channel requested after that, support training last. Each is short on its own; in sequence they add a quarter.
| Start early, in parallel | Because the lead time is not yours |
|---|---|
| Payment provider onboarding | Underwriting and account setup run on the provider's schedule |
| Reporting channel setup | Credentials, formats and test submissions often involve the regulator directly |
| Exclusion-register integration | Where a national register exists, access is granted on its own process |
| Testing-house engagement | Queue position is a real constraint; book before the build is finished |
| Support and complaints readiness | Staff training and documented paths cannot be compressed at the end |
The pre-launch checklist
- Configuration confirmed. Every market row set, with no value inherited by accident from another market.
- Verification flow tested end to end in the market's actual conditions, including the failure paths.
- First reporting submission rehearsed against the real channel, not simulated internally.
- Responsible-gambling tools live and reachable, with intervention ownership assigned.
- Payout path proven with a real withdrawal, including the verification gate in front of it.
- Rollback and incident plan written, with the decision owner named.
- Evidence pack assembled — configuration versions, certification references, test results — so the first regulator question is answered from a folder rather than an investigation.
After go-live
The first reporting deadline usually arrives sooner than teams expect, and the first regulator query often follows the first complaint rather than the first month. Both are routine if the evidence pack exists. Keep the launch configuration frozen and observed for a defined period before starting optimisation work — separating "does it operate correctly" from "does it perform well" is what makes either question answerable.
Continue reading: Regulatory reporting — the deadline that lands first. Launching prediction markets — the same gate discipline applied to a new product line.