Graph Neural Networks for Multi-Account Bonus Abuse Detection

Bonus abuse detection becomes harder when fraudulent behavior stops looking like a collection of individual accounts. A single customer can be easy to assess, yet a coordinated group may distribute deposits, devices, identities, and promotional activity across dozens of profiles. Graph neural networks provide a useful way to model those relationships because the risk signal often sits between accounts rather than inside one account.

For operators evaluating new casinos, promotional campaigns create another engineering headache. Acquisition bonuses can attract legitimate customers while also creating incentives for organized account farming. The solution is not to reject everyone sharing a household router. Instead, a graph-based system can combine multiple weak signals, calculate relationship strength, and escalate only the patterns that deserve scrutiny.

This whitepaper examines a practical architecture for bonus abuse detection using entity-relationship graphs, community detection, and graph neural networks. The emphasis is operational. Build the graph correctly, preserve context, score accounts quickly, and keep automated decisions explainable enough for security and compliance teams to defend.

Why Bonus Abuse Detection Belongs in a Graph

Traditional fraud models usually represent an account as one row in a feature table. That works well for attributes such as deposit velocity, wagering behavior, chargebacks, or promotional conversion. However, it struggles when the evidence is relational.

Consider five accounts that use different names but share the same device fingerprint, deposit instrument, residential network, and withdrawal destination. None of those attributes necessarily proves abuse individually. Together, they create a much stronger pattern.

A graph represents that pattern naturally. Accounts become nodes, shared entities become additional nodes, and observed relationships become edges. The resulting structure captures connections that ordinary tabular models can miss.

The First Graph: Accounts and Shared Entities

A practical graph might contain several node types:

Customer accounts.
Devices and browser fingerprints.
IP addresses and network identifiers.
Payment instruments and deposit sources.
Withdrawal destinations.
Email, phone, or identity attributes.
Promotional campaigns and redemption events.

Edges should also carry context. A device shared for two minutes is different from a device associated with ten accounts over six months. Likewise, two accounts using the same public IP during a major event could represent an apartment block rather than coordinated activity.

That is why edge attributes matter. Store frequency, recency, duration, confidence, and observation timestamps wherever possible. Graph models become substantially more informative when relationships have memory.

Building a Relationship Graph Without Creating False Positives

The graph should begin with normalized entities, not raw strings. Payment identifiers may arrive in different formats, while device signals can change slightly across browser versions. Identity resolution therefore needs deterministic and probabilistic matching rules before graph construction.

Normalize account and transaction identifiers across every source system.
Create canonical entity records for devices, networks, deposits, withdrawals, and identity attributes.
Attach timestamps to every observed relationship.
Assign confidence scores to uncertain matches.
Expire or down-weight stale relationships when operationally appropriate.
Maintain provenance so investigators can trace why an edge exists.

Suppose two siblings legitimately use the same laptop but maintain independent accounts. A simplistic rule might block both. A relationship graph can instead observe that their payment instruments, identity records, wagering patterns, and promotional histories remain distinct.

That distinction is essential. The purpose of bonus abuse detection is not to find shared attributes. It is to identify coordinated promotional behavior supported by multiple independent signals.

A shared IP is evidence of proximity. It is not evidence of collusion.

Weighting the Edges

One useful approach is to assign an edge weight representing the strength of a relationship. For example, a shared withdrawal destination might carry more weight than a shared IP address, depending on the operator’s evidence quality and applicable privacy rules.

A simplified score could look like:

EdgeScore = w₁×recency + w₂×frequency + w₃×uniqueness + w₄×confidence

The weights should come from validated historical data rather than intuition alone. Moreover, the model should preserve the underlying components so analysts can explain why a relationship received a high score.

Community Detection Finds the Group Behind the Accounts

Once the graph exists, the next challenge is finding clusters. Community detection algorithms can identify dense regions where accounts and entities have more connections than expected under the surrounding graph structure.

Algorithms such as Louvain or Leiden are practical choices for large graphs because they optimize community structure without requiring investigators to define every possible group in advance. However, a dense community is not automatically fraudulent. It is a candidate structure requiring contextual scoring.

Imagine a cluster containing 180 accounts. Forty share several devices. Seventy connect to a small set of deposit instruments. Twenty repeatedly redeem the same promotion within minutes of account creation. The cluster’s structure is now much more informative than any single suspicious account.

Community-level features can include cluster size, shared-entity density, promotional concentration, account creation bursts, transaction synchronization, and the proportion of members previously associated with restrictions.

Why Graph Neural Networks Add Another Layer

Community detection is generally unsupervised or lightly supervised. Graph neural networks can then learn how neighboring nodes and their attributes combine into a fraud-risk representation.

A graph convolutional network, GraphSAGE model, graph attention network, or similar architecture can aggregate information from connected entities. The model might learn that an account with an ordinary deposit pattern becomes significantly riskier when surrounded by nodes exhibiting synchronized promotional activity.

Graph attention mechanisms can also help assign different importance to neighboring information. A payment relationship may deserve more influence than an incidental IP overlap, while a recent device relationship could matter more than an old one.

The output might be a probability-like risk score rather than an automatic verdict. That distinction matters operationally. NIST’s AI Risk Management Framework recommends managing AI throughout its lifecycle, with attention to validity, reliability, transparency, explainability, security, and ongoing evaluation. ([nist.gov](https://www.nist.gov/itl/ai-risk-management-framework?utm_source=chatgpt.com))

Real-Time Bonus Abuse Detection at Redemption

Batch analysis is useful for discovering historical networks, but promotional abuse often happens quickly. A customer registers, deposits, claims a bonus, clears minimal wagering requirements, and attempts to withdraw before a conventional overnight review completes.

Real-time graph scoring changes the timing. At registration or redemption, the system can query the applicant’s immediate neighborhood and calculate the risk created by the new node.

Create the new account node and attach known relationships.
Retrieve nearby entities within a defined graph radius.
Calculate graph-derived features such as shared-device count and cluster density.
Run those features through the trained GNN or a hybrid risk model.
Combine the model score with deterministic policy rules.
Assign an operational action such as approve, review, delay, or restrict promotional eligibility.

Latency matters here. A graph query taking several seconds may be acceptable for investigation but frustrating at registration. Therefore, production systems often precompute embeddings or maintain materialized neighborhoods for frequently queried entities.

A Practical Redemption Scenario

Imagine Account A registering at 10:02 and redeeming a welcome offer. The graph shows no concerning relationships, so the promotional action proceeds normally.

At 10:07, Account B arrives with a new identity but the same device fingerprint and deposit instrument. The system finds a direct connection to Account A plus an older restricted account in the same neighborhood. An additional cluster contains several recent promotional redemptions with nearly identical transaction timing.

A rules-only engine might flag the device and stop there. A graph model can evaluate the complete neighborhood and determine whether the combination materially changes risk. That is the advantage of relational reasoning.

Training the Model: RTP Is Not the Objective Here

Casino mathematics still matters, but fraud models optimize a different objective. The security team is balancing prevented promotional losses against false positives, investigation cost, customer friction, and regulatory obligations.

Useful evaluation metrics therefore include precision, recall, precision-recall AUC, false-positive rate, detection latency, and expected financial impact. Cost-sensitive training can give more weight to severe abuse clusters than minor anomalies.

Class imbalance deserves special attention. Confirmed bonus abuse may represent a tiny fraction of total accounts. A model can therefore achieve impressive accuracy simply by predicting “legitimate” almost everywhere. That is mathematically useless.

Temporal validation is also essential. Train on historical periods and test on later periods rather than randomly shuffling every account. Otherwise, near-duplicate relationships can leak across the training and test sets, creating inflated results.

The Dark Side of Clever Graphs: Governance

A graph containing identities, devices, payment relationships, and network information is sensitive infrastructure. Security teams should minimize unnecessary data collection, enforce access controls, document retention periods, and ensure decisions are appropriate for the jurisdictions in which the operator works.

The regulatory direction is clear enough to take seriously. The UK Gambling Commission’s 2026 risk guidance includes real cases involving multiple accounts, false or stolen identities, and circumvention of identity-verification controls. ([gamblingcommission.gov.uk](https://www.gamblingcommission.gov.uk/guidance/the-2026-money-laundering-and-terrorist-financing-risks-within-the-british-gambling-industry/2026-money-laundering-and-risks-casino-remote?utm_source=chatgpt.com))

Its guidance on bonus and promotional offers also states that operators need robust identity-verification procedures and controls against promotional exploitation. ([gamblingcommission.gov.uk](https://www.gamblingcommission.gov.uk/licensees-and-businesses/page/managing-criminal-risk-bonus-and-promotional-offers?utm_source=chatgpt.com))

Therefore, the graph should support investigators rather than become an opaque machine for automatic punishment. A risk score should have an audit trail showing the important relationships, timestamps, and model version behind the decision.

From Clever Model to Production Security System

The strongest architecture is usually hybrid. Deterministic rules catch obvious violations quickly. Community detection reveals suspicious structures. The GNN estimates contextual risk. Human investigators handle difficult cases.

Use rules for known prohibited relationships.
Use graph analytics for cluster discovery.
Use GNNs for contextual scoring.
Use real-time features for promotional redemption.
Use manual review for ambiguous or high-impact decisions.

Monitor the system continuously. Fraud networks adapt once controls become effective, so yesterday’s strongest features may weaken tomorrow. NIST’s AI RMF describes continuous risk management and regular evaluation as part of trustworthy AI deployment, rather than treating model release as the finish line. ([airc.nist.gov](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/?utm_source=chatgpt.com))

Graph drift is especially interesting. A new payment provider, device population, promotional campaign, or market expansion can change the topology without any increase in actual abuse. Engineers should therefore monitor node distributions, edge frequencies, community sizes, score calibration, and investigator-confirmed outcomes.

The best bonus abuse detection platform is not the one generating the most alerts. It is the one separating ordinary shared infrastructure from coordinated behavior while doing so quickly enough to protect promotional budgets.

Graph neural networks are valuable because they model what traditional account-level systems often miss: relationships. Shared IPs, devices, deposits, withdrawals, identities, and promotional actions become connected evidence rather than isolated columns. Community detection exposes suspicious clusters, while real-time graph scoring lets the operator respond before promotional value disappears.

None of that removes the need for judgment. A graph can reveal a pattern, but governance determines what happens next. Build the relationships carefully, validate the model against time-separated data, keep explanations available, and treat the risk score as evidence rather than a verdict. That is how graph technology becomes a practical security control instead of an expensive diagram with an AI sticker on it.