Responsible-Gaming Transaction Monitoring for iGaming

iGaming operators carry two monitoring obligations that pull in different directions. AML rules ask you to watch for laundering — structuring, mule patterns, sanctioned counterparties. Responsible-gaming rules ask you to watch for harm — a player depositing faster than they should, raising their own limits to chase losses, or being farmed for bonuses. Most operators run these as separate programs with separate tooling, even though both are reading the same stream of player transactions.

Didit's Transaction Monitoring API runs both in one engine. The Responsible gaming bundle catches deposit-velocity spikes, suspicious limit changes, and bonus abuse, using dedicated gambling_* transaction categories — and it sits alongside the AML/CTF, Anomaly detection, and Fraud bundles in the same product, the same alert queue, and the same case workflow. Every transaction is scored in real time at $0.02 per transaction.

This guide explains the Responsible gaming bundle, the gambling categories that feed it, and how to wire it up.

Key takeaways

• The Responsible gaming bundle catches deposit-velocity spikes, suspicious limit changes, and bonus abuse — player-protection signals, not just laundering.
• Dedicated gambling_* categories — gambling_bet, gambling_limit_change, gambling_bonus_change — let rules apply in the right context.
• Responsible-gaming and AML run in one engine, so player-harm and laundering signals share an alert queue and a case workflow.
• Velocity windows (count, sum, distinct) express deposit-velocity and limit-change patterns without a separate stream processor.
• AWAITING_USER can pause a flagged transaction for a step-up that doubles as a player-protection touchpoint.
• $0.02 per transaction, no minimums. AML screening on a flagged party is billed separately at $0.20.

What the Responsible gaming bundle does

The bundle is a curated set of rules tuned to player-protection typologies rather than laundering ones. It reads the player's transaction stream — deposits, bets, limit changes, bonus events — and flags the patterns regulators and harm-prevention frameworks care about: a player depositing repeatedly in a short window, a player raising their deposit or loss limit immediately after a losing streak, or accounts cycling bonuses in ways that signal abuse or organized farming.

Each rule carries the same kinds of action as the rest of the engine: add to the risk score, change the status, tag the transaction, or add the party to a list. So a deposit-velocity spike can move a player into review, attach a note for the responsible-gaming team, and — if your policy chooses — pause the next deposit with AWAITING_USER so the player has to confirm before continuing.

Why it matters

Gambling regulators increasingly require operators to demonstrate active harm monitoring, not just AML compliance. License conditions in many jurisdictions expect operators to identify markers of harm — chasing losses, escalating deposits, limit changes that remove protections — and to intervene. Failing to do so is a license risk, not just a fine.

Running responsible gaming as a bolt-on to AML monitoring is wasteful, because both are reading the same transactions. A unified engine lets one integration serve both obligations: the same deposit that an AML rule scores for structuring, a responsible-gaming rule scores for velocity. The signals share a queue, the analysts share a workflow, and the audit trail covers both programs at once — at a per-transaction price instead of two vendor contracts.

Technical details

Gambling transactions are created against the unified /v3/ API with a gambling_* category so the right rules apply:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_g7a118",
    "category": "gambling_bet",
    "amount": 500,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T20:05:00Z",
    "subject": { "vendor_data": "player_4471", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "payment_method": "CARD"
  }'

A deposit-velocity spike trips the Responsible gaming bundle and returns a status the operator can act on:

{
  "transaction_id": "txn_g7a118",
  "status": "AWAITING_USER",
  "risk_score": 68,
  "triggered_rules": [
    {
      "name": "Deposit velocity — 24h count",
      "bundle": "Responsible gaming",
      "aggregation": "count",
      "window": "24h",
      "action": "CHANGE_STATUS"
    }
  ],
  "alert_id": "alrt_e9c440"
}

Gambling categories. gambling_bet, gambling_limit_change, and gambling_bonus_change let rules apply in context — a velocity rule on deposits, a pattern rule on limit changes, an abuse rule on bonus events.

Velocity and aggregation. Express deposit-velocity and limit-change patterns with count, sum, and distinct windows — "more than 6 deposits in 24 hours", "cumulative deposits over €2,000 in 7 days" — without building your own stream processor.

Webhooks. Subscribe to transaction.created and transaction.status.updated to keep your platform in sync as alerts resolve and remediation completes.

Price. $0.02 per transaction, billed per call, no minimums. AML screening on a flagged party is billed separately at $0.20.

Building player-protection rules

• Deposit velocity. A count or sum window on gambling_bet-adjacent deposit events catches a player depositing faster or more than your harm thresholds allow. Pause the next deposit with AWAITING_USER so the player confirms before continuing.
• Limit changes. A rule on gambling_limit_change catches a player raising a deposit or loss limit, especially right after a losing streak — a classic chasing-losses marker. Route it to review and notify the responsible-gaming team.
• Bonus abuse. A rule on gambling_bonus_change, combined with distinct-account counts, catches bonus cycling and organized farming.
• AML alongside. The same player's deposits run against AML/CTF and Anomaly detection at the same time, so structuring or mule signals surface in the same queue.

All of these are tuned in the Business Console, and you can extend them in the Custom bundle for operator-specific harm markers.

Use cases

• Online casinos — deposit-velocity and limit-change rules flag chasing-losses behavior and trigger a player-protection step-up.
• Sports betting — bet and deposit velocity windows catch escalating stakes within a session.
• Bonus-driven acquisition — gambling_bonus_change rules with distinct-account counts catch bonus farming.
• Age-gated platforms — AWAITING_USER step-ups double as a re-verification touchpoint where harm or fraud signals appear.
• Multi-jurisdiction operators — tune harm thresholds per market in the Console while keeping one monitoring program.

How to integrate with Didit

1. Switch on the bundle. In the Business Console, enable Responsible gaming alongside AML/CTF and Anomaly detection, and tune the deposit-velocity, limit-change, and bonus thresholds to your jurisdictions.
2. Send gambling events. POST /v3/transactions/ with the right gambling_* category as players deposit, bet, change limits, or receive bonuses — with a stable transaction_id and vendor_data linking each to the player.
3. Act on the status. Approve, review, decline, or pause with AWAITING_USER to insert a player-protection or re-verification step.
4. Sync with webhooks. Listen for transaction.status.updated to react when an alert resolves or a step-up completes.

Because it's all on the unified /v3/ API, a player onboarded with KYC flows straight into the same engine that runs both their responsible-gaming and AML monitoring — one identity-and-fraud platform, end to end.

Frequently asked questions

What does the Responsible gaming bundle catch?

Deposit-velocity spikes, suspicious limit changes, and bonus abuse — player-protection markers — using the gambling_bet, gambling_limit_change, and gambling_bonus_change categories.

Can I run responsible gaming and AML in the same engine?

Yes. Both run in one engine against the same transaction stream, sharing an alert queue and case workflow, so you serve both obligations from one integration.

How do I flag chasing-losses behavior?

Use a rule on gambling_limit_change to catch limit increases (especially after losses) and deposit-velocity windows to catch escalating deposits. Route them to review or pause with AWAITING_USER.

Can I pause a player rather than block them?

Yes. The AWAITING_USER status pauses a flagged transaction for a step-up — a confirmation, a re-verification — that resumes automatically once the player clears it, doubling as a player-protection touchpoint.

What does it cost?

$0.02 per transaction, billed per call with no minimums. AML screening on a flagged party is billed separately at $0.20.

Ready to get started?

Read the Transaction Monitoring overview in the docs, see how it fits the rest of the platform on the Transaction Monitoring product page, and check transparent per-call pricing on the pricing page. When you're ready, start free — 500 free KYC checks every month, and transaction monitoring at $0.02 per call.