Some security decisions cannot depend on a live external API. The FraudGuard Offline Threat Database delivers IP intelligence as SQLite or CSV data so customers can enrich and enforce locally.

It is designed for high-volume systems, restricted networks, appliances, batch pipelines, and request paths where predictable local latency matters more than the freshest possible lookup.

Choose SQLite or CSV

SQLite

SQLite is the simplest option when an application or security service needs indexed local lookups. The database can be downloaded, validated, swapped atomically, and queried without running another server.

Good fits include authentication gateways, edge services, local APIs, appliances, and incident-response workstations.

CSV

CSV is better when the data will be loaded into a warehouse, SIEM, search cluster, distributed processing job, or an existing internal threat-intelligence schema.

Good fits include historical enrichment, firewall or WAF feed generation, analytics, and custom data pipelines.

Review the current SQLite and CSV delivery documentation before integrating.

Why local delivery matters

  • Predictable latency: lookups happen inside the application or network.
  • High-volume economics: large joins do not require one remote call per row.
  • Resilience: a live API outage does not stop local decisions.
  • Privacy and control: source addresses and surrounding event data can remain inside the customer environment.
  • Disconnected operation: approved workflows can continue in restricted or intermittently connected networks.

These benefits introduce a tradeoff: local intelligence has an age. Delivery cadence depends on the plan, and every integration should expose when the active file was generated.

Common use cases

  • authentication and account-takeover controls;
  • SIEM and data-lake enrichment;
  • firewall, WAF, reverse-proxy, and secure-web-gateway policy;
  • appliance and edge deployment;
  • incident response and historical forensics;
  • offline malware-analysis labs;
  • local risk features for fraud and abuse models;
  • air-gapped or tightly controlled environments with an approved transfer process.

A production update pattern

Do not replace the active file in place while readers are querying it.

  1. Download to a staging path over an authenticated connection.
  2. Verify the transfer, expected format, and basic row-count or schema checks.
  3. Run a known-query smoke test.
  4. Move the validated file into place atomically or update a versioned pointer.
  5. Keep the previous version for rollback.
  6. Record generation time, activation time, and update status.
  7. Alert when data age exceeds the policy threshold.

For CSV, apply equivalent validation before loading the destination system or publishing generated rules.

Decision design

An offline record should remain one input to policy. Combine it with the current request, account, session, and route. Prefer tiered actions when the evidence is ambiguous, and keep customer allowlists or exceptions separate from the vendor dataset.

Plan explicitly for:

  • stale-data behavior;
  • missing IPs;
  • IPv4 and IPv6 normalization;
  • cache invalidation after a file swap;
  • customer-specific allowlists and blocklists;
  • rollback after an unexpected change;
  • audit logging of dataset version and decision reason.

API or offline database?

Use the live API when freshness, a rich explainable response, and account-specific policy need to arrive together. Use offline data when local control, volume, privacy, or disconnected operation dominates. Many mature deployments use both: local data for the broad path and ACE v2 for high-risk or ambiguous decisions.

Review current delivery cadence and eligibility on the FraudGuard pricing page, or contact hello@fraudguard.io for a format or deployment requirement that needs review.