Why account protection belongs close to the request

The problem with bolt-on fraud calls

Account abuse checks often sit far from the request path. That creates three product problems:

1. Latency — every extra hop slows signup and login.
2. Data sprawl — more systems see identifiers than need to.
3. Opaque ownership — when something fails, nobody knows who owns the decision.

AbuseGraph is built so evaluation stays close to the traffic that matters, with a clean handoff to your backend for the final decision.

What “close to the request” actually means

It does not mean publishing our infrastructure diagram. It means designing for:

• Fast preliminary evaluation where the browser can contribute device and session context without shipping unnecessary personal data
• Authoritative finalization on your backend, where you already hold the email and event context
• Signed, short-lived bridges between those steps so clients cannot quietly rewrite the outcome
• Clear customer ownership of enforcement — allow, challenge, or block stays in your product

Design principles we optimize for

Principle	Why it matters
Minimize sensitive data in the browser path	Less exposure, fewer compliance surprises
Keep the critical path under your control	Your app decides what happens to the user
Prefer explainable outputs	Security and support can defend the call
Fail closed on integrity, open on availability	Tampered handoffs are rejected; temporary enrichment gaps degrade gracefully

What we keep private

We publish the customer contract — inputs, outputs, and how to enforce them. We do not publish infrastructure maps, scoring formulas, or enrichment inventories. Those details help attackers more than customers.

Bottom line

Good account protection is less about naming every subsystem and more about a trustworthy path: collect what you need, decide quickly, explain the result, and leave policy in the customer’s hands.