Request demo

Fraud Prevention

Work Fraud From the Leak Before the Chargeback.

Card fraud and account takeover begin with data that surfaced somewhere else: a card number in a market listing, a customer login in an infostealer log, a lookalike domain waiting for traffic. Your fraud team gets each one as a record it can filter, export and close.

Request demo

Cards

  • card 4821 · Luhn ✓ · not expired · CVV present · 3 sightings

    State resolved

Filter bin in ['YOUR_BIN_1','YOUR_BIN_2']

Logins

  • sso.acme.example/login · j. · target service

Lures

  • acrne.example · fuzzy · dns ssl

Ranked usable cards first: Luhn-valid, not expired, CVV attached, seen recently

Where Fraud Gets Its Start.

A disputed transaction is the end of a chain. The earliest links are visible from outside, to anyone who looks.

Cards

Leaked Card Numbers

Numbers turn up in leak dumps, market listings and paste sites, sometimes with expiry and CVV. Until the issuer acts, the card stays usable.

Logins

Customer Credentials

A customer’s infected device leaks every saved login, including the one to your portal. The breach isn’t yours. The takeover risk is.

Lures

Lookalike Infrastructure

A domain one character away from yours, a fake app, a search result pointing to a fake support line. Each one collects the card numbers and logins that later go up for sale.

Each Fraud Pattern Maps to a Capability.

Card-Not-Present Fraud

Leaked cards with BIN, issuer, brand, expiry, CVV presence, a Luhn check and sighting history, filtered to your ranges.

CTI

Account Takeover

Customer logins to your services found in leaked credential data, each with the URL, the username and the service it opens.

CTI

Phishing and Payment Redirection

Domains matched to your brand names, including fuzzy and confusable matches, monitored for DNS, mail, certificate and web activity, each with a risk score timeline.

BRP

Fake Apps

App listings that present themselves as yours. Coverage is confirmed per engagement.

BRP

Fake Support and Refund Pages

Search results that use your brand to send customers to pages you don’t run. Coverage is confirmed per engagement.

BRP
Confirmed lures go to Managed Takedown

From Leaked Record to Closed Case.

  1. 01

    Scope

    Filter to what is yours: your BIN ranges, the login URLs of your services, the brand names customers know.

  2. 02

    Rank

    Put usable cards first: Luhn-valid, unexpired, CVV attached, seen recently. Put customer logins to high-value services ahead of the rest.

  3. 03

    Act

    Reissue or block cards, force resets or step-up checks on accounts, and send confirmed lookalikes to takedown. Those decisions run in your payment and identity systems.

  4. 04

    Close

    Mark each record resolved, risk accepted, ignored or false positive, one at a time or in bulk by filter. A decision can be reverted.

Records Your Fraud Stack Can Consume.

Payment and client credentials each have search, export and bulk state actions in the API. The filter that finds the records also closes them.

A fraud team pulls new leaked cards on its BINs into the rules engine it already runs, and closes all cards on a BIN after a reissue in one request.

Export API reference
Export cards on your BINs 
curl -X POST \
  "https://api.deepinfo.com/v1/cti/compromised-payment-credentials/search:export?format=csv" \
  -H "apikey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "must": [
        { "name": "bin", "type": "in",
          "value": ["YOUR_BIN_1", "YOUR_BIN_2"] }
      ]
    }
  }'

The Lures Start as Domains.

One brand name and a candidate for each match type, including lookalike letters from other alphabets.

  1. acme.example

    Your keyword

    Each rule pairs it with one match type

  2. acme.test

    Same name · exact

    The name itself, on another TLD

  3. acme-login.example

    Name inside · contains

    The name inside a longer label

  4. acrne.example

    Typo · fuzzy

    One edit away: a dropped, doubled, swapped or mistyped letter

  5. acem-verify.example

    Typo inside · fuzzy_contains

    A typo inside a longer label

  6. аcme.example

    resolves as xn--cme-5cd.example

    Lookalike letters · confusable_exact

    Letters swapped for ones that look identical

  7. аcme-login.example

    resolves as xn--cme-login-zyh.example

    Lookalike letters inside · confusable_contains

    Lookalike letters inside a longer label

  8. aсem.example

    resolves as xn--aem-4ed.example

    Lookalike and typo · confusable_fuzzy

    A typo and a lookalike letter together

  9. secure-aсem.example

    resolves as xn--secure-aem-jwi.example

    Lookalike and typo inside · confusable_fuzzy_contains

    Both, inside a longer label

Fraud Work in Real Programs.

Customer story A humanitarian foundation Fraudulent donation domains removed through Managed Takedown, donor credentials watched in breach data. Read Customer story A metropolitan municipality Lookalikes of citizen-facing services caught and removed around filing and enrollment periods. Read Use case Phishing Detection and Prevention Lookalike domains found at registration and routed to takedown. Read

Use This Data in Your Tools

The domains the index sees each day are also a daily file and a search API, for teams that run their own lookalike matching or enrich alerts in a SIEM.

Questions About Fraud Prevention

Does the Deepinfo Platform block fraudulent transactions?

No. It surfaces leaked cards, leaked customer logins and lookalike infrastructure as records. Blocking, reissuing and step-up decisions stay in your payment and identity systems, fed by search or export.

Can card monitoring be limited to our own BINs?

Yes. BIN is a searchable field alongside issuer name and country, card brand, type and level. That filter also drives exports and bulk state changes.

Where does the card data come from?

From the markets, leak dumps and paste sites where card numbers are posted. Each record keeps where the card was listed and how often it was seen.

What counts as a client credential?

A login to one of your services that belongs to a customer rather than an employee, found in leaked credential data. Each record carries the URL it was used on, the username and the service behind it.

Can we catch a lookalike domain before it goes live?

Yes, if it is matched while still parked. Rules match names as they come into the index, and include_past extends a new rule to names already there. Once your team approves a match, monitoring shows when it gets a mail server, a certificate or a live web page.

See What’s Circulating With Your Name.

Book a demo and we’ll walk your fraud team through card, login and lookalike records scoped to your BINs, services and brands.

Request demo