Services
Everything that has to be true before you submit.
Five connected workstreams built around one outcome: an evaluation you only pay for once. Start at design or start at code freeze — the earlier you start, the less the whole thing costs.
Compliance by design
The service that costs the least and saves the most. Instead of auditing a finished game, we work with your team from the design stage, so the requirements of the target market shape the build rather than arriving as a list of corrections after code freeze.
What we do alongside your team
- Requirements as acceptance criteria — the jurisdiction's rules translated into testable statements your engineers and QA can work from, before the sprint rather than after it
- Math model review at design time — RTP band, volatility target, max win and buy-feature permission checked against the market while the model is still cheap to change
- RNG and integration review at first implementation — seeding, scaling and range mapping reviewed when they are written, not when they are load-bearing
- Rules and UI specced against the standard — mandated statements, limits and disclosures written into the screen specs from the start
- Player-protection features in the backlog — session reminders, reality checks, autoplay constraints scoped as features, not bolted on in the last fortnight
- Evidence captured as you go — build manifests, hashes, change logs and test output accumulated during development instead of reconstructed from memory afterwards
- Continuous verification — RTP simulation re-run on each math change, so drift is caught the week it appears
Why it changes the economics
- A requirement missed at spec is a conversation; the same requirement missed after evaluation means another lengthy submission iteration and a delayed launch
- Changes made before code freeze do not carry regression risk across a frozen, already-signed build
- Your dossier is mostly written by the time you need it, because the evidence was captured live
- The math never has to be re-balanced late, which is where most late RTP failures come from
- Your team learns the standard once and carries it into the next title, so the second submission costs less than the first
Typically a light retained engagement running beside your sprints — a review cadence, an open channel, and a checkpoint at each milestone — rather than a full-time presence.
Compliance readiness & pre-certification
We run the evaluation before the evaluation. Your game is tested against the specific standard, version and jurisdiction appendix that will actually be applied to it, and you get the findings while they are still cheap to fix.
What we examine
- Requirement-by-requirement traceability against the target rule set
- RNG implementation: seeding, re-seeding, scaling, range mapping, cycling
- Paytable, reel strips, weight tables and their consistency with the math model
- Game logic: win evaluation, ways/lines direction, wild and scatter handling
- Feature triggers, retriggers, caps and buy-feature behaviour
- Round recovery: disconnection, power loss, duplicate bets, incomplete rounds
- Player-protection features required by the jurisdiction
- Rules, help and information screens against actual behaviour
- Meters, logging, significant events and reporting hooks
- Currency, denomination, bet limits, max win and max exposure handling
What you receive
- Readiness report — pass / conditional / fail per requirement, with the clause cited
- Findings register — each issue graded blocker, major, minor or observation
- Remediation plan — what to change, why, and what evidence proves it fixed
- Re-test pass — verification that closed findings stay closed
- Traceability matrix — the artefact that shows a laboratory you did the work
Findings are ours, not the laboratory's. A clean readiness report is a strong predictor of a clean evaluation, never a guarantee of one.
Bringing the product to standard
This is where the money is saved. A findings list is worth nothing if the fixes are guessed at — a wrong correction costs the same second evaluation as no correction. We stay with your engineers until every finding is closed the way the standard actually requires, and re-tested against the criterion it failed.
What we help you change
- Mathematics — re-balancing paytables, reel strips and weight tables to land inside the jurisdiction's RTP band without wrecking the game feel
- RNG integration — seeding, re-seeding, scaling and range mapping brought into line with the standard's requirements
- Feature behaviour — trigger and retrigger caps, buy-feature permission, maximum win and maximum exposure limits
- Round integrity — disconnection, power-loss and incomplete-round recovery made deterministic and provable
- Player protection — session reminders, reality checks, autoplay constraints, clock and net-position display per market
- Rules and information screens — brought into exact agreement with the paytable, the math and the mandated local statements
- Logging and meters — significant events, audit trails and reporting hooks the laboratory will ask to see
How we work with your team
- Each finding comes with the clause, the reason and a concrete recommended change — not "non-compliant"
- Your engineers implement; we review the change against the criterion before it is called closed
- Where a fix affects the math, we re-run verification rather than assume the model still holds
- Where a finding is a judgement call, we document the rationale you will put to the laboratory instead of quietly changing the game
- Closed findings are re-tested, and the register is the single source of truth from first pass to submission
We advise and verify; your team owns the codebase. Where you would rather we implement directly, that is scoped separately.
Submission document preparation
A technical dossier is not paperwork; it is the argument for your game. We assemble it in the structure laboratories expect, in the order they read it, with every claim traceable to something they can verify.
The dossier
- Game description, theme and full rules of play
- Mathematics report and PAR sheet with component RTP breakdown
- Paytable, reel strips, weight tables and symbol definitions
- RNG description, scaling method and independence statement
- Volatility, hit frequency, cycle length and max-win analysis
- Build manifest: version, file inventory, hashes and signatures
- Change log and delta analysis against any previously certified build
- Third-party and open-source component inventory
- Jurisdiction declarations and conformity statements
- Help, rules and responsible-gaming screen captures
- Test evidence: logs, screenshots and simulation output
And through the review
- Submission checklist tailored to the receiving laboratory or regulator
- Query handling — we draft the technical responses to RFIs
- Delta submissions — scoped packs for updates, so you are not re-certifying a whole game
- Version discipline — a single source of truth from freeze to approval
- Multi-market reuse — one core dossier, per-jurisdiction overlays
Document formats and required declarations differ by receiving body. We confirm the current template set at scoping rather than assuming last year's.
RTP & math verification
Independent simulation of your own engine at scale. We drive the production math code directly, so what we measure is what will ship — then we decompose the return until every basis point is accounted for.
Method
- Your engine is driven through a language-neutral harness — Go, Java, C, C++, C# and others
- Deterministic seed sets so any figure can be reproduced line for line
- Runs sized to the confidence interval you need, not to a round number of spins
- Separate runs per bet mode: base, ante, buy-feature and super-buy variants
- Component attribution: base game, free spins, features, jackpot contribution
- Convergence tracking, so we can show the estimate settling rather than assert it
- Cross-check against your declared theoretical model and paytable
Reported
- Simulated RTP with confidence interval and delta to declared theoretical
- Component RTP table and percentage-of-total split
- Volatility index, standard deviation and cycle length
- Hit frequency overall and per feature
- Max-win reachability and observed frequency in the tail
- Simulation manifest: engine hash, seeds, configuration, run duration
- Declared theoretical
- 96.50%
- Simulated
- 96.4831%
- Delta
- 0.017 pp
- 95% CI
- ±0.016 pp
- Hit frequency
- 24.61%
- Max win
- 5,000×
Illustrative report extract — sample figures, not client data. Every verification run ships with its seed set, engine build hash and simulation manifest so the result can be reproduced independently.
Next step
Send us one game and one target market.
Finished, half-built or still on a whiteboard — we will come back with a scoped plan, the document list your submission needs, and an honest view of what has to change before it is worth paying a laboratory to look at it.