FraudGuard has several APIs because a login decision, a threat-hunting query, and a 20-million-row log enrichment job should not use the same interface. This guide helps you choose the right starting point. The API documentation remains the source of truth for authentication, schemas, limits, and code examples.

The short answer

Your job	Start here	Why
Decide on one live request	ACE v2 IP Intelligence	Returns explainable allow, challenge, or block guidance
Enrich a batch of IPs	ACE v2 Bulk IP Intelligence	Applies the same decision model efficiently across a batch
Investigate a network or campaign	Advanced Threat Lookup	Filters FraudGuard intelligence by ASN, provider, country, threat, risk, and other attributes
Score logins in user context	User History Check	Combines source-IP context with recent account activity
Enrich locally or without a live dependency	Offline Threat Database	Delivers SQLite or CSV data for local decisions
Monitor IPs over time	ThreatWatch	Maintains an account-specific watchlist and activity view
Manage your own exceptions	Custom lists	Adds your allowlist, blocklist, and geographic policy to FraudGuard context

If you are building a new request-path integration, start with ACE v2. If you are investigating rather than deciding, start with Advanced Threat Lookup.

Real-time decisions: ACE v2

ACE v2 IP Intelligence is the primary endpoint for new single-IP integrations. It is designed for login, signup, checkout, API gateway, WAF, form, and account-access decisions.

The response includes an action, risk and confidence context, human-readable reasons, observed activity, infrastructure and network attribution, geography, and customer-specific policy. That structure matters because a production control needs more than a score. Engineering needs a stable action; security needs supporting evidence; support needs an explanation.

Use ACE v2 when:

• the lookup is in a live request path;
• false positives have a customer or revenue cost;
• you want to distinguish ambiguous traffic from confirmed abuse;
• the decision and its evidence need to be logged together.

Treat the returned action as a strong input to your policy, not a substitute for business context. A high-value payment, an employee login, and a public documentation request may require different responses to the same source-IP evidence.

Batch enrichment: ACE v2 Bulk

Use ACE v2 Bulk IP Intelligence when the same decision model must be applied to many addresses at once. Common inputs include authentication logs, WAF exports, incident timelines, fraud queues, and scheduled review jobs.

Bulk is usually a better fit than a loop of single lookups because it reduces network overhead and makes job-level retry, logging, and cost controls easier. Normalize and deduplicate IPs before submission, preserve the original event timestamp, and store the evidence fields you will actually use during review.

For very large or latency-sensitive workloads, use the Offline Threat Database instead of turning a local join into millions of remote calls.

Investigations: Advanced Threat Lookup and GeoThreat

Advanced Threat Lookup answers questions about patterns, not only one address. Analysts can pivot across ASN, ASN organization, ISP, organization, country, connection type, threat classification, and risk. It is useful for investigating abuse clusters, validating a proposed network rule, or measuring whether a suspicious source belongs to a broader pattern.

GeoThreat adds geographic-neighborhood context around a query IP. Proximity is not proof of coordination, so use it to generate investigative leads alongside ASN, provider, timing, and observed behavior.

Account-aware controls: history, lists, and rate limits

IP evidence becomes more useful when it is combined with what your application already knows.

• User History Check supports account-level anomaly workflows such as an unfamiliar source or a sudden location change.
• Custom allowlists and blocklists encode customer-specific exceptions and known bad sources.
• Geographic controls add an explicit business policy without pretending that a country label proves malicious intent.
• Rate limiting reduces repeated abuse without forcing every suspicious request into a permanent block.

These controls should form a hierarchy. Explicit, reviewed exceptions come first; current behavioral evidence comes next; broader contextual signals influence challenge or monitoring; blanket blocking is the last resort.

Local data: Offline Threat Database

The Offline Threat Database is designed for high-volume enrichment, restricted networks, local firewalls, SIEM pipelines, and environments where a live API dependency is undesirable. SQLite supports indexed local queries. CSV supports warehouses, distributed jobs, and custom ingestion pipelines.

Plan for update cadence, atomic file replacement, rollback, and a clear stale-data policy. A local dataset is fast, but the application should know the age of the evidence it is using.

Monitoring and raw evidence

ThreatWatch is the right fit when a known address or small watchlist needs to be followed over time. Attack Stream is for teams that need raw FraudGuard-observed events and can operate their own downstream intelligence workflow.

Those products serve different maturity levels. ThreatWatch provides a focused workflow. Raw telemetry provides flexibility, but it also creates responsibility for storage, correlation, retention, and analyst review.

A safe implementation pattern

1. Start in log-only mode and capture the FraudGuard action plus evidence.
2. Compare decisions with known fraud, abuse, and legitimate traffic.
3. Enable block only for strong evidence and reviewed policies.
4. Route ambiguous traffic to a reversible control such as step-up verification or rate limiting.
5. Maintain an allowlist and a dispute path for legitimate exceptions.
6. Revisit thresholds as your traffic mix changes.

That staged rollout is more useful than copying a universal score threshold. Your application supplies the cost of a false positive; FraudGuard supplies the source-IP evidence.

Review current plans and product availability, then use the API documentation for the exact request and response contract.