What GGR actually is and why it needs to be live

Gross Gaming Revenue is the total amount wagered minus the total winnings paid out. It is the primary revenue metric for casino and sportsbook operators – the number that tells you, right now, whether the platform is generating value. As Blask’s GGR knowledge base (2026) notes, operators who track GGR in isolation are navigating without a benchmark. We’d go further: operators who see GGR on a delay are making decisions on data that no longer reflects reality.

In Argentina, this matters more than in most markets. Argentina operates with multiple peso exchange rates – official, MEP, and blue dollar – and real transactions in the market run in both ARS and USDT. Onmidev handles balances in both. A GGR figure from two hours ago may have been calculated at a different rate than the one active right now. For real-time GGR reporting in iGaming to mean anything here, currency normalization has to happen at transaction time – not in a batch job running at midnight.

Batch vs real-time reporting in iGaming: why it matters for operators

Batch reporting tells you what happened. Real-time reporting tells you what to do next.

Batch

Schedule

Aggregate

Cache

Dashboard

Real time

Event

Propagate

Dashboard

The standard approach in iGaming back office analytics is batch reporting – aggregate transactions at set intervals, write to a reporting table, serve from cache. As Airbyte’s data engineering guide (Jim Kutz, September 2025) defines it, batch systems “collect and process large datasets at scheduled intervals,” while stream processing “handles data continuously as it arrives in real time.” Confluent, whose infrastructure underpins event-driven architectures across industries, frames the operational consequence directly: streaming enables systems to “take advantage of data in motion” rather than waiting for a snapshot.

For online casino reporting tools built around an agent network, batch creates a specific problem – and it is the reason real-time GGR reporting in iGaming requires a different approach at the data layer. Onmidev runs without open online registration – every player is registered by an agent, inside a hierarchy that goes operator → agent → subagent → player. When a transaction completes, it needs to update every relevant node in that tree immediately. In a batch system, that propagation happens on a schedule. In ours, it happens as part of the transaction itself, using a modular Node.js and PostgreSQL stack deployed on AWS and GCP.

Each completed round or settled bet writes an event. That event updates the relevant nodes in the hierarchy. The GGR figure any role sees in the iGaming KPI dashboard reflects the actual state of the network at that moment – not the last time a job ran.

How live GGR reporting changes operator decisions

When Onmidev shipped real-time GGR reporting in iGaming for our first operators, we expected them to open the dashboard at end of day. The actual pattern was different. Operators check it throughout the day – the way you check a phone. One partner said it plainly: "I stopped asking for reports. I just open the dashboard and I know what's going on."

The casino operator data visibility that matters most in practice: agent network GGR tracking, GGR by provider, deposit and withdrawal flow – all in one view. When a payment route slows down, it shows in the deposit feed next to GGR immediately. Operators switch routes without waiting for support to flag the issue. Agents see their own commission accumulation in real time and adjust accordingly. No tickets. No calls to the dev team.

Each role sees only their own slice. Operators see total network GGR, deposits, and provider performance. Agents see their own book. Subagents see only their own tier – no lateral visibility into others. This is enforced at the data layer, not just the UI.

Can operators see GGR split by casino and sportsbook separately? Yes – the dashboard filters by vertical, by provider, and by agent. This is real-time GGR reporting in iGaming applied at the most granular level operators actually need. What happens to real-time casino analytics in LatAm when a payment provider goes down? The deposit feed reflects the drop immediately, next to GGR, so the operator sees the impact without waiting for a support ticket. These are the questions we hear most often – and the answers are built into the product, not the documentation.

What the number you see actually means

There is also a version of this that does not work: showing every intermediate state. Partial round results, uncommitted transactions, and pre-settlement bonus calculations are not surfaced as confirmed GGR. iGaming reporting latency is a real tradeoff – and we chose accuracy over optimism.

How do operators know the number is final, not provisional? Because unconfirmed figures never appear in the dashboard. The number updates when the event is settled, not when it is in progress. Operators build habits around the data they see, and those habits need to rest on numbers that hold.

Why this is interesting to build

Building real-time GGR reporting in iGaming for a multi-currency, agent-based network surfaced problems that do not show up in a standard tutorial.

Concurrent writes across the agent tree. When multiple players under the same agent are active at the same time, their transactions write to the same aggregation nodes. Getting this right under concurrent load – without race conditions or double-counting – required careful use of PostgreSQL’s transaction isolation. This is not a glamorous problem. It is exactly the kind of thing that causes silent errors in production if you get it wrong.

Currency handling before storage. ARS/USDT normalization at transaction time means every write carries the current rate. This keeps GGR figures consistent with the actual financial positions of agents and operators – no retroactive adjustments, no reconciliation surprises at end of day.

Good infrastructure is boring to use. Interesting to build. The online casino reporting tools we build – including real-time GGR reporting in iGaming – are used by real operators in Argentina and LatAm every day. For an engineer, that means the feedback loop between what you ship and what actually happens is very short.