Real-time circuit breaker for player withdrawals, affiliate payouts, and bonus disbursements in iGaming.
This page is for Heads of Payments, Risk & Operations Managers, and Affiliate Managers at online gambling, sports betting, and casino platforms who manage automated financial outflows — player withdrawals, affiliate commissions, and bonus payouts.
If your team is responsible for approving and executing outbound payments — and anomalies in withdrawal patterns or affiliate payouts are caught after funds have left — this is relevant.
For product fundamentals (how Froddy works, how rules work, verdicts), see Docs. This page covers how Froddy applies specifically to iGaming.
Note: Regulatory requirements vary by jurisdiction. Froddy is a pre-execution control layer for execution risk, not a compliance solution — see boundaries below.
| Risk class | What happens | Blast radius |
|---|---|---|
| Bonus anomalies / entity overlap | One person creates multiple player accounts from the same device, claims sign-up bonuses on each, and withdraws | Loss per incident = bonus value × number of fake accounts; scales quickly |
| Rapid withdrawal after deposit | A player deposits and immediately requests a large withdrawal — potential money laundering pattern or payment method abuse | Exposure is the withdrawal amount; often time-sensitive |
| Affiliate payout anomaly | An affiliate's commission payouts spike far beyond their historical pattern — possible traffic manipulation or conversion anomalies upstream | Daily affiliate exposure can reach tens of thousands before manual review |
| Withdrawal velocity spike | A player submits many withdrawal requests in rapid succession — splitting a large amount across small transactions | Cumulative loss if each individual withdrawal passes checks |
Froddy does not detect the intent behind these risks. It limits blast radius by flagging anomalies in amount, velocity, and daily exposure before money moves.
iGaming platforms typically have multiple outbound payment flows. Froddy can be placed on any or all of them:
Withdrawal approved Froddy evaluates Payment executes
[Cashier / Wallet] ──→ [ Froddy ] ──→ [Payment Gateway]
evaluates in ms
allow / hold / block
Froddy sits between your cashier or wallet system (after the withdrawal or payout is approved internally) and the payment gateway execution. One API call per outbound transaction. Froddy evaluates the request, returns allow / hold / block, and your code acts on it.
Multiple flows: You can route player withdrawals, affiliate payouts, and bonus disbursements through the same Froddy tenant with different event_type values, or use separate tenants for separate monitoring.
Bonus anomaly cluster. Four player accounts route withdrawals from the same source hash within 48 hours — each claiming a $100 sign-up bonus. Classic duplicate-origin pattern. → Caught by: R-DEDUP (source hash deduplication)
Anomalous single withdrawal. A player with a typical withdrawal history of $200–$500 requests a $25,000 withdrawal. → Caught by: R-COHORT (single transaction anomaly)
Daily withdrawal ceiling. A player's cumulative withdrawals for the day reach $15,000 — well above any previous daily total. → Caught by: R-CEIL (daily ceiling)
Withdrawal splitting. A player submits 30 withdrawal requests of $200 each within one hour, bypassing per-transaction checks through volume. → Caught by: R-VEL (velocity spike)
Affiliate commission spike. An affiliate who normally earns $2,000/month suddenly has $18,000 in commission payouts queued in a single day. → Caught by: R-CEIL (daily ceiling)
Shared-source affiliate cluster. Six "affiliate" accounts route commission payouts from the same source hash, each collecting independently — a clustering pattern indicating shared origin. → Caught by: R-DEDUP (source hash deduplication)
These are starting points — tune them against your actual traffic using the check log.
| Rule | Parameter | Suggested start | Why |
|---|---|---|---|
| R-COHORT | hold_usd |
$5,000 | Above typical player withdrawal; adjust for your VIP tier |
| R-COHORT | block_usd |
$25,000 | Well beyond normal single withdrawal for most player segments |
| R-CEIL | daily_ceiling_usd |
$10,000 | Conservative daily withdrawal ceiling; use entity overrides for VIP players |
| R-VEL | max_count / window |
10 txns / 1h | Players rarely submit more than a few withdrawals per day |
| R-DEDUP | max_entities |
3 | Tight default is appropriate — source hash clustering is a primary risk in this vertical |
Product defaults for reference: R-COHORT hold $25K / block $100K, R-CEIL $50K, R-VEL 20/1h, R-DEDUP 3 entities. See /docs Rules Reference.
Note: iGaming has wide variance between casual players and VIP/high-roller segments. Expect to use entity overrides extensively for VIP players who legitimately withdraw at higher volumes.
Scenario A → ALLOW
Player_8821 requests a $350 withdrawal. Their daily total is $700. One of 2 withdrawals today. No source hash clustering.
Result: all rules pass → allow. Withdrawal proceeds normally.
Scenario B → HOLD
Player_4455 requests a $6,000 withdrawal — their largest ever. The hold threshold is $5,000.
Result: R-COHORT triggers → hold-for-review. Froddy logs the event, sends an alert, and returns the verdict. The withdrawal is queued for manual review.
Scenario C → BLOCK
Source hash dev_m7k2 is associated with withdrawal requests from 7 different player accounts within 24 hours. The block threshold is 6 entities.
Result: R-DEDUP triggers → block. Froddy logs the event and returns the verdict. The withdrawal is rejected.
Integration details: API Reference
entity_id (player ID or affiliate ID), amount, event_id per transaction; device_hash strongly recommended for iGamingAfter connecting, the check log surfaces detections and rule triggers. Use entity overrides for VIP players who legitimately withdraw at higher volumes.
Froddy is a pre-execution control layer for payout execution risk, not a replacement for your compliance, responsible gambling, or anti-fraud infrastructure. See What Froddy Does — and What It Doesn't.
| Resource | Link |
|---|---|
| Product documentation | froddy.io/docs |
| API reference | froddy.io/api |
| Interactive demo | froddy.io/demo |
Ready to evaluate? Try the demo or contact us.