> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fraudtraceai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# FraudTrace Intelligence Database: Stats, Sources, Privacy

> Explore the FraudTrace Intelligence Database: 24,76,004+ indexed UPI IDs from 18,330+ sources, with real-time lookups and full India data residency.

The FraudTrace Intelligence Database is the continuously updated, real-time store of fraud-actor entities that your API queries every time you call `/v1/verify/upi`. It is not a static blocklist assembled from incident reports — it is a live intelligence corpus built by an automated OSINT pipeline that monitors the places where fraud actually happens: Telegram channels, gambling and betting sites, scam forums, dark-web dumps, and rogue mobile apps. Understanding what the database is, how it is built, and what it deliberately does not contain will help you trust the signals it returns and communicate them clearly to your risk and compliance teams.

## What the database contains

The Intelligence Database indexes **fraud-actor entities** — identifiers that have appeared in a fraud context — across four entity types:

<CardGroup cols={2}>
  <Card title="UPI VPAs" icon="at-sign">
    Virtual Payment Addresses found on deposit pages, scam channels, and phishing sites. The primary entity type queried by the FraudTrace UPI API.
  </Card>

  <Card title="Phone Numbers" icon="phone">
    Mobile numbers linked to fraud registrations, Telegram fraud-channel admins, and scam app sign-ups.
  </Card>

  <Card title="Domains" icon="globe">
    Web domains hosting illegal betting platforms, investment scam landing pages, or NBFC impersonation portals.
  </Card>

  <Card title="App Packages" icon="smartphone">
    Android package names (`com.example.fakeinvest`) of fraudulent APKs distributed outside the Play Store.
  </Card>
</CardGroup>

## Key statistics

| Metric          | Value      |
| --------------- | ---------- |
| Indexed UPI IDs | 24,76,004+ |
| Crawled sources | 18,330+    |
| Mule clusters   | 1,188      |
| Lookups served  | 94,72,910+ |

These numbers grow continuously as the OSINT pipeline ingests new sources.

## How the database is built

The database is populated entirely by FraudTrace's automated ingestion pipeline. No manual blocklist submission, no crowdsourced reports, and no data from customer bank systems ever enters this pipeline.

<Steps>
  <Step title="Source discovery">
    FraudTrace's discovery layer continuously finds new fraud infrastructure through keyword monitoring, domain registration feeds, Telegram channel graph traversal, and referral links between known fraud sites.
  </Step>

  <Step title="Crawling and monitoring">
    Discovered sources are added to the crawl queue. Active sources are re-crawled at regular intervals. Telegram channels are monitored in near-real time. The current corpus covers **18,330+** unique sources.
  </Step>

  <Step title="Entity extraction">
    Each crawled page or message is parsed to extract structured entities: UPI VPAs (matched against the `@psp` pattern), phone numbers, domains, and APK package names. Context metadata — page category, surrounding text, timestamp — is captured alongside each entity.
  </Step>

  <Step title="Enrichment">
    Extracted entities are enriched with cross-source correlation. A VPA seen on five different gambling sites receives richer metadata than one seen once. Domain WHOIS, app store data, and Telegram channel membership signals augment the raw extraction.
  </Step>

  <Step title="Confidence scoring">
    Each entity receives a **confidence score** (0.0–1.0) that reflects the strength of evidence for its fraud classification. Multiple independent sightings, high-confidence source types, and cluster membership all raise the score. See [Confidence Scores and Mule Clusters](/concepts/confidence-clusters) for details.
  </Step>

  <Step title="Clustering">
    VPAs that share device fingerprints, co-appear on the same fraud sites, or are linked through network graph analysis are grouped into **clusters** (prefixed `MC-`). Cluster membership is updated continuously as new evidence arrives.
  </Step>

  <Step title="Indexing for query">
    Processed records are written to the query index. From this point forward, any call to `/v1/verify/upi` for that VPA returns the enriched, scored, clustered result in under 200 ms.
  </Step>
</Steps>

## Update frequency

Ingestion is **continuous and real-time**. There is no nightly batch window. When a VPA appears on a newly discovered fraud site, it is typically indexed and queryable within minutes. This is critical for fast-moving fraud campaigns where a mule VPA may be live for only a few hours before being rotated.

## What the database does NOT contain

FraudTrace is built to detect fraud-actor entities, not to store data about victims or customers of financial institutions. The following data is explicitly **not** present in the Intelligence Database:

* Personal data of fraud victims (names, Aadhaar, PAN, addresses)
* Bank account numbers or IFSC codes
* Transaction histories or payment amounts
* Balances or account statements
* Any data originating from customer bank systems, core banking platforms, or CBS exports
* Any data provided by your API integration beyond the VPA you query

Your call to `/v1/verify/upi` with a VPA sends only that identifier. FraudTrace does not log or retain the VPA you query for purposes beyond serving the immediate API response.

## How you query the database

All access to the Intelligence Database is through a single REST endpoint:

```http theme={null}
GET /v1/verify/upi?vpa={upi_vpa}
```

**Response time:** \<200 ms (p99)\
**Authentication:** Bearer token in the `Authorization` header\
**Rate limit:** Defined per plan; see your dashboard for current limits

For the full response schema, see [Evidence Schema: What FraudTrace Returns](/concepts/evidence-schema).

<Info>
  **Data residency:** All FraudTrace infrastructure — ingestion pipeline, database, and API — runs exclusively on AWS Mumbai (`ap-south-1`). No data leaves Indian cloud infrastructure. This supports your compliance with RBI data localisation requirements.
</Info>