# Card Testing for Issuers
source: https://developer.mastercard.com/mastercard-threat-intelligence/documentation/use-cases/card-testing-for-issuers/index.md

## Overview {#overview}

This document provides practical usage scenarios for the Card Testing API from an Issuer perspective. The use cases demonstrate how Issuers can leverage card testing intelligence to identify payment cards exhibiting card testing activity, investigate related authorization attempts, and prioritize fraud mitigation actions.

This illustrates how Issuers can integrate card testing intelligence into fraud operations to proactively identify accounts at elevated risk and support investigation workflows.
Note: All use cases share the same setup. You call the API over HTTPS with OAuth 2.0 authentication, and you read typed JSON responses. For authentication and environment details, see [API Basics](https://developer.mastercard.com/mastercard-threat-intelligence/documentation/api-basics/index.md).

## Investigate an At-Risk Account {#investigate-an-at-risk-account}

### Context {#context}

Card testing is often an early indicator that payment card credentials may have been compromised and are being validated through low-value authorization attempts. Fraud analysts frequently need to determine whether a customer account has exhibited card testing activity and then investigate the associated transactions to understand the scope, timing, and characteristics of the activity.

### Goal {#goal}

Find flagged transactions and identify affected cards and Bank Identification Number (BIN) portfolios.

### Main actors {#main-actors}

The analyst, your application, and the Mastercard Threat Intelligence API.

### Preconditions {#preconditions}

* The Issuer has access to Mastercard Threat Intelligence APIs.
* OAuth credentials and access tokens have been obtained.
* A fraud investigation case or account review has been initiated.

### Desired outcome {#desired-outcome}

* Relevant card testing activity is identified.
* Related card testing transactions are retrieved and reviewed.
* Analysts gain additional visibility into potential account compromise indicators.
* Investigation findings are documented.
* Appropriate fraud mitigation actions can be considered.

## Steps {#steps}

Tip: This is a multi-step flow. The first request discovers which identifiers have data. The second request searches transactions within those identifiers.

1. Call the filter options endpoint with `type=TRANSACTIONS` to discover CIDs, ICAs, and BINs that have data.
2. Search transactions, filtered by a BIN from the previous step.
3. Review the flagged transactions, risk scores, and reason codes.

### Sequence {#sequence}

Diagram mti-card-testing-issuers

### Endpoints and step mapping {#endpoints-and-step-mapping}

**Step 1** discovers the filter values.

API Reference: `GET /threats/card-testings/filter-options`

**Step 2** searches flagged authorization attempts.

API Reference: `POST /threats/transactions/searches`

## Filter options request and response {#filter-options-request-and-response}

```text
GET /threats/card-testings/filter-options?type=TRANSACTIONS
```

```json
{
  "cids": ["456789"],
  "icas": ["6789"],
  "bins": ["54321098"]
}
```

### Transactions request and response {#transactions-request-and-response}

```json
{
  "filters": {
    "fieldFilters": { "bins": ["54321098"], "riskScore": 998 },
    "transactionDateRange": { "start": "2025-10-01T00:00:00Z", "end": "2025-10-31T23:59:59Z" }
  },
  "page": { "limit": 20, "offset": 0 },
  "sort": { "by": "transactionDate", "direction": "DESC" }
}
```

```json
{
  "records": [
    {
      "customerName": "FAST MONEY BANK, N.A.",
      "issuerIca": "6789",
      "bin": "54321098",
      "transactionDate": "2025-10-26T12:34:56Z",
      "transactionAmount": 0.01,
      "transactionStatusIndicator": "ACCOUNT_STATUS_INQUIRY",
      "riskScore": 998,
      "reasonCode": "C7",
      "merchantName": "FUNPARTYSUPPLIES.COM",
      "transactionId": "5432100000123456789",
      "currencyCode": "USD"
    }
  ],
  "page": { "limit": 20, "offset": 0, "total": 1 }
}
```

## Error Handling and Scenarios {#error-handling-and-scenarios}

Every endpoint uses the same error model. An error response includes `source`, `error`, `recoverable`, and `error_description`. The `recoverable` field indicates whether retrying could change the outcome.

The most common scenarios across all use cases are:

* `400 Bad Request`: a field fails validation, for example an out-of-range `limit` or an invalid `reason`. Correct the request and send it again.
* `403 Forbidden`: your project lacks access to the requested feature or data scope. Confirm your product enrollment, credentials, environment, and entitlements.

For card testing use cases, filter your searches to the CIDs, ICAs, and BINs returned by the filter options endpoint. Searching identifiers outside your access scope can lead to a `403 Forbidden` response.

For detailed error questions and troubleshooting, see the [Codes and Formats](https://developer.mastercard.com/mastercard-threat-intelligence/documentation/code-and-formats/index.md) page. For the full list of status codes and error fields, see the error models in the [API Reference](https://developer.mastercard.com/mastercard-threat-intelligence/documentation/api-reference/index.md).