# PAN-Related Decisions
source: https://developer.mastercard.com/mastercard-processing-core/documentation/guides/pan-related-decisions/index.md

Many financial institutions must be de-scoped from some Payment Card Industry Data Security Standards ([PCI DSS](https://www.pcisecuritystandards.org/)). This means that the full Primary Account Number (PAN) of the card or other sensitive data cannot be used as card identifier and cannot appear in any field of API requests or responses. This document refers to this situation as "PAN-less".

The Mastercard Processing API offers solutions to both types of issuers:

* Full-PAN or PAN users can use full PAN as card identifiers. In these situations:
  * The API may return the full PAN in the API responses.
  * You can assign a PAN number during a card creation request by sending the full PAN in the `cardContractNumber` field.
  * You can use ISO-0 or ISO-1 format for the PIN block operations (`getPin`, `setPin`, and `verifyPin`), depending on your API configuration.
* PAN-less users cannot use full PAN. In these situations:
  * The API will always mask PAN in the API responses.
  * Mastercard Processing CMS will generate PAN number during card creation request based on the assigned BIN ranges.
  * You must use ISO-1 format for the PIN block operations (`getPin`, `setPin`, and `verifyPin`).

Note: To support PAN-less issuers with displaying the card details (PAN, PIN, and CVC) to the cardholder, Mastercard Processing offers an additional level of encryption. In this encryption, the PCI data is encrypted with the `Customer-Public-Rsa-Key` sent in the request generated by the cardholder's device so that issuer's back-office systems cannot decrypt it. For more information, refer to the following use cases:

* [Set a PIN for a Full PAN Issuer](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/pin-management/set-pin-full-pan-issuer/index.md)
* [Set a PIN for a PAN-less Issuer](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/pin-management/set-pin-pan-less-issuer/index.md)
* [Display a PIN](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/pin-management/display-a-pin/index.md)
* [Display Card Details to the Cardholder](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/disp-card-det-to-crdholder/index.md)

## Proxy Card Identifiers {#proxy-card-identifiers}

There are two options for setting a proxy card identifier:

* Use `cbsNumber` (Core Banking System number), a card contract identifier that can be generated by:
  * A user: In this situation, you must send the `cbsNumber` in a `createCardContract` request. The Mastercard Processing CMS generates the technical `cardContractId` and stores both identifiers on a card contract record. In this option, the `cbsNumber` has a different value than the `cardContractId`.
  * Mastercard Processing: In this situation, `cbsNumber` always receives the same value as `cardContractId`, and the returned responses are unique technical card identifiers.
* Use `cardContractId`, the technical number generated by the Card Management System (CMS). The Mastercard Processing CMS generates a unique technical identifier when creating the card object (the `POST` request is sent to the `/cards` endpoint). This identifier is returned to you in response to create operations and must be used further in API requests to manage the created card object.

The proxy card ID approach has implications on the card PIN block format used in [PIN Management](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/pin-management/index.md) operations.