A single IP lookup can answer a triage question. It cannot explain whether 8,000 addresses in an authentication log belong to one campaign, which evidence is current, or where enforcement should happen. At scale, the work is a pipeline: collect, normalize, enrich, correlate, decide, and learn from the outcome.

This workflow is designed for security, fraud, abuse, and platform teams that need repeatable results rather than a pile of scores.

1. Define the decision before collecting data

Start with the operational question. Examples include:

  • Which login sources should receive step-up verification?
  • Which addresses in a WAF export show recent, confirmed attack behavior?
  • Is abuse isolated to a few IPs or clustered across a prefix or ASN?
  • Which sources should be added to a temporary watchlist?

The decision determines the evidence you need. A permanent firewall block should require stronger support than a temporary rate limit. A customer-facing login flow needs an exception path; an analyst enrichment job may not.

2. Preserve event context

Keep more than the source IP. Useful context includes event time, account or tenant, route, response status, user-agent, session identifier, authentication outcome, and the control that already fired.

Normalize IPv4 and IPv6 consistently. Remove malformed and private addresses, but do not discard timestamps or tenant boundaries. Deduplicate only when it will not erase meaningful repetition. Ten attempts from one source are operationally different from one attempt.

3. Triage a representative sample

Before running a full batch, inspect examples with FraudGuard IP Lookup. Review:

  • what behavior was observed;
  • how recently it occurred;
  • whether the evidence repeated across time or sensors;
  • the infrastructure, prefix, ASN, ISP, and geography;
  • the confidence factors and recommended action.

This step validates that the data can answer your question and helps you choose which fields to retain downstream. For a deeper checklist, see How to Check if an IP Address Is Malicious.

4. Enrich in the right mode

Use ACE v2 Bulk IP Intelligence for bounded batches and scheduled jobs. Use the Offline Threat Database when volume, local latency, privacy, or network isolation makes a local join more appropriate.

Store the evidence date with the result. Reputation is time-sensitive. A verdict without recency is difficult to defend and easy to misuse months later.

5. Correlate beyond the individual address

Attackers rotate infrastructure. Group results by dimensions that can reveal a shared campaign:

  • account or session;
  • time window and request cadence;
  • route or targeted service;
  • attack family or reason code;
  • IP prefix and ASN;
  • infrastructure provider and connection type;
  • repeated payload or client fingerprint.

Use Advanced Threat Lookup to test whether a source belongs to a broader pattern in FraudGuard data. A cluster strengthens an investigation, but network ownership alone is not enough to justify blocking every address in an ASN.

6. Translate evidence into tiered action

Avoid a single “bad IP” rule. A production policy usually needs several outcomes:

Evidence Proportionate action
No current malicious evidence and normal request context Allow and log
Ambiguous infrastructure or weak/stale evidence Monitor, rate-limit, or challenge
Recent repeated attack observations with high confidence Block temporarily and alert
Reviewed customer or partner exception Allowlist with owner and expiry

The exact boundaries depend on the cost of fraud and the cost of interrupting a legitimate user. Keep the reason and policy version beside every automated decision.

7. Close the feedback loop

Measure outcomes after enforcement:

  • confirmed fraud or abuse prevented;
  • challenge completion rate;
  • support contacts and disputes;
  • allowlist additions;
  • decision reversals;
  • latency and API error behavior.

False positives are not just a model problem; they often reveal missing business context. Feed reviewed exceptions into customer-specific lists and give blocked users a safe dispute path. FraudGuard’s IP Dispute Manager is built for that workflow.

Common mistakes

  • Blocking an ASN because of one address. Shared networks contain unrelated customers.
  • Treating VPN or country as proof. Those are contextual attributes, not observed behavior.
  • Ignoring age. An old finding and an attack from five minutes ago should not carry the same weight.
  • Dropping the explanation. A score without evidence makes support, tuning, and audit work harder.
  • Failing closed on an enrichment outage. Decide explicitly how each request path behaves when intelligence is unavailable.

At scale, IP investigation is less about finding one bad address and more about building a defensible decision system. Start with a sample, retain the evidence, correlate carefully, and expand automation only after the outcomes match your risk policy.