Methodology & disclosures

Methodology v1.0 — Published/Updated: 2026-01-12

Why we publish this

igaming-solution.com is a B2B comparison and research platform for iGaming operators and industry stakeholders. This page explains:

• what our Readiness Score means (and what it does not mean),
• how we collect and verify information,
• how rankings are produced,
• how partnerships and sponsored visibility are handled,
• how providers can request corrections.

Our goal is to make comparisons repeatable, inspectable, and operator-relevant — not to publish “marketing scores”.

What the Readiness Score is (and isn’t)

Readiness Score (0.0–5.0)

The Readiness Score is a criteria-based benchmark that summarizes how well a provider’s offering typically supports regulated, multi-market operations.

It is:

• a structured assessment of maturity and operator fit,
• based on evidence we can verify (see “Evidence Standards”),
• updated when material facts change or on scheduled review cycles.

It is not:

• a customer review average,
• a popularity metric,
• a promise of performance or commercial outcome,
• a guarantee of licensing, compliance approval, or regulatory acceptance.

Why we use 0.1 increments

Scores are displayed in 0.1 increments to reflect meaningful differences in maturity. This does not imply scientific precision. Where evidence is limited, we score conservatively.

Who the table is for

Our comparisons are designed primarily for:

• operators evaluating platforms, sportsbook/casino solutions, aggregators, payments, KYC/AML, CRM, and related B2B infrastructure,
• product and compliance teams looking for a shortlist aligned with regulated-market needs.

If you are an end user/player, this site is not intended to help you choose where to gamble.

Inclusion criteria

A provider can appear in comparison tables when it meets baseline eligibility, such as:

• clear product/service scope (what it offers, what it doesn’t),
• identifiable company/entity information (brand + company details),
• sufficient public information to evaluate at least the core pillars,
• no unresolved high-confidence evidence of deceptive claims about licensing or ownership.

We may exclude or remove providers that repeatedly publish misleading claims or refuse to correct material inaccuracies.

Data sources we use

We rely on a mix of public and provider-submitted information:

Primary sources (preferred)

• official provider documentation and product pages
• technical docs (APIs, integration guides, SDK references)
• compliance/terms/policy documentation
• public announcements with verifiable details (e.g., product releases, integration updates)

Secondary sources (supporting)

• reputable industry publications and conference materials
• public registries where applicable (e.g., corporate registries, licensing info where verifiable)
• third-party technical references (only when primary sources are absent)

Provider-submitted updates

Providers may submit updates or clarifications. We treat these as claims until verified via public documentation or other verifiable evidence.

Evidence standards (how we decide what to trust)

We score using an evidence hierarchy:

Tier A — Verified, primary

• publicly accessible official documentation
• direct product evidence (public API docs, feature matrices, release notes)

Tier B — Corroborated

• multiple consistent reputable sources
• conference decks + matching public documentation

Tier C — Provider claim (unverified)

• sales decks, private emails, or claims not supported publicly
  ➡️ Tier C is scored conservatively or treated as “unknown” until verified.

If we can’t verify a key claim, we don’t score it as true.

The scoring framework (pillars and weights)

Overview

Each provider is evaluated across six pillars. Each pillar is scored 0.0–5.0 and combined into a weighted average:

Readiness Score = Σ (Pillar Score × Weight)

Default weights (general B2B operator readiness)

1. Regulatory & compliance maturity — 20%
2. Integration ecosystem depth — 20%
3. Platform architecture & scalability — 20%
4. Delivery model & ownership — 15%
5. Operational tooling — 15%
6. Market applicability (operator fit) — 10%

Note: Some tables may use scenario-specific weights (e.g., “startup speed”, “high-regulation expansion”). If weights differ, they are explicitly shown on that table.

Pillar definitions (what we look for)

1) Regulatory & compliance maturity (20%)

Assesses readiness for regulated environments and operator obligations.

Signals may include:

• KYC/AML support options and workflows (capability clarity, not “claims”)
• reporting and audit-readiness features (where documented)
• player protection / responsible gambling tooling support (if applicable)
• clarity of compliance responsibilities (who does what: operator vs provider)

Common reasons for lower scores:

• vague claims like “fully compliant” without documentation
• missing clarity on responsibilities and audit/reporting capabilities

2) Integration ecosystem depth (20%)

Measures how easily an operator can integrate key components.

Signals may include:

• breadth of documented integrations (payments, KYC, risk, games, etc.)
• quality of integration documentation (APIs, SDKs, versioning)
• existence of integration partners and how well they’re documented
• clarity on integration timelines and dependencies

Common reasons for lower scores:

• partner logos without integration specifics
• undocumented or inconsistent API references

3) Platform architecture & scalability (20%)

Evaluates technical maturity and operational resilience.

Signals may include:

• modularity and separation of components
• reliability expectations (SLA references if publicly stated)
• deployment model clarity (cloud/on-prem/hybrid), scaling considerations
• data handling boundaries (conceptual clarity, not legal guarantees)

Common reasons for lower scores:

• no architectural clarity (only marketing terms)
• missing operational constraints (limits, dependencies, known trade-offs)

4) Delivery model & ownership (15%)

How the delivery approach fits different operator needs.

Signals may include:

• clear offering types (licensed / managed / white-label / hybrid)
• operator control vs speed-to-market trade-offs explained
• migration/exit considerations (where documented)
• configuration ownership (what operators can control)

Common reasons for lower scores:

• unclear ownership boundaries
• “white-label” positioning without explaining control limitations

5) Operational tooling (15%)

How well the product supports day-to-day operations.

Signals may include:

• back-office capabilities, reporting, configuration tools
• monitoring/alerts/controls (where documented)
• role management and workflow support (if documented)
• tooling clarity for support and incident handling

Common reasons for lower scores:

• no documented operational tooling depth
• reliance on generic “dashboard” claims

6) Market applicability / operator fit (10%)

Not “best overall” — best-fit for operator profiles.

Signals may include:

• clarity on target operator segment (startup/mid/enterprise)
• jurisdiction/multi-market suitability (where verifiable)
• product constraints clearly documented (what it’s not good for)

Common reasons for lower scores:

• broad “fits everyone” messaging without boundaries

How rankings are produced

• Rankings are typically sorted by Readiness Score (highest to lowest) within the table’s scope.
• If a table uses scenario weights, ranking reflects that scenario.
• If two providers are very close, we may group them as “comparable” and highlight fit differences rather than implying one is universally better.

Star rating: what it means

Stars are a simplified display of the same score for quick scanning.

Typical mapping (may vary by table):

• 4.6–5.0 = 5 stars
• 4.0–4.5 = 4 stars
• 3.5–3.9 = 3.5 stars
• 3.0–3.4 = 3 stars
• below 3.0 = limited readiness for regulated, multi-market use cases (or insufficient evidence)

We prefer showing precise pillar breakdowns when possible because operator fit matters more than a single number.

When we score conservatively

We score conservatively when:

• key claims cannot be verified publicly,
• documentation is missing or contradictory,
• product scope is unclear,
• ownership, licensing, or compliance statements are not supported by verifiable evidence.

“Unknown” does not mean “bad”, but it reduces readiness confidence.

Review cadence and change logs

• Major comparison tables are reviewed on a scheduled cycle (e.g., quarterly) and also updated when we detect material changes.
• Each provider profile may show a “Last reviewed” date.
• We maintain internal change logs for material scoring changes (e.g., new integrations, delivery model changes, documented compliance tooling).

Corrections and provider participation

Providers can request corrections by contacting us with:

• the exact statement/field to update,
• the supporting evidence (ideally public documentation links),
• the effective date of the change.

We may:

• update factual fields quickly once verified,
• re-score pillars if changes are material and supported by evidence,
• annotate “provider-submitted” updates until verified.

Partnerships, sponsored visibility, and independence

Key principle

Partners do not buy scores or rankings.
Partnerships may include visibility products (e.g., featured placement), but scoring remains criteria-based.

What partnerships can include

• enhanced profile completeness (structured data collection and verification)
• expedited review scheduling (review sooner, not scored higher)
• featured visibility in designated comparison areas

How we disclose sponsored/featured placements

• Featured listings are labeled as “Featured” or “Sponsored visibility” where they appear.
• Featured visibility does not change the underlying pillar scores; it affects placement in a designated featured area only.

Conflict-of-interest guardrails

• editorial scoring decisions are separated from commercial arrangements
• scoring changes require evidence-based justification
• any material relationship is disclosed where relevant

Limitations

• The Readiness Score is a decision aid, not a substitute for procurement due diligence.
• We cannot access private contracts, internal SLAs, or customer-specific implementations unless publicly verified.
• Provider offerings can vary by jurisdiction, integration set, and commercial terms — operators should validate final fit through an RFP or pilot.

Contact

For corrections, evidence submissions, or methodology questions, contact: contact@igaming-solution.com