Every automated security control eventually meets a legitimate exception. A customer changes networks, a partner deploys from a new provider, or a shared IP inherits reputation from another user. Without a defined process, support tickets become ad hoc firewall changes with little evidence or accountability.

FraudGuard IP Dispute Manager gives customers a protected submission page, captures the IP evidence at that moment, and routes the case into a reviewable allowlist, blocklist, or dismissal decision.

How the workflow works

  1. Publish the customer-specific dispute link. Add it to an access-denied page, WAF response, or support article.
  2. Protect the submission. BotGuard helps reduce automated dispute spam while the form captures the source IP and contact details.
  3. Snapshot the evidence. FraudGuard records reputation, threat, network, geography, and customer-list context at submission time.
  4. Review the case. The customer compares that snapshot with its own account, request, and support evidence.
  5. Resolve deliberately. Allowlist, blocklist, or dismiss the dispute in the app or through the API.
  6. Keep the outcome. Status and decision history create a clearer audit trail than an undocumented rule change.

What a reviewer should check

  • Does the requester control or legitimately use the address?
  • Is the IP dedicated, dynamic, shared, or part of a VPN or provider range?
  • What behavior was observed, and how recent was it?
  • Does the dispute match a real customer, partner, transaction, or support case?
  • Would an account-, route-, or time-scoped exception be safer than a broad allowlist?
  • Who owns the exception and when should it be reviewed?

An allowlist should not erase the evidence. It records a customer-specific policy decision that the legitimate business context outweighs the external source-IP risk for the intended workflow.

Avoid permanent exceptions by default

Addresses change and business relationships end. Use an owner, reason, scope, and review date for every exception. If your enforcement layer supports it, prefer the narrowest useful exception: one tenant, route, integration, or time period rather than a global bypass.

High-confidence current attacks should not be overridden solely because a form was submitted. Escalate cases where the identity or business relationship cannot be verified.

The best dispute process is visible at the moment of denial. A useful block page includes:

  • a plain-language explanation that access was restricted;
  • a reference or correlation identifier;
  • the detected source IP;
  • a link to the protected dispute form;
  • an alternative support route for sensitive accounts;
  • no internal score, detector, or policy details that would help an attacker tune evasion.

Measure false-positive operations

Track more than the number of disputes:

  • dispute rate per blocked request;
  • verified legitimate disputes;
  • time to first review and resolution;
  • allowlist expiry and renewal;
  • repeat disputes from the same customer or provider;
  • decisions later reversed;
  • abuse observed after an exception.

These metrics show whether a problem comes from reputation evidence, policy thresholds, missing customer context, or an overly broad enforcement point.

Availability

Open IP Dispute Manager in the FraudGuard app or review the API documentation. Feature availability can change; confirm the current plan on the pricing page.

False positives cannot be solved by hiding the block. They are solved by preserving evidence, verifying the legitimate case, and turning the exception into a controlled policy decision.