A dynamic cryptogram is a payment card security code that changes automatically on a schedule instead of staying fixed. It helps reduce reuse of copied card data in card-not-present transactions. The issuer or processor validates the current value at authorisation time, which makes the code less useful to fraudsters.
What the term means in card payments
A dynamic cryptogram is a card security code that is designed to change on a schedule rather than remain fixed. The goal is to make copied card data less reusable, especially when a transaction is completed without the physical card present.
This matters because the code is not just a static verification value, it is part of the issuer’s validation step at authorisation time. If the current value no longer matches, the transaction is less likely to be approved.
How it works in practice
In a normal card-not-present flow, a merchant captures the card details and submits them for payment authorisation. With a dynamic cryptogram, the issuer or processor checks whether the submitted code is still current, which turns a previously useful stolen value into something that can expire or roll forward.
The exact timing and format vary by programme, card type, and payment network implementation. Some deployments are tied to a tokenised card experience, while others are used to reduce risk in digital commerce more generally. The common idea is the same: keep the security code short-lived so that a copied value has a smaller window of usefulness.
Why it reduces fraud utility
The main security advantage is that it weakens replay value. If a criminal copies card data from a breach, skimming event, or phishing capture, a fixed code can often be reused until the card is replaced. A dynamic cryptogram reduces that advantage by making the code time-sensitive.
This does not remove all payment fraud risk. Attackers may still try account takeover, social engineering, device compromise, or abuse of stored credentials in merchant systems. It simply narrows one class of abuse by making the verification secret less durable.
Where it fits in the payment stack
Dynamic cryptograms sit in the authentication and transaction-validation layer, not in the merchant’s business logic. They are most useful where card data may be exposed to copying, forwarding, or reuse outside the original context.
The control is strongest when paired with other payment security measures such as tokenization, fraud analytics, risk-based authorisation, and strong cardholder authentication where appropriate. On its own, it is a risk-reduction mechanism, not a complete fraud-prevention strategy.
Risk and Threat Considerations
Dynamic cryptograms reduce the value of stolen card data, but they also create a dependence on correct issuer-side validation and on merchants sending the right transaction data at the right time. If the validation path is broken, out of sync, or poorly implemented, legitimate payments may fail or, in weaker designs, stale data may be accepted longer than intended.
Failure mechanism: Attackers benefit when copied card data can be replayed before the code rotates, when merchants or processors mishandle the validation window, or when related fraud controls are too weak to catch reuse attempts.
Impact: Successful replay or delayed detection can increase card-not-present fraud losses, reduce trust in the payment flow, and create operational friction through false declines or customer support escalations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dynamic cryptograms rely on managed, time-bound authenticator values. |
| Recommendation — Manage code lifetimes and rotation so replayed payment data loses value quickly. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Card authorisation depends on validating the current transaction credential correctly. |
| Recommendation — Verify transaction authentication inputs so stale codes are rejected at authorisation. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | The term is about controlling and validating a short-lived authenticator at transaction time. |
| Recommendation — Apply authenticator-management controls that enforce short-lived verification values. | ||
| CIS Controls v8 | CIS-5 — Account Management | Card-payment security depends on controlling reusable payment credentials and their lifecycle. |
| Recommendation — Control the lifecycle of reusable payment credentials and reduce replay exposure. | ||
Practitioner Guidance
What to watch for: Treat the dynamic cryptogram as one control in a layered card-fraud strategy. Its value depends on rotation discipline, correct authorisation checks, and clean integration across the issuer, processor, and merchant path.
Practitioner takeaway: Use it to shrink the reuse window for copied card data, but validate the full payment path so the control improves fraud resistance without introducing avoidable decline rates.