Real-time circuit breaker for partner payouts in affiliate and CPA networks.
This page is for Heads of Payments, Risk / Operations Leads, and Affiliate Managers at CPA and affiliate networks who manage automated partner payouts.
If your team is responsible for approving and disbursing partner commissions — and anomalies are typically caught after money has left — this is relevant.
For product fundamentals (what Froddy is, how rules work, how enforcement operates), see Docs. This page covers how Froddy applies specifically to CPA networks.
| Risk class | What happens | Blast radius |
|---|---|---|
| Entity overlap (shared device) | One person creates 10+ partner accounts from the same device and collects payouts from all of them | Proportional to fake account count × average payout; often undetected for weeks |
| Velocity abuse | A partner generates hundreds of micro-conversions in a short window, triggering rapid sequential payouts | Cumulative loss grows until someone manually spots the pattern |
| Ceiling breach | A new or low-volume partner suddenly accumulates $100K+ in daily payouts — far outside their historical profile | Full daily exposure at risk; often discovered in next-day reconciliation |
| Duplicate payout bug | A system error causes the same conversion to trigger multiple payouts to the same partner | Exponential — loss grows every second the bug runs without a limit |
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.
Conversion validated Froddy evaluates Payout executes
[Your Payout Engine] ──→ [ Froddy ] ──→ [Bank / PSP API]
evaluates in ms
allow / hold / block
Froddy sits between your payout engine (after conversion is validated and payout is approved) and the actual bank or PSP call. One API call before each payout. In observe-only mode, your payout flow continues uninterrupted — Froddy logs without blocking.
Anomalous single payout. A partner who normally earns $500–$2,000 per payout submits one for $35,000. → Caught by: R-COHORT (single transaction anomaly)
Daily exposure spike. A mid-tier partner's cumulative daily payouts reach $60,000 — well above their usual $10,000/day pattern. → Caught by: R-CEIL (daily ceiling)
Payout velocity flood. A partner generates 45 payout requests in one hour. Their normal rate is 3–5 per day. → Caught by: R-VEL (velocity spike)
Shared-source entity cluster. Five distinct "partner" accounts submit payouts from the same source hash within 24 hours — a pattern indicating duplicate-generating infrastructure or misconfiguration. → Caught by: R-DEDUP (source hash deduplication)
New partner, immediate high volume. A partner registered last week is already accumulating $80,000/day in payouts — no historical baseline to justify this. → Caught by: R-CEIL (daily ceiling)
Micro-conversion burst. Hundreds of $5–$15 payouts from one partner in rapid succession, individually unremarkable but anomalous in aggregate. → Caught by: R-VEL (velocity spike)
These are starting points — observe-only mode exists to validate them against your actual traffic.
| Rule | Parameter | Suggested start | Why |
|---|---|---|---|
| R-COHORT | hold_usd |
$15,000 | Above typical single partner payout for mid-size networks |
| R-COHORT | block_usd |
$75,000 | Well beyond any normal single payout event |
| R-CEIL | daily_ceiling_usd |
$40,000 | Above typical daily earnings for a top-performing partner |
| R-VEL | max_count / window |
20 txns / 1h | 2–3× the normal transaction rate for active partners |
| R-DEDUP | max_entities |
3 | Source hash clustering is common in CPA duplicate scenarios; tight default is appropriate |
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.
Scenario A → ALLOW
Partner_127 submits a $2,400 payout. Their daily total is $8,500, well below the ceiling. Transaction rate is normal. No source hash clustering.
Result: all rules pass → allow. Payout proceeds normally.
Scenario B → HOLD
Partner_42 submits a $6,000 payout, bringing their daily total to $44,000. The daily ceiling is $40,000.
Result: R-CEIL triggers → hold-for-review. In observe-only mode this is logged and an alert is sent. With active enforcement (available by arrangement), the payout would be queued for review.
Scenario C → BLOCK
Source hash dev_x9f3 is associated with payouts from 7 different partner accounts within 24 hours. The block threshold is 6 entities.
Result: R-DEDUP triggers → block. In observe-only mode this is logged. With active enforcement (available by arrangement), the payout would be rejected.
An evaluation is particularly timely when:
Integration details: API Reference
entity_id (partner ID), amount, event_id per transaction; device_hash strongly recommended for CPAFroddy is a circuit breaker for payout execution risk, not a replacement for your anti-fraud or traffic quality platform. 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? Request an evaluation or try the demo.