Multi-Product Tournaments: Same Leaderboard, Different Rules

Why tournaments matter

Tournaments are one of the most effective engagement tools in iGaming. They give players a reason to play more, a reason to compete, and a reason to come back. A well-run tournament creates urgency — a leaderboard that updates in real time, a prize pool that grows, a deadline that forces action. The psychological mechanics are well understood: competition drives session length, and session length drives revenue.

But most tournament systems are built for a single product vertical. A casino tournament tracks slot wagers. A sportsbook tournament tracks bet volume. A bingo tournament tracks ticket purchases. Each vertical has its own leaderboard, its own scoring logic, its own prize distribution workflow. This means the operator runs three separate engagement systems instead of one, and the player who plays across products never sees a unified competitive experience.

The harder problem is architectural. Running a tournament across different game types means normalizing fundamentally different event structures into a single scoring model. A casino spin, a sportsbook accumulator, and a bingo ticket are not the same thing. They have different stake structures, different outcome timings, and different margin profiles. Treating them as equivalent without a weighting system produces leaderboards that don't reflect actual engagement — and players notice.

PAM's tournament system was designed from the start to work across the entire product catalog. Not as an afterthought, not as a separate module per vertical, but as a single engine that consumes events from every product and normalizes them into a unified leaderboard with configurable scoring rules.

Cross-product leaderboards

A single tournament in PAM can span Casino, Sportsbook, Bingo, and Fantasy Sports simultaneously. Each product contributes to the same leaderboard, but the contribution is governed by configurable weight multipliers that the operator defines per tournament.

Weight multipliers exist because a 10 EUR casino spin and a 10 EUR sportsbook bet are not equivalent engagement signals. The casino spin resolves instantly and the margin is known. The sportsbook bet might not settle for days, and the margin varies by market. Without weighting, a player who places one large accumulator could dominate a leaderboard over a player who has been actively spinning for hours. That's not the competitive dynamic most operators want.

The weighting configuration is per-tournament, not global. An operator might run a "Weekend Warrior" tournament where sportsbook bets carry a 1.5x multiplier because the goal is to drive weekend sports engagement. The next week, they might run a "Slots Showdown" where casino wagers carry a 2x multiplier. The scoring engine doesn't change — only the configuration does.

Leaderboard updates happen in near real time. When a qualifying event is processed, the player's tournament score is recalculated and the leaderboard position is updated. Players see their rank change as they play — that immediacy is what makes tournaments feel competitive rather than administrative. The leaderboard state is cached in Redis and pushed to connected clients via SignalR, so there's no polling lag between the event and the UI update.

Event listeners per product

The foundation of cross-product tournaments is the event listener layer. Each product vertical has a dedicated listener that captures relevant events and normalizes them for the scoring engine. This separation is deliberate — the listener understands the semantics of its product, and the scoring engine doesn't have to.

• CasinoWagerListener — captures every completed game round from every integrated game provider. It extracts the stake amount, game category, and round result. It knows that a bonus-funded spin and a cash-funded spin might score differently depending on tournament configuration.
• SportsbookWagerListener — captures bet placement events from the sportsbook integration. It handles singles, accumulators, and system bets. For tournaments scored on placement (not settlement), it fires at bet acceptance. For settlement-scored tournaments, it fires when the bet result is confirmed.
• BingoWagerListener — captures ticket purchases and, optionally, side-game activity within bingo rooms. Bingo has unique scoring considerations because a single ticket purchase might represent participation in multiple games within a session.

Each listener produces a normalized event payload that the scoring engine consumes. The engine doesn't know or care whether the event came from a slot spin, a football accumulator, or a bingo ticket. It receives a player ID, a stake amount, a product type, and metadata — and it applies the tournament's scoring rules. This normalization boundary is what makes the system extensible. When a new product vertical is added to the platform, adding tournament support means writing a new listener, not modifying the scoring engine.

The listeners run on the same event infrastructure as the rest of the platform — the RabbitMQ-based message bus that BeAware and other consumers use. Tournament event processing doesn't require a separate message pipeline. It subscribes to the same streams, which means it benefits from the same delivery guarantees and the same operational monitoring.

Tournament lifecycle

Every tournament in PAM follows a defined lifecycle: creation, registration, active, settlement, and prize distribution. Each stage has its own validation rules and state transitions, and the system enforces them strictly — you cannot settle a tournament that hasn't ended, and you cannot distribute prizes for a tournament that hasn't been settled.

Creation — An operator configures the tournament in the back office: name, start and end times, eligible products, weight multipliers, minimum qualifying stake, prize pool structure, and registration rules. The tournament is validated at creation time — if the prize pool references a bonus template that doesn't exist, or if the weight multipliers produce a configuration that would make a product effectively invisible, the system rejects it.

Registration — Tournaments can be open (all eligible players are automatically enrolled) or opt-in (players must register before the start time). Opt-in tournaments can have a registration fee, which is processed through the standard wallet transaction layer. Registration caps are supported — when the tournament is full, additional registration attempts are rejected.

Active — Once the start time is reached, the tournament transitions to active and the listeners begin scoring qualifying events. The leaderboard updates in real time. Players can see their position, the scores of nearby competitors, and the prize they would receive at their current rank. Mid-tournament, the operator can view engagement metrics — how many registered players are actually participating, the score distribution, and the projected prize allocation.

Settlement — When the end time is reached, the tournament transitions to a settlement state. No further events are scored. The EndTournamentCron handles scheduled settlement automatically — it runs on the PAM.Service.Cron infrastructure and checks for tournaments that have passed their end time. Settlement calculates final rankings, resolves ties according to the tournament's tiebreaker rules (earliest to reach the score, or total number of qualifying events, configurable per tournament), and locks the final leaderboard.

Prize distribution — After settlement, prizes are distributed automatically based on the tournament's prize tier configuration. This is not a manual step. The settlement process triggers the prize allocation, and each winner receives their prize through the standard platform mechanisms. The entire lifecycle from end time to prizes-in-wallet is automated and auditable.

Prize allocation

Prize pools in PAM tournaments are configurable with tier-based distribution. The operator defines the total prize pool and the allocation per rank — first place gets 40%, second gets 20%, third through fifth get 10% each, and so on. The tier structure can have as many levels as needed, and it can include both percentage-based and fixed-amount allocations.

The key design decision is that prizes are not a separate system. They flow through the same bonus engine that the rest of the platform uses. This means tournament prizes can be:

• Cash — credited directly to the player's withdrawable balance. No wagering requirements, no restrictions. The prize shows up in the player's transaction history as a tournament win.
• Bonus credits — credited as bonus funds with configurable wagering requirements, game restrictions, and expiry dates. The bonus is created from a template defined in the bonus engine, so all the standard bonus rules apply — including responsible gaming limits and jurisdiction-specific restrictions.
• Freespins — awarded on specific games or game categories. The freespin package is configured in the bonus engine and linked to the tournament prize tier. When the player opens an eligible game, the freespins are waiting.

Because prize distribution uses the existing bonus engine, there's no separate reconciliation process for tournament prizes. They appear in the same reports, follow the same audit trail, and respect the same compliance rules as every other bonus on the platform. A tournament prize that would violate a player's responsible gaming limits is handled the same way any other bonus would be — blocked, with the reason logged.

For operators, this means tournament prizes don't create operational exceptions. The finance team doesn't need a separate workflow to reconcile tournament payouts. The compliance team doesn't need to audit a separate prize distribution system. It's all the same infrastructure.

The principle

Engagement features have to work across your entire product catalog, not just one game type. A tournament system that only supports slots misses the sportsbook player. A sportsbook leaderboard that ignores casino activity misses the cross-product player. And the cross-product player is almost always the highest-value player — they play more, deposit more, and stay longer.

If your tournament system is siloed by product, you're building engagement walls between your own verticals. You're telling the player who bets on football and plays blackjack that those are two separate relationships with your brand. They're not. The player doesn't think in product verticals. They think in "things I do on this site."

The architecture follows from this. One scoring engine, multiple listeners, configurable weights, unified leaderboard. The tournament doesn't care where the engagement comes from — it measures all of it, normalizes it, and ranks it. That's the system that drives retention across a multi-product operation, not a collection of product-specific leaderboards that nobody looks at after the first week.

If your tournament system only supports slots, you're leaving engagement on the table.