How to Run a Card-Linked Offers Programme Without Expanding PCI DSS Scope

Information security teams are right to be cautious about loyalty programmes. Every new system that stores, processes or transmits full card numbers joins the bank's PCI DSS scope, with all the controls, testing and audit evidence that implies. A marketing initiative that quietly adds a new card data environment is a genuine risk.

The good news is that a well-designed card-linked offers programme does not need full card numbers at all. This guide explains the principles of a "scope-light" design and the questions to ask any vendor.

This article is general guidance, not a compliance opinion. Always confirm scope decisions with your Qualified Security Assessor (QSA) and internal compliance team.

A quick refresher on PCI DSS scope

The Payment Card Industry Data Security Standard applies to systems that store, process or transmit cardholder data, and to systems connected to them that could affect their security. The central piece of cardholder data is the primary account number (PAN), the long number on the front of the card.

The standard also recognises techniques that reduce risk, such as truncation (keeping only a limited number of leading and trailing digits), tokenisation and strong network segmentation. Used properly, these can keep systems out of scope or significantly reduce the controls required.

Why many loyalty systems end up in scope

Traditional card-linked programmes often ingest full transaction data, including PANs, to match purchases to offers. Others ask customers to type their full card number into a registration form. Both approaches pull the loyalty platform, and sometimes the marketing team's tools, into the card data environment.

The result: longer security reviews, higher audit costs, more risk and, often, a programme that takes months longer to launch.

The principles of a scope-light design

1. Never collect the full card number

The simplest way to avoid storing PANs is to never ask for them. Registration can instead use:

• A truncated identifier, such as the first five and last four digits of the card.
• The customer's registered mobile number, already known to the bank.
• A one-time password (OTP) sent to that mobile number to confirm the customer is who they say they are.

The combination of partial digits, mobile number and OTP is enough to link a customer to an eligible card product and to their offers, without the platform ever seeing the full PAN.

2. Let the bank own the mapping

If the programme needs to know which cards are eligible, the bank can share eligibility using internal customer or account references, or tokens, rather than PANs. The mapping between the reference and the real card number stays inside the bank's existing, already-assessed environment.

3. Redeem without card numbers

Redemption at the merchant should never require a card number. Scope-light options include:

• Rotating customer codes shown in the app and entered by the merchant.
• QR or PIN tent cards that the customer scans at the counter.
• Coupon codes and tracked links for online merchants.

None of these touch card data. The merchant confirms that an eligible customer is present; the bank's payment systems handle the payment as usual.

4. Keep merchants away from cardholder data

Merchants should see only what they need: that an offer was redeemed, when and, if the customer consents, basic information. They should never see PANs or full customer profiles.

5. Separate environments cleanly

Where the loyalty platform does connect to bank systems, for example by file transfer or API, keep the interfaces narrow and well documented. Exchange only the fields needed, and make sure none of them are full card numbers.

Beyond PCI: broader security controls

Keeping card data out of scope is important, but a loyalty platform still handles personal data and business-critical processes. Look for controls aligned with recognised frameworks such as SOC 2 and ISO 27001, including:

• Role-based access control and multi-factor authentication for staff and merchants.
• Encryption of data in transit and at rest.
• Detailed audit logs for configuration changes, approvals and data access.
• Secure software development practices and regular penetration testing.
• Data retention and deletion policies that match local regulation.
• Clear incident response procedures.

Questions to ask any offers platform vendor

1. Does your platform ever store, process or transmit full card numbers? If so, where and why?
2. How do customers register their cards? What data is collected?
3. How do merchants validate offers? Do they ever see card data?
4. What data do you need from our systems, and in what format?
5. Which security frameworks are your controls aligned with, and what evidence can you share?
6. Where is data hosted, and how do you meet local data residency requirements?
7. How are access, logging and incident response handled?

A vendor with a genuinely scope-light design will answer the first three questions simply and quickly.

The business benefit

Scope reduction is not only about avoiding risk. It changes the project itself:

• Faster approvals, because security reviews focus on a narrower set of questions.
• Lower cost, because fewer systems need PCI controls and audit evidence.
• More flexibility, because marketing and product teams can iterate without touching the card data environment.
• Greater customer trust, because the bank can say, truthfully, that the offers programme never holds full card numbers.

Summary

A card-linked offers programme can be engaging, measurable and secure without expanding the card data environment. Identify cards with truncated digits and an OTP to the customer's mobile, let the bank keep the mapping, redeem with codes rather than card numbers and keep merchants away from cardholder data.

cardoff.ai was designed this way from the start: cards are identified by first-five and last-four digits plus mobile OTP, never a full PAN, with controls aligned to SOC 2 and ISO 27001. If your security team would like to review the architecture, we are happy to share the details.