This is where vendor due diligence separates the serious evaluations from the superficial ones.

A monolithic backend bundles all platform services (PAM, betting engine, risk management, CMS, payments) into a single deployable unit. Many legacy platforms and some current turnkey offerings still operate this way. Monoliths are simpler to deploy initially. They avoid the distributed systems complexity that microservices introduce: no service mesh to manage, no inter-service latency to account for, no distributed tracing to implement.

But monoliths scale poorly across two dimensions that matter to regulated operators: jurisdictional deployment and feature velocity.

When the UKGC mandates a change to affordability check thresholds or the MGA updates its player protection directives, a monolithic platform requires a full release cycle to implement what should be a localised compliance change. You can’t update the responsible gaming module without regression testing the entire application. In a multi-jurisdiction operation, this becomes an engineering bottleneck that directly impacts your ability to maintain licences.

Microservices decompose the platform into independently deployable services. Your wallet service, your bet placement engine, your KYC orchestration layer, your bonus engine (each operates, scales, and releases independently). Need to swap out your KYC provider for a specific jurisdiction? That’s a change to one service, not a platform-wide deployment.

The honest trade-off: microservices done badly are worse than a well-maintained monolith. They introduce distributed transaction complexity, require investment in observability tooling, and demand a team that understands eventual consistency patterns. If your engineering organisation isn’t ready for service-oriented architecture, forcing a microservices adoption will generate more technical debt than it resolves.

What to probe during vendor evaluation: ask how their platform handles jurisdiction-specific configuration. Ask whether compliance changes can be deployed independently of feature releases. Ask about their deployment pipeline for individual services versus full platform releases. The answers reveal the real architecture more reliably than any slide deck.

For operators running multi-brand or multi-jurisdiction portfolios, a service-oriented architecture isn’t a nice-to-have. It’s the difference between a platform that absorbs regulatory change and one that fights it.

Risk management and trading capability determine whether your sportsbook makes money or gives it away. Everything else (the frontend, the CMS, the bonus engine) is a cost centre without an effective risk and trading layer.

The core requirements: real-time liability management across markets, dynamic odds adjustment (particularly for in-play betting where latency kills margin), exposure limit configuration by market, event, and player segment, and automated suspension triggers for abnormal betting patterns.

Two models dominate.

Managed trading services mean the platform provider runs your trading desk. They set the odds, manage the liabilities, handle the in-play adjustments. Kambi is the best-known example of this approach. For operators without trading expertise or the appetite to build a 24/7 trading operation, this is the pragmatic choice. The downside: you’re dependent on the provider’s risk appetite and margin philosophy. You can’t differentiate on pricing. Your margins are, to a degree, their margins.

Self-service trading tools give your in-house team direct control over odds compilation, liability management, and market creation. This requires trading expertise and headcount, but it enables competitive differentiation on pricing, faster market creation for niche sports or local events, and the ability to tailor risk appetite to your specific player base.

The AI and ML conversation in risk management deserves honest framing. Vendors will talk about AI-driven fraud detection, ML-powered odds compilation, and predictive risk modelling. Some of this is real and production-grade. Much of it assumes a data infrastructure maturity that most operators haven’t achieved. Before evaluating AI risk capabilities, ask: does the platform provide real-time event streaming from the bet placement and wallet services? Can you access raw transactional data at the granularity needed to train models? Is there an ML feature store, or are vendors running batch predictions against yesterday’s data and calling it real-time?

The difference between a vendor that has deployed ML in production risk management and one that has a proof of concept running in a sandbox is the difference between operational capability and a marketing slide. Probe accordingly.

Regulatory compliance at the engineering layer is where platform limitations become most expensive to work around.

The UKGC‘s LCCP (Licence Conditions and Codes of Practice) requires specific responsible gaming functionality: deposit limits, loss limits, session time limits, reality checks, self-exclusion integration (with GAMSTOP in the UK), and affordability assessment triggers. The MGA has its own set of player protection requirements. The GGC, while historically lighter-touch, is tightening. US state regulations introduce per-jurisdiction variance that can be substantial.

From a platform perspective, the questions are:

Can responsible gaming parameters be configured per jurisdiction without code changes? Is the self-exclusion integration built as a pluggable service, or is it hardcoded to a single provider? Does the platform support configurable affordability check triggers that can be updated when the regulator changes thresholds (which the UKGC does)? Are audit trails generated automatically at the required granularity for regulatory reporting?

KYC and AML are similarly jurisdiction-dependent. Your platform needs to orchestrate multiple identity verification providers (because no single KYC provider covers all regulated markets equally well), support configurable AML transaction monitoring rules, and generate Suspicious Activity Reports in the format required by each jurisdiction’s Financial Intelligence Unit.

If the platform treats compliance as a monolithic feature set rather than a configurable, per-jurisdiction service layer, you will spend engineering time building compliance workarounds. That time accumulates. In a regulatory environment that’s tightening across every major market, a platform that can’t absorb compliance change without a full release cycle is a liability.

Ask providers for their compliance change log: how many jurisdiction-specific regulatory updates did they ship in the last 12 months, and what was the average time from regulatory announcement to production deployment? That number tells you more about their real compliance agility than any feature matrix.