Research notes on Bet365 Poker bots and the iPoker Network ecology.

Bet365 Poker in one page

Bet365 — the UK gambling group built by Denise Coates and family from a Stoke-on-Trent caravan park in 2000 — runs one of the larger online sportsbook and casino operations in regulated Europe. Bet365 Poker sits inside that group as a smaller revenue line, with the poker product itself white-labelled from Playtech's iPoker Network rather than built in-house. The legal operating entity is Hillside (UK Gaming) Ltd; the poker client is a re-skinned iPoker client; the liquidity is shared across iPoker skins.

That structure changes almost every interesting question about bots on the platform. The traffic numbers a player sees on a Bet365 Poker table are network-wide, not operator-wide. The RNG is Playtech's. The anti-cheat that watches multi-account collusion and bot farms is Playtech's. Bet365 contributes a fraud and KYC team — built for the sportsbook side, where the money sits — and the operational decision to ban an account. Network and operator each cover roughly half of the detection picture.

From a product perspective Bet365 Poker offers what the iPoker schedule offers: NLH cash from €0.02/0.05 up through roughly €5/10, the Twister-branded Spin format at €1 to €25 buy-ins with random multipliers up to 1000x, Speed Poker (the iPoker fast-fold variant comparable to Rush & Cash or Zoom), and a thinly populated MTT schedule. UK and several EU markets are served; US is locked out, as you would expect for a Hillside-licensed operator.

The iPoker Network architecture

iPoker has been around since 2004. Playtech acquired it in 2007 and has run it as a B2B liquidity platform since — operators license a skin, brand it, and share the player pool. The Bet365 skin is one of the better-known active skins; Coral, Betfair, Titan Poker, Betsson historically, and a long tail of regional operators sit on the same network. The historical roster matters because it shapes the detection question: a bot that runs on Bet365 is observed by Playtech across every skin in the network, not just Bet365.

Three architectural points are worth pulling out for an engineering audience:

Shared anti-cheat at the network level

Playtech runs the behavioural-fingerprint pipeline, the statistical play-pattern analysis, and the collusion graph across the whole network. The data joins on Playtech's internal player IDs, which span skins — a player who registers separately at Bet365 and Coral with the same device and KYC document is still one node in the graph.

RNG and audit at the network level

The shuffle and the audit chain run on Playtech infrastructure. eCOGRA historically attested the iPoker RNG; current attestations are licensed-jurisdiction-specific (UK Gambling Commission, Isle of Man, Malta, Romania, Spain). The audit does not prove security; it confirms that the audit happened.

Operator-level fraud and KYC

Each skin runs its own customer-facing risk team. Bet365's is sportsbook-grade — large, well-funded, used to thinking about chargebacks, identity theft, and arbitrage. The poker-specific knowledge is thinner than at a pure poker operator, but the fraud machinery sitting underneath is heavier than what a pure poker operator typically affords.

The practical consequence for a bot author is that the detection signal is more diffuse than at a single-skin operator. A play-pattern outlier that survives Bet365's review queue can still be flagged by Playtech weeks later when the same fingerprint appears on a sister skin. The catch rate is correspondingly slower and less consistent than at GGPoker — but it is not zero, and the volume across skins gives the network a larger reference distribution than any individual skin would.

What we mean by "poker bot" in 2026

The phrase "poker bot" gets used so loosely in public discussion that almost every conversation starts on the wrong foot. For the purposes of this site, a poker bot is a piece of software that takes visible game state as input — your seat's hole cards, the community cards, the action sequence, stacks and positions — and emits an action under a real-time latency constraint. A poker bot does not read network packets. It does not know opponent hole cards before showdown. It does not predict the deck. Everything it does, a human could do with the same information; the human would just be slower, less consistent, and unable to play eighteen tables at once.

The interesting work sits in three layers underneath that definition. A solver-anchored baseline compiles CFR-derived strategies — Pluribus-style for multiway 6-max NLH, PioSolver or GTO+ for heads-up trees, MonkerSolver for the parts of PLO that anyone has the patience to solve — into compressed action-frequency tables keyed on bucketed game states. An online opponent model updates lightweight statistics over the session, since long-horizon HUD data is unreliable across iPoker's skin rotation. And a policy combiner decides how far to deviate from the baseline given the current opponent estimate, with detection-aware noise on the output distribution.

How detection actually works on iPoker

Detection is a stack of asynchronous signals weighted into a per-account score, exactly as on every other serious operator. The novelty at iPoker is the network-versus-operator split. Some layers run at Playtech and see every skin; some layers run at Bet365 and see only Bet365 traffic plus the KYC and payment context. The combined picture looks like this:

Behavioural fingerprinting (Playtech)

Client telemetry on input timing, mouse-path geometry on desktop, touch dwell and pressure on mobile, action-confirmation latency, idle behaviour between hands. The pipeline runs across all skins; the per-account score is portable. Cheap to compute, runs continuously, bites naive implementations hardest.

Statistical play-pattern analysis (Playtech)

Per-account distributional analysis on VPIP, PFR, 3-bet by position, bet-sizing histograms, fold-to-cbet by board texture. Network-scale data joins make this layer stronger at iPoker than the user-facing skin volume suggests. Pure GTO output stands out paradoxically faster than a noisier strong-human strategy.

Anti-collusion graph (Playtech)

Account graph joined by IP, device fingerprint, deposit method, KYC document, table co-occurrence. Bot farms appear here when run under shared infrastructure; chip dumping and soft-play also fall out of the same graph.

Operator fraud + KYC (Bet365)

Sportsbook-grade fraud surface — payment-pattern anomalies, ID verification, source-of-funds checks at thresholds set by UK and EU regulators. Less poker-specific intelligence than Playtech's pipeline, but heavier identity and payment scrutiny than most pure poker operators run.

Human review

Final decision point, split across both organisations depending on the signal mix. Statistical-only flags route to Playtech analysts; KYC-or-payment flags route to Bet365; mixed cases go through a joint review. The bottleneck is human reviewer capacity, as everywhere.

The detection page covers the four-layer model in depth, including the action-timing distribution that catches the bulk of naive implementations and the adversarial-classification frame that makes "anti-detection as feature checklist" the wrong frame.

Areas covered on this site

Where the real engineering questions are

The notes on this site are a working document. Five threads I think are genuinely open in the iPoker context:

1. Cross-skin behavioural-fingerprint portability. Playtech joins behavioural data across all skins. The question is how much variance a single account's fingerprint can carry across sessions before the cross-skin classifier flags it — and whether session-level fingerprint shaping helps or just makes the per-session variance itself the signal.
2. Online opponent modelling under skin rotation. The reg population at iPoker mid-stakes is small enough that long-horizon observation across skins is theoretically useful, but operator-side HUDs are banned and external HUDs are blocked by client-side process detection. The compromise is online estimation; convergence under thin volume is harder than at higher-traffic operators.
3. Twister / Spin engine economics. Multiplier variance at €1–25 buy-ins is severe; the EV signal arrives over tens of thousands of games. The interesting engineering question is whether opponent modelling has any role at all — versus a pure push-fold engine with multiplier-aware ICM.
4. Adversarial-classification framing under split detection. The classifier in the iPoker setting is two classifiers stacked: a network-side play-pattern model and an operator-side fraud model. Their decision boundaries are different shapes, and optimising for one can make the other worse. The right formal frame is multi-classifier adversarial selection; the literature thins out fast past two-player settings.
5. Where to point engineering effort. The EV-per-engineering-hour curve for serious modern poker AI peaks at GGPoker, not Bet365 or iPoker. Bet365 work is interesting for cross-skin questions and as a softer-population destination; it is not the place to grind out a primary income line. If your project is a primary income line, this site is partial — the homepage of the parent project covers the bigger picture.

Corrections, contributions, and pointers to relevant data are welcome through the chat. The notes here move when the field moves; the dates at the top of each piece are the last revision, not the original publication.