Stop Paying Ghost IBs: 12 Automated Signals That Catch Self-Referral Before Payout

IB fraud and self-referral rarely look like “one big incident.” More often, it’s dozens of small leakages: suspicious clicks that convert too well, “new” clients who share the same device, and commission payouts that don’t match real trading value.

This post lists 12 detection signals brokers and prop firms can automate across four data layers—clicks, devices, payments, and trading links—so you can flag abuse before commissions are approved. (Always check local regulations and your privacy policy before expanding tracking or data matching.)

1) Clickstream signals: catch manufactured traffic early

Affiliate fraud typically starts upstream. If you can detect manipulation at the click layer, you prevent bad accounts from ever reaching KYC, payments, or trading.

Automatable signals to implement:

• Click-to-registration time anomalies: clusters of registrations happening within seconds of a click (or unrealistically consistent timings) often indicate scripted flows.
• High click volume with low page depth: many clicks but near-zero time on site, no scroll, no second page view—classic low-intent or bot traffic.
• Repeated “unique” clicks from the same network: different user agents but the same ASN/ISP or narrow IP ranges, especially when paired with identical landing paths.

How to operationalize: set thresholds per GEO and channel (paid search vs. IB link). Your CRM should score leads before sales touches them, and automatically require stronger verification for high-risk cohorts.

2) Device & session signals: link “different” users who aren’t different

Self-referral usually breaks when you stop trusting surface-level identifiers (email, name) and start correlating device, session, and environment signals.

Automatable signals to implement:

• Device fingerprint overlap: multiple “clients” registering from the same fingerprint (or a tight cluster) within a short window.
• Cookie/local storage continuity across accounts: account A logs out, account B logs in—same browser storage identifiers or same session continuity patterns.
• Emulator/VPS indicators: datacenter IPs, headless browser flags, abnormal screen resolutions, or missing device sensors on “mobile” signups.

How to operationalize: don’t hard-block by default. Route to a “step-up” path: extra KYC, selfie liveness, proof-of-address earlier, or manual compliance review. Keep an audit trail of why the step-up was triggered.

3) Identity & KYC signals: self-referral often reuses real-world attributes

Fraudsters can rotate emails and phone numbers, but they struggle to rotate real-world identity elements at scale—especially when they want fast withdrawals.

Automatable signals to implement:

• KYC field collisions: same document number, same address, same DOB, or near-matches (typos, transliterations) across multiple accounts tied to one IB.
• Phone/email patterning: sequential emails, disposable domains, VOIP-heavy phone ranges, or repeated recovery emails.
• Jurisdiction mismatch patterns: a surge of clients “living” in one country but consistently using networks/devices from another, concentrated under one IB.

How to operationalize: implement fuzzy matching (not just exact match) and score collisions higher when the accounts are under the same IB tree. For regulated environments, confirm what you’re allowed to match/store and for how long.

4) Payment signals: follow the money, not the marketing

Self-referral becomes most expensive when deposits and withdrawals start. Payment data is also harder to fake consistently.

Automatable signals to implement:

• Shared payment instruments: same card BIN + last4 (where available), same crypto wallet reuse, same bank account identifiers, or same e-wallet account used across multiple “clients.”
• Deposit/withdrawal choreography: small deposits to trigger CPA/bonus/IB qualification, followed by fast withdrawals with minimal trading.
• Third-party funding patterns: frequent deposits from names that don’t match the client (where your PSP provides payer info), especially when clustered under one IB.

How to operationalize: tie commission eligibility to “cleared” deposits and risk status. Delay IB payouts when payment risk flags are present, and require compliance sign-off for third-party funding scenarios (subject to local rules).

5) Commission & incentive signals: abuse concentrates where rules are brittle

Fraud follows incentive design. If your IB program pays CPA quickly or pays per-lot without quality controls, you’ll attract “manufactured” activity.

Automatable signals to implement:

• CPA overperformance outliers: an IB with conversion rates that are statistically extreme for their GEO/traffic type.
• Commission spikes right before payout cycles: a surge of “qualifying” actions (first deposit, minimum lots) in the final 24–72 hours before commission approval.
• Sub-IB tree anomalies: many sub-IBs created rapidly, each producing a small number of “clients” with similar profiles and identical funnel paths.

How to operationalize: create program rules that are machine-checkable (e.g., “CPA eligible only after X trading days and Y net deposits”). Then automate holds when patterns match known abuse signatures.

6) Trading-link signals: connect IB fraud to trading behavior (MT4/MT5/cTrader)

The most reliable self-referral detection often comes from linking referral attribution to trading account telemetry. Fraudulent accounts frequently trade “just enough” to unlock a payout.

Automatable signals to implement:

• Synchronized trading across accounts: multiple accounts under one IB opening similar positions at similar times, same symbols, same lot sizes—especially across fresh accounts.
• Low-value churn trading: high number of micro-lots or short-duration trades designed to generate rebate/commission with minimal market exposure.
• Hedged or offsetting behavior across related accounts: patterns consistent with internal matching or risk-free volume generation (e.g., mirrored positions) rather than genuine trading intent.

How to operationalize: integrate platform data (via MT4/MT5 Manager API or platform connectors) into your CRM scoring. If you run a prop model, apply similar logic to challenge accounts and payout requests.

7) How to automate this in your CRM: a simple scoring + workflow blueprint

You don’t need a “perfect” fraud model on day one. You need consistent signals, a scoring rubric, and enforcement workflows that don’t overload your team.

A practical automation pattern brokers use:

• Step 1 — Normalize events: clicks → registrations → KYC → deposits → trades → withdrawals → commissions.
• Step 2 — Score signals: assign weights (e.g., device overlap = 30, shared payment instrument = 50, synchronized trading = 40).
• Step 3 — Trigger workflows:
  • Low risk: auto-approve standard flow.
  • Medium risk: step-up verification + delayed commission eligibility.
  • High risk: freeze IB payout, route to compliance, require enhanced due diligence.
• Step 4 — Close the loop: confirmed fraud outcomes feed back into rules (and into IB program policy updates).

Keep the process audit-ready: every hold, rejection, or payout delay should have a logged reason, timestamp, and reviewer notes.

The Bottom Line

IB fraud and self-referral are easiest to stop before payouts—by correlating what marketing sees (clicks) with what operations sees (devices, KYC, payments) and what dealing sees (trading behavior).

Start with 12 signals, score them consistently, and automate step-up checks and payout holds based on risk—not gut feel.

If you want to implement these checks inside your IB module, payments workflows, and platform integrations, talk to Brokeret at /get-started.