Fraud & Abuse — Initial Implementation (minFraud Insights)

[JoseSzycho]

Fraud & Abuse — Initial Implementation (minFraud Insights)

Context

We want to introduce a bare-minimum fraud & abuse layer using MaxMind minFraud Insights to protect high-risk flows.
This is an initial, collaborative proposal and intentionally open for iteration.

Reference:
https://www.maxmind.com/en/solutions/fraud-prevention/overview

---

Goal (Phase 1)

• Add an external fraud signal
• Cover high-risk endpoints only
• Keep logic simple and centralized
• Follow a workflow-based approach
• Start with visibility first, not blocking

---

Endpoints / Triggers (Initial Proposal)

We only call minFraud on decision points.

1. User Signup

Trigger: New account creation
Why: High fraud ROI

2. Login from New IP / Device

Trigger: IP not previously seen for the user
Why: Account takeover detection

3. Sensitive Actions (Optional / Phase 1.5)

Examples:

• Email change
• Organization creation
• Project creation
• Domain addition
• Proxy creation

---

Workflow-Based Model

Fraud handling should follow a workflow pattern:

Trigger → Signal evaluation → Threshold check → Action

---

Rollout Idea

• Auth operations + Slack notifications
• Observe and tune thresholds

---

Open Questions / Collaboration

• Which signals should trigger workflows?
• What thresholds make sense initially?
• What Slack channel / alert format should we use?
• Which additional actions should be supported next?

👉 Please comment with ideas, concerns, or alternative workflows.

Related to:

• Fraud and abuse - Initial implementation enhancements#505

[jacobsmith928]

@JoseSzycho here are some quick notes. Overall your direction is solid, so this is just for your thinking process:

• i think the biggest signal (to trigger a workflow) would be a change in the maxmind fraud score.
• I've found that the we need three levels when there are issues: LOW (log only), MEDIUM (flag + review), HIGH (block + notify)
• Slack is a good place to trigger a notification, but we probably need to open a support ticket for restricted users.
• Beyond Slack and Helpdesk, maybe look at how we integrate with our observability stack (unusual score distributions, etc)
• Starting with Maxmind (which is good at IP's and geolocation) is good for abuse signals. I would look at Stripe Radar as something similar but focused on fraud. This could be grouped with our billing and payments work.
• I think the signal you are missing overall is utilization (for instance network traffic, number of tunnels, etc).

Other considerations

• Question: what does Zitadel offer out of the box related to abuse and fraud?
• I imagine that fraud checks are async and don't block user operations initially (unless the workflow demands it)
• I imagine you're looking to store / cache fraud scores per IP/user for some TTL to avoid hammering MaxMind on every request.
• MaxMind charges per query so we should monitor costs carefully
• When blocking users, we need to provide clear paths for appeal/verification. Maybe inspired by our waitlist UX?
• We might ask @zachsmith1 to guide us in terms of building tests for this (use known-bad IPs for validation, create test scenarios for each workflow path, load test the fraud checking pipeline)

Compliance & Privacy / Data Retention

• Define how long fraud signals are stored
• Ensure compliance with GDPR, CCPA for IP/device data
• Document what data is sent to MaxMind