ClubGG Cheating and Detection: Architecture, Signals, Outside-Channel Collusion

What counts as cheating on ClubGG

Categorisation matters because each category has its own signal stack, its own consequence path, and a different distribution of who actually does the catching. The platform's terms of service and the practical enforcement environment recognise the following categories:

Outside-channel collusion is at the top because it threatens the club model's own legitimacy — clubs whose regulars are quietly colluding will lose their soft players within months and stop generating settlement volume. The platform and the club operator are aligned on detecting this category, which is unusual; most cheat categories pit some part of the platform against some part of the club economy.

The hybrid detection model

Detection on ClubGG sits on two stacks. The first is the network layer that NSUS runs, and the second is the per-club layer that agents and club owners run. Both have to be modelled if you want to predict where a given behaviour will be caught.

Network layer: behavioural fingerprinting

Client telemetry on input timing, mouse-path geometry, touch-dwell on mobile, action-confirmation latency, idle behaviour. This is the cheapest layer to compute, runs continuously, and contributes to a per-session behavioural score. The signal family is the one GGPoker has been refining for years; the ClubGG instance is, as best as can be inferred from outside, the same family with a population baseline tuned for the ClubGG player demographic.

Network layer: statistical play-pattern analysis

Per-account distributional analysis on VPIP, PFR, 3-bet by position, fold-to-cbet by board texture, bet-sizing histograms, river aggression, all-in equity at showdown. Heavy compute, runs offline on nightly or weekly cadence, produces a play-pattern outlier score. Pure-GTO output is paradoxically easier to flag here than a noisy strong human, because population variability is the comparison baseline.

Network layer: account-graph models

Accounts joined by device fingerprint, IP, deposit method (where one is associated with the account), KYC document where collected, table co-occurrence patterns, and action-timing correlations within hands. Multi-accounting and farming fall out of this layer; collusion within a single club is harder because the natural prior is high co-occurrence inside a club.

Club layer: agent and owner judgement

Club owners see balance sheets, transfer histories, and full table logs for their own club. They have the operational tools to restrict seats, expel players, freeze balances, and refuse settlement. This is the layer that catches single bots and unusual behaviour at small and mid stakes — the club owner notices a regular winning above their skill envelope long before the network-layer pipeline produces a verdict.

Club layer: settlement choke point

The final consequence layer. A player who has been flagged but not removed at the platform level can still be locked out at settlement by the club. The settlement layer is private to the club and is not visible to the platform; from the outside, an account that simply stops generating volume looks the same as an account that has been quietly cut off.

The two layers cover different failure modes and neither is sufficient alone. The network layer is broad and catches large-scale farming and statistical outliers; the club layer is narrow but high-context and catches single-instance bot play and obvious collusion inside its own walls.

The agent and club-owner layer

The agent layer is the structural feature that distinguishes club apps from public real-money operators, and it is the single most important thing to understand if you are modelling detection on ClubGG. An agent is the operational manager of a player segment — they handle deposits and cashouts, vouch for new players, and have the platform-side tools to set seat restrictions and view transfer histories for the players under them. The club owner is the agent of agents, with the same toolset over the whole club.

From a detection perspective the agent layer behaves like a low-volume, high-context classifier. A single agent watches a small set of players over hours of session time, with knowledge of who they vouched for, who deposited what, who runs hot and who plays tight, and who has been a stable contributor to the club's economy. That knowledge is not captured anywhere in the platform's signal stack — it is in the agent's head — but it produces classification decisions that the platform's model often cannot replicate. A bot that passes the NSUS behavioural-fingerprinting layer but is winning above its seat's expected rate will get noticed by the agent within days.

The standard countermove from bot operators is to run their own club. This solves the agent-layer problem at the cost of creating a much larger one: the club becomes a known farm in the broader ecosystem, settlement-side partners refuse to take its action, and the platform-side scrutiny escalates. The economically successful pattern is small-volume embedded play inside legitimate clubs run by inattentive owners, not full-control farming.

Signal weights and observable failure modes

The exact weightings inside the NSUS detection model are confidential, but the relative ordering can be inferred from which behaviours get caught first and which behaviours survive for months before triggering an enforcement action. The pattern is consistent enough to support both building detection systems and shaping bot behaviour around them.

The pattern is consistent. Cheap-to-compute network signals catch the most casual implementations; expensive offline analysis catches the more sophisticated single bots; and the club-side human review catches everything else over a longer timescale. The typical lag between a bot first joining and being identified runs from two weeks at the fast end to six months at the slow end, with the most common interval around eight to fourteen weeks.

Detecting outside-channel collusion

Outside-channel collusion is the cheating category that matters most economically and is the hardest to detect mechanically. The colluders share hole cards on a private chat — WhatsApp, WeChat, Telegram, Discord, KakaoTalk — and coordinate aggression against a target. The platform sees only the visible actions, which look like routine play taken in isolation.

Defence is purely statistical. The signal lives in joint behaviour: two players folding when they hold dominated hands against each other more often than chance, two players raising in tandem against a third more often than position would predict, two players never bluffing each other on rivers across thousands of hands. Building a useful detector means estimating a baseline of expected joint behaviour, then flagging pairs whose observed joint behaviour deviates above a threshold.

The hard part on club apps is the baseline. Standard collusion detection on public operators assumes near-random opponent matching, so any two players seeing each other for thousands of hands is itself a signal. Club tables violate that assumption — regulars see each other every session. The right baseline is per-club, not per-network, and constructing population priors at the per-club level is genuinely fiddly because most clubs are small.

# Schematic: showdown-correlation detector for club tables
# Conceptual, not production code

from collections import defaultdict
import math

def collusion_pair_score(hands, club_baseline):
    """
    hands: iterable of hand records with players, hole cards, board, action sequence
    club_baseline: per-club expected joint-action frequencies
    Returns a dict[(p1, p2)] -> z-score of observed deviation
    """
    pair_obs = defaultdict(lambda: {'soft': 0, 'coord': 0, 'count': 0})

    for h in hands:
        for p1, p2 in pairs(h.players):
            pair_obs[(p1, p2)]['count'] += 1

            # Soft-play: showdown where p1 held dominated hand vs p2 and checked/called rather than valuebet
            if held_dominated(h, p1, p2) and not valuebet(h, p1, against=p2):
                pair_obs[(p1, p2)]['soft'] += 1

            # Coordination: p1 and p2 both raised vs a third party in the same hand
            if joint_aggression_vs_third(h, p1, p2):
                pair_obs[(p1, p2)]['coord'] += 1

    scores = {}
    for (p1, p2), obs in pair_obs.items():
        if obs['count'] < 200:           # too thin to score
            continue
        soft_rate = obs['soft'] / obs['count']
        coord_rate = obs['coord'] / obs['count']
        expected_soft = club_baseline['soft']
        expected_coord = club_baseline['coord']
        # Normal approximation z-score on combined signal
        z = z_combined(soft_rate, expected_soft, coord_rate, expected_coord, obs['count'])
        scores[(p1, p2)] = z

    return scores

The example is schematic. Production systems condition the baseline on stake level, the action sequence, the position relationship between the two players, and a per-pair history length. The point is that the right reference is the per-club joint-behaviour distribution, not a network-wide one — and that getting the false-positive budget right is the operational discipline that matters more than the model architecture.

Cross-NSUS signal sharing

The question of whether a flag on ClubGG produces an enforcement action on GGPoker, or vice versa, is the most consequential open question in the ecosystem and the one I get asked about most often in the chat. The platform does not publicly document its cross-product signal architecture, so the honest answer is structural inference plus the small set of cases where someone has actually observed cross-product enforcement and written about it publicly.

The structural argument is that NSUS Group runs a single security organisation and shares enough infrastructure that any signal collected on either product is at minimum visible to the same team. The plausible internal architecture is a shared abuse-graph that ingests device fingerprints, payment methods, KYC documents, and behavioural fingerprints from both products and flags accounts at the network level. The reasonable operational assumption from a bot-operator perspective is that any signal you generate on either product is observable to the other; the reasonable assumption from a defender perspective is that signal sharing is at least possible at the human-review layer and probably automated at some layers.

This is not specific to ClubGG. It is a property of multi-product operator groups, and the same logic applied to PartyPoker and bwin, or to PokerStars and FullTilt before FullTilt was retired. The public posture is "separate products"; the practical reality is that the security teams talk.

Anti-detection as adversarial classification

The standard mistake among bot builders is to treat detection as a checklist of features — add latency noise, vary touch coordinates, randomise schedule. The right frame is adversarial classification: the operator builds a model that distinguishes bot behaviour from population behaviour, and the bot's job is to produce a behaviour distribution the classifier cannot separate from the human population distribution while preserving expected value.

The formal literature on this dates to Dalvi, Domingos, Mausam, Sanghai and Verma (2004) on adversarial classification and Lowd and Meek (2005) on probing the boundary of a deployed classifier. The structure is identical: an attacker chooses an action that maximises expected utility under a classifier whose decision boundary the attacker can probe but not fully observe. The modern adversarial-ML literature (Goodfellow et al. 2014 onward) extends the formal apparatus with neural-network classifiers, gradient-based attacks, and the certified-robustness lineage.

Three operational consequences follow:

The decision boundary is non-stationary

Operators retrain. Behaviour that survives in 2024 is detectable in 2026, and behaviour that works on the GGPoker side may or may not transfer to the ClubGG population baseline.

Population baseline is the right reference

The classifier is comparing your bot to the empirical population distribution, not to an abstract "human" prior. If the NL50 6-max population on ClubGG has a specific bet-sizing histogram with a heavy small-overbet tail, your bot needs that shape, not a generic poker-pro shape.

EV-detection tradeoff is the right optimisation target

Pure-GTO output maximises EV against fixed opponents but minimises distance from the operator's "bot signature" cluster. Behaviourally shaped output gives up some EV in exchange for a lower detection score. The right optimum is not zero detection — it is the EV-maximising point under a budgeted detection probability over the account's expected lifetime.

This perspective explains the apparent contradiction that pure-GTO bots tend to get banned faster than less-optimal bots with overlaid human-shape noise. The pure-GTO bot wins more per hand on average, which compresses the time-to-detection, while the noisier bot wins less per hand but lasts longer; total EV before ban often favours the noisier strategy.

References and related work

Selected sources on the topics above. URLs are stable through arXiv and Science.

• Brown and Sandholm, 2019. Superhuman AI for multiplayer poker. Science 365 (Pluribus). Reference result for 6-max NLH at superhuman level.
• Moravčík et al., 2017. DeepStack: Expert-level artificial intelligence in heads-up no-limit poker. Science 356. arXiv:1701.01724.
• Brown and Sandholm, 2017. Safe and nested subgame solving for imperfect-information games. NeurIPS (Libratus core technique).
• Dalvi, Domingos, Mausam, Sanghai and Verma, 2004. Adversarial Classification. KDD. Foundational paper on the adversarial-classifier framing.
• Lowd and Meek, 2005. Adversarial Learning. KDD. Probing the decision boundary of a deployed classifier.
• Heinrich and Silver, 2016. Deep Reinforcement Learning from Self-Play in Imperfect-Information Games. NIPS DRL workshop. arXiv:1603.01121.

The companion notes cover the rest of the picture: the taxonomy of claimed ClubGG hacks and the home page's overview of the club ecosystem. The FAQ covers the implementation questions that recur in the chat.