Compromised Payment Credential Monitoring

Each Leaked Card Comes With Its Paper Trail.

Q: Can we close every card from one leak at once?

Yes. Filter on leak_name, check the result with a search, then send the same filter to the state change, and every card from that leak moves in one request.

Card numbers turn up in leak dumps, market listings and paste sites. A number on its own tells a fraud team very little.

The Deepinfo Platform records each leaked card with the attributes your team filters on (BIN, issuer, brand, expiry, whether a CVV came with it) and with its trail: where it was listed, when it was first and last seen, and how many times.

Request demo Platform guide: Compromised payments

masked 4821

Card record

masked · last four only

Leaked card:

BIN · issuer
a BIN you watch · issuer and country from the BIN
Checks
Luhn valid, Expiry not expired, CVV present : Usable

Usableevery check passed:
Source
leak on a market · source network

Where it was listedsource network:
Hackishness
0.8
Sightings
first seen last seen seen 3 times

First and last seen, and how many times:
Co-listed
other cards in the same listing

New cardnewly_detected

What Each Card Record Carries.

Masked number and last four	The card number with its middle digits hidden, and the last four digits for matching
BIN	The issuer identification number, for filtering to your ranges
Issuer and country	The issuing bank and its country
Brand, type and level	Card brand, card type and card level
Expiry	Expiry month and year, and whether the card has already expired
CVV present	Whether a CVV was listed with the number
Luhn valid	Whether the number passes the Luhn checksum, a quick filter for junk
Source	Leak name, source URL and network, with a hackishness score for the page
Sightings	When the card was first and last seen, and how many times
Co-listed cards	How many other cards appeared in the same listing

Fields as documented in the Compromised Payment Credential Search reference.

Read a Card Record Like a Fraud Analyst.

The fields are there to rank the queue. These readings do most of the work.

One card record, read three ways

Usable
A number that passes Luhn, has not expired and came with its CVV is ready for card-not-present fraud. It goes to the top.

It reads Expiry, CVV present, Luhn valid.
Circulating
A recent last-seen date and a high times-seen count suggest the card is still being passed around.

It reads Sightings.
Batch
A high co-listed count points to a bulk dump. Group those cards by leak name and BIN to work them as one event.

It reads BIN, Source, Co-listed cards.

Issuers and Merchants Read It Differently.

Card Issuers

Filter to your BINs, then decide card by card: reissue, block or watch. Issuer name and country keep portfolios and subsidiaries apart.

Industry

Merchants and Payment Providers

Group cards by leak name and source to see which listings they came from, and pass that evidence to your acquirer or the issuers concerned.

Industry

Fraud and Risk Teams

Pull matching records into the rules engine or case management you already run, through search or export.

Use case

Close a Whole BIN in One Request.

New cards arrive as newly_detected and move through the states used for other CTI credentials: resolved, risk accepted, ignored or false positive, with a revert. Each action takes a search filter, so the cards you review are exactly the cards you change.

Filterbin.json3 changed

must bin eq YOUR_BIN

YOUR_BIN masked 4821
marked_as_resolved
5 masked 1150 (not selected)
unresolved
YOUR_BIN masked 0937
marked_as_resolved
YOUR_BIN masked 7702
marked_as_resolved

Request

POST …/compromised-payment-credentials/search:mark-resolved

curl -X POST \
  "https://api.deepinfo.com/v1/cti/compromised-payment-credentials/search" \
  -H "apikey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d @bin.json

curl -X POST \
  "https://api.deepinfo.com/v1/cti/compromised-payment-credentials/search:mark-resolved" \
  -H "apikey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d @bin.json

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 @bin.json

{
  "filters": {
    "must": [
      { "name": "bin", "type": "eq", "value": "YOUR_BIN" }
    ]
  }
}

Compromised Payment Credential Search reference

Query This Data Through the API

Credentials and dark web findings stay in the Deepinfo Platform. The domain and vulnerability data around them is open through the API.

Questions About Compromised Payment Credential Monitoring

Can we filter to our own BIN ranges?

Yes. BIN is a searchable field, alongside issuer name, issuer country, card brand, card type and card level. Filters combine with must, should and must_not, and that filter also drives exports and bulk state changes.

What does Luhn valid mean?

The Luhn checksum is the check digit built into every card number. A number that fails it was mistyped or made up, so it can be set aside before anyone looks further.

Can we close every card from one leak at once?

Yes. Filter on leak_name, check the result with a search, then send the same filter to the state change, and every card from that leak moves in one request.

Can we see how many cards have leaked over time?

Yes. Payment credential statistics return the total number of card records and a count per year, through the CTI API.

How does card data reach our fraud systems?

Through the CTI API. Search returns matching records as JSON, and export returns all matching records as CSV or JSON without pagination. The endpoints are documented in the CTI reference.

See Which Cards on Your BINs Have Leaked.

Book a demo. We’ll walk your fraud team through card records, filters and the state workflow on your scope.

Request demo

Platform

Solutions

Data & API

Resources

Company