The account is shared. The models are not
- Kevin Jones
- 42 minutes ago
- 6 min read
Every supplier now sells convergence: poker and casino under one account, a shared balance, players moving freely between the two. The commercial case makes itself. The build is where it falls apart, because the two products run on opposing assumptions. Poker is peer-to-peer and depends on pooled, often cross-border liquidity. Casino is house-banked and certified jurisdiction by jurisdiction. Put them behind a single balance and the hard questions start: how funds are reserved and reconciled, how risk is controlled separately for each product, how liquidity and content are gated by market, and what happens when a tournament spikes or a provider fails. EvenBet Gaming launched its casino platform and aggregator this year after two decades in poker, which puts its CTO, Alexander Tamplon, on the operator-facing side of these problems. The Q&A is where the trade-offs get concrete: controlled shared balances, wallet idempotency, jurisdictional rules engines, scaling under load, and the cost of integrating 15,000 titles across 230 providers.
Gaming Eminence: EvenBet has been known primarily as a poker supplier for more than 20 years. From a technology and architecture perspective, what actually changes when you move from a specialist poker platform into a broader casino platform and aggregator?
Alexander Tamplon: "We are systematically moving towards an "iGaming supermarket" model for operators, expanding from a standalone poker platform into casino aggregation, One Click solutions, exclusive card games and integration services. The platform shifts from managing poker gameplay alone to becoming a core part of the operator's business ecosystem.
Poker's architecture centres on a real-time multiplayer engine, liquidity, tournament lifecycles and game integrity. Casino and aggregation bring an entirely different set of challenges: a huge game catalogue, integrations with hundreds of third-party providers, provider wallets, round lifecycles and compliance logic.
That means moving from a product-centric view to a service-oriented model, where the poker engine, casino aggregator, wallet, bonus layer, RG tools, BI and back office are interconnected without becoming a tightly coupled monolith. A key trade-off is integration depth. A unified account and UX is desirable, but poker and casino run different risk models, transaction flows and latency requirements, so we deploy distinct domain services behind strict contracts, with a dedicated environment for each major operator."
Gaming Eminence: Poker is peer-to-peer, with the operator taking rake, while casino is house-banked and carries a different liability and risk model. When both sit under a single account and shared balance, how does the platform handle those two models at wallet, transaction and risk-control level?
Alexander Tamplon: "The defining concept isn't a shared balance but a controlled shared balance. In poker, funds are usually reserved or escrowed (buy-ins, rebuys, add-ons, prize pools) rather than deducted as a simple wager. Casino transactions are simpler in form but carry far more provider dependency, rollback and round-state complexity. The platform also has to partition funds by balance and bonus type and calculate wagering requirements precisely.
Our core principle is strict idempotency, where every operation is fully traceable and reversible through a defined correction flow. That is critical when integrating tier-one operators on a seamless wallet model, where we can't rely on local state alone and have to handle callback latency, retries, partial failures, and temporary state divergence between the game and the wallet.
Risk controls diverge too. Poker focuses on collusion, chip dumping and abnormal win rates. Casino focuses on bet limits, house exposure and bonus abuse. Global thresholds such as deposit limits apply universally, with product-specific limits enforced independently by each domain."
Gaming Eminence: Poker often depends on shared or international liquidity, whereas casino content is typically certified and ring-fenced by jurisdiction. When both run under a single account, how do you reconcile cross-jurisdiction poker liquidity with jurisdiction-locked casino content, and what does that mean for operators active across multiple regulated markets?
Alexander Tamplon: "We separate three layers: account, liquidity, and content entitlement. A unified account is an identity and wallet relationship. It does not mean all content and liquidity is universally accessible. Access to a specific liquidity pool, game, bonus or tournament is governed by a rules engine that evaluates jurisdiction, licensing, location, KYC status, brand, currency and RG standing in real time. In the US sweepstakes market, for example, we separate poker and casino access at state level under a single operator brand, aligning the UX with localised compliance.
Poker's value depends on liquidity mass, so operators often want shared pools across markets. Casino content, by contrast, can be certified for one jurisdiction and restricted in another, for reasons ranging from RTP requirements to local licensing. The trade-off is between liquidity, simplicity and compliance isolation, so the right model is configurable segmentation: one core platform driving distinct pools, catalogues and reporting per market, rather than rigid isolation or blanket aggregation."
Gaming Eminence: For tier-one operators, scalability is about resilience, uptime and performance under load, not just launch speed. What are the main pressure points when combining poker liquidity, real-time gameplay, casino content and aggregation at scale?
Alexander Tamplon: "The critical pressure points are tournament starts, mass registrations, late-registration close, payout calculations, reconnect storms, provider degradation and bonus campaign launches.
Poker's high-load scenarios include mass authorisation before major events, registration storms, late-registration closing windows, dynamic table balancing, post-disruption reconnect storms, and simultaneous prize calculations across thousands of tables. Casino's load profile is different: concurrent game launches, provider callbacks governing debits, credits and rollbacks, high-velocity short sessions and real-time jurisdictional filtering on every launch.
The architectural objective is to stop one domain's degradation bleeding into the other. We enforce that through separated processing pipelines, backpressure and rate limiting, circuit breakers on external providers, strict idempotency, an event-driven outbox approach, and deep observability at product, provider and transaction-type level.
For tier-one operators, predictability matters most. Not just whether the platform survives a 10x spike, but exactly how it behaves when dependencies fail, which is why we design for graceful degradation, disabling non-essential features while the core transactional and gameplay engines stay up."
Gaming Eminence: Your aggregator includes more than 15,000 titles from more than 230 providers. What are the biggest technical and compliance challenges in managing that volume across integrations, metadata, certification, availability, jurisdictional rules and performance?
Alexander Tamplon: "At this scale, the challenge isn't connecting a provider. With AI now built into our Content Development Life Cycle, foundational integration can take days rather than weeks. The real complexity is managing the content lifecycle systematically.
Every provider has its own API conventions, transaction semantics, rollback rules, and jackpot and bonus mechanics. Integrating each directly into the operator-facing layer would be unmanageable, so we normalise these variables into a unified contract, without stripping out the provider-specific features operators still need.
Metadata management is its own challenge. More than 15,000 games need dynamic categories, languages, currencies, RTP, volatility and market availability, all filterable by country and aligned to compliance rules instantly. The broader industry issue is the lack of standardised APIs among casino and payment providers, which forces platforms to spend hundreds of man-hours per integration. It ultimately means good games can miss operators simply because integrating them isn't commercially viable. Our goal is content that is genuinely manageable, not just high in volume."
Gaming Eminence: Many established operators already have a PAM, wallet, CRM, payments stack, KYC provider, BI layer and RG tooling. How do you approach integration when the operator wants a unified poker and casino ecosystem without replacing its existing infrastructure?
Alexander Tamplon: "We act as a content and product provider, not an infrastructure replacement. Through our unified API, operators access our poker engine, One Click solutions, exclusive titles and 15,000+ third-party games under a single commercial contract, using the same integration pipelines they already run for other providers. We have deliberately aligned our multiplayer games with the traditional casino model, including a distinct round that opens and closes cleanly, so operators can apply their standard bonus, wagering, reporting and RG flows without special-casing our products. For advanced tier-one setups, we expose an Event Bus, MQ integration and REST APIs, allowing operators to stream raw object data into their proprietary BI, keep localised caches updated, and power custom analytics without touching the core transactional engine.
The operator remains the source of truth for player account, KYC, payments, master wallet and RG. EvenBet owns the poker engine, casino aggregation, game sessions and content catalogue. Externally it is a seamless offering. Internally, we orchestrate around the infrastructure and compliance frameworks the operator already has."
