Short answer: The KVKK loyalty card decision (principle decision 2026/266) ends the practice of using a loyalty card at the till simply by telling the cashier a phone or card number, without verifying that the member knows about it and consents. KVKK is Türkiye's personal data protection authority. Its Board extended the compliance deadline to 28 February 2027 with decision 2026/1491. Verification covers every use of the card, including creating a membership, earning points, spending points and discounts or promotions. The Board gives these methods as examples: a one-time code sent by SMS, a barcode or QR code in the app or on the website, a physical card, a card PIN at the till, and an "opt-in" that the member selects in their online account. So the phone number does not disappear from the till; what disappears is unverified use. The real work lies in earning points and discounts, which, according to the decision, commonly run without any verification.
We wrote this guide for IT, CRM and e-commerce managers at retail and franchise chains that run their loyalty programme on their own or partly custom till, CRM and mobile app systems. It is also relevant for international brands that run stores in Türkiye, directly or through franchise partners. If you use off-the-shelf till software, you can use this article as a list of questions for your vendor. We read the decisions in the Official Gazette (Resmî Gazete, where Turkish laws and official decisions are published) and in KVKK's announcements. We based our technical recommendations on primary sources such as OWASP and the IETF. Our recommendations are engineering options, not legal advice. By "till" or "POS", we mean the in-store sales software and the fiscal cash register device (ÖKC) used in Turkish stores; for online payments, see our virtual POS integration guide. This article is up to date as of 31 October 2026.
What does the KVKK loyalty card decision say? Two decisions in one table
The Board (Kişisel Verileri Koruma Kurulu, KVKK's decision-making body) examined this scenario: a third person tells the cashier a member's phone or card number. The purchase is made on the member's card without any approval code being entered. An invoice or similar document is issued in the member's name, and the purchase data is recorded in their account. The decision names food, cosmetics, technology, DIY stores and clothing as example sectors.
| Topic | 2026/266 (main decision) | 2026/1491 (extension) |
|---|---|---|
| Decision date | 11 February 2026 | 22 July 2026 |
| Official Gazette | 28 February 2026, Issue 33182 | 13 August 2026, Issue 33339 |
| What does it do? | Ends unverified use; requires the technical and administrative measures in Article 12 of Law No. 6698 on the Protection of Personal Data; 6-month compliance period | Extends the period, which would have ended on 28 August 2026, to 28 February 2027 following requests from the sector |
| Scope | Every use: membership, earning points, using points, discounts/promotions "etc." | Same scope; only the deadline changed |
All three strands of the Board's reasoning affect software design:
- No legal basis: When a third person uses the number without the member's knowledge and consent, none of the processing conditions in Article 5 of Law No. 6698 can justify it. That makes it unlawful data processing.
- A wrong record is also a breach: Issuing a document in the member's name for a purchase they did not make, or writing that purchase to their account, breaches the principle in Article 4 that data must be "accurate and, where necessary, kept up to date". The issue is not only who gets the discount, but also what is written to the profile and the document.
- A contract is not enough: Using the membership agreement to make the member responsible for not letting third persons use the card does not remove the data security obligation in Article 12.
According to the Board's findings, membership and spending points are already commonly verified with an SMS code or an app barcode/QR code. What runs without verification is the flow for discounts, promotions and earning points. So the real work lies in this flow, which is also the one that repeats most often.
The flexibility the decision leaves: The list of methods ends with "etc.", and the data controller decides which mechanism to use. Phone numbers are not banned: transactions the member has opted in to can be done with the number alone. The decision targets the in-store till. Applying the same logic to the call centre is our recommendation, not an obligation written in the decision.
Deadline and sanctions: As of 31 October 2026, KVKK's announcements and its list of principle decisions show no new extension or change, and 120 days remain until the deadline. The period has already been extended once at the sector's request, so keep watching the announcements. Those who do not comply will face action under Article 18 of Law No. 6698. We do not quote fine amounts here, because under Article 17(7) of the Law on Misdemeanours (Kabahatler Kanunu), administrative fines are increased every year by the revaluation rate.
Which 5 verification methods does the Board list, and what is the engineering cost?
The methods serve the same purpose, but they put different loads on the till, the budget and the support team. The assessment below is our own engineering view:
| Method | Flow at the till | Cost and infrastructure | If the connection drops | Weak point |
|---|---|---|---|---|
| SMS one-time code | The member reads the code from their phone and the cashier enters it; there is a wait for the SMS | An SMS fee for every verification | Needs access to the service and the SMS provider | SIM swaps, lock-screen previews; members who do not have their phone with them |
| App/web barcode or QR code | The till scans the code on the screen; no waiting | App and scanner integration; no message fees | The code can be scanned, but the server check waits for the connection | A screenshot of a static code can be shared; needs a smartphone |
| Physical card | The card is shown or scanned | Printing, distribution, a process for lost cards | The card is read locally | The card can be handed to someone else |
| Card PIN at the till | The member enters the PIN on the device themselves | Customer-facing input device, PIN reset | Central checking needs a connection | Forgotten PINs, shoulder surfing |
| Opt-in | The number is enough for permitted transactions | Account screen, record of preferences | The preference can be cached at the till | Anyone who knows the number can carry out the permitted transaction |
The practical takeaway: offering at least two methods covers both different customer groups and outage scenarios.
Is an SMS code required for every transaction? A verification matrix by transaction type
No. The decision says explicitly that different mechanisms can be chosen by transaction type (membership verification, earning points/discounts/promotions, spending points) and by level of risk. Our suggested starting point:
| Transaction | Primary method (suggested) | Alternative | If verification fails |
|---|---|---|---|
| Creating a membership | SMS code | Sign-up through the app or website | No membership is created; the sale is completed anonymously |
| Earning points | App QR code or physical card | The number if there is an opt-in; otherwise an SMS code | No points are credited; the member can claim them later with the code on the receipt |
| Personal discount/promotion | App QR code or physical card | SMS code or opt-in | No personal benefit is applied; general campaigns still apply |
| Spending points | SMS code or a time-based rotating QR code (TOTP) | Card and PIN | No points are spent |
This matrix is an engineering option, not a legal guarantee. The risk assessment and the choice of method are the data controller's decision.
Design the opt-in as a rule in the verification service, not as an exception. If the member has allowed a transaction type, the service accepts that transaction with the number. If not, it falls back to the method in the matrix. We recommend keeping the opt-in for spending points switched off by default.
Reference architecture: how should the till, CRM, SMS and e-Arşiv invoicing work together?
The most important design decision is where the rule is enforced. If the rule sits in the till screen, every till version and every franchise becomes its own weak point. We recommend putting the rule in the write API of the loyalty/CRM system: without a valid verification token, writes for points, personal discounts and profile data are rejected.
- Till (POS software and ÖKC): Finds the member by number, card or QR code. Until verification is complete, it shows masked details, not the member's name.
- Verification service: Opens a session tied to the basket, reads the opt-in preferences, and either generates an SMS code or checks the QR code, card or PIN. On success, it returns a short-lived, single-use token.
- Loyalty/CRM: Writes points, discounts and purchase data only with this token.
- SMS provider: Is called only through the verification service.
- Mobile app and web: Show the QR code, the opt-in preferences and the privacy notice.
- Document flow: Buyer details are filled in from the profile only for a verified transaction. According to GİB, Türkiye's Revenue Administration, a seller using the e-Arşiv system issues invoices as an e-Arşiv Fatura (e-archive invoice) to buyers who are not registered for e-Fatura, the e-invoice system. This includes consumers who are not taxpayers. If your ERP fills in buyer details from the profile automatically, tie this step to the verification token as well.
If your loyalty data sits in your own CRM system, the check is added there. If you use an off-the-shelf platform, ask your vendor for the same. We compared e-document integration options in our article on ERP and e-invoice integration.
When verification fails: complete the sale anonymously instead of stopping it
If verification fails, the sale does not stop; what must stop is every write that belongs to the member. The rule we recommend: the payment is completed, no personal discount or points are applied, nothing is written to the profile, and no document is issued in the member's name. A customer who wants a document provides their own details. A member who does not want to lose the points can be given the option to claim them later in their own app, with a one-time code on the receipt. That way, the write comes from the member's verified account. Also script in advance what the cashier will say in this situation.
What happens if the till is offline?
If the connection or the SMS provider goes down, the safest default is an anonymous sale. As OWASP warns, a fallback mechanism must not be weaker than the primary method. That is why "let's just use the number for now" is not a solution. Suppose offline points are a commercial requirement and your app uses a time-based rotating code (TOTP). In that case, the till stores the scanned code and the time of the scan. When the connection returns, the service verifies the code against that time, and only then are the points credited. This approach relies on the till clock being accurate and impossible for the cashier to change. Even then, no document is issued in the member's name. For SMS, set up automatic failover to a second provider.
How do you harden SMS codes and app QR codes?
The SMS text: structuring it in line with decision 2025/1072
KVKK's principle decision 2025/1072 sets out this framework for SMS verification codes:
- Staff first explain clearly what the SMS is for and what giving the code means. The SMS also includes a channel for further information.
- Membership approval, permission to process data and consent to commercial electronic messages (the Turkish legal term for marketing messages) are not collected with a single code. A separate option is offered for each processing activity that needs explicit consent.
- Consent to commercial messages is not presented as a condition of the sale. It is either requested after the sale is complete, or the message states clearly that the code is optional, that the sale will go ahead even without the code, and that preferences can be changed at any time.
- Staff involved in these processes receive regular training.
In other words, the verification code must have a single purpose. Sample text (translated from Turkish): "[BRAND]: Your code to approve using your loyalty card at the [Store] till is 482913. Valid for 3 minutes. Share it only if you approve this transaction. Info: [short link]" Turkish characters can change the number of message segments, and therefore the cost, so test with your provider.
Expiry, attempt and cost limits
According to OWASP's guidance on multifactor authentication, sending SMS messages costs money, and attackers may request large numbers of messages to drain your budget. SMS is also exposed to SIM swaps, lock-screen previews and malicious apps. The controls we recommend:
- The code is generated and verified on the server. It is short-lived and single-use, is never stored in plain text and never appears in logs.
- A limit on wrong attempts, and a waiting period before a code can be resent.
- Hourly limits per number, per till and per store, plus an alert when one till requests codes for different numbers one after another.
- A threshold alert on the daily SMS budget. If the service is also used on the web and in the app, rate limiting and bot protection on those endpoints.
Sender IDs, a backup provider and consent records are the job of your multi-channel messaging infrastructure. Keep verification SMS in a separate flow from marketing sends.
App QR code: static barcode or TOTP?
The decision lists a barcode or QR code in the app or on the website. It does not distinguish between static and dynamic codes, and it does not require the code to be "dynamic". However, someone can take a screenshot of a static barcode and share it. If you want to close this gap, there is an established standard: the time-based one-time password (TOTP) in RFC 6238. The code is renewed using a secret key on the device and the clock; the recommended default time step is 30 seconds. Verification happens on the server, a limited tolerance is allowed for clock drift, and the same code is never accepted twice. The cost is key distribution and a renewal flow for reinstalled apps. Designing this into the mobile app from the start is cheaper than patching it in later. If you choose a design where customers scan a QR code in the store, also take into account KVKK's warning about quishing (QR code phishing).
How should you design the opt-in screen, and what about customers without a phone?
The member gives the opt-in in their online account. There, they choose which of earning points, discounts/promotions and spending points can be done with the number alone. Design the screen in line with principle decision 2026/347. The privacy notice (aydınlatma metni) and the explicit consent (açık rıza) text are presented under separate headings, with separate declarations. For the privacy notice, you ask the member to confirm they have read it, not to approve it. The language is plain. If the processing relies on a legal basis other than explicit consent, you only provide the privacy notice. Clarify the legal nature of the opt-in with your legal team: is it a preference under the contract, or explicit consent? Our recommendations for the screen:
- A separate switch for each transaction type, all off by default.
- A one-sentence risk note next to each switch: "If you turn this on, anyone who knows your number can do this at the till."
- Turning a switch off is as easy as turning it on. Every change is recorded with a timestamp, and the member is notified.
- Marketing consent does not appear on this screen.
Alternatives for different customer groups
KVKK states that alternative mechanisms can be offered to take account of differences such as age, level of education, economic situation and technology literacy. For a member without a smartphone, the simplest route is a physical card. For a member whose basic phone can receive SMS, it is an SMS code. If you choose a PIN, the member does not say it to the cashier but enters it on the device themselves. The PIN is not stored in plain text; it is stored with a salted, slow hashing algorithm. Short PINs are easy to guess, so the number of wrong attempts is limited too. Stay away from face or fingerprint verification: under Article 6 of Law No. 6698, biometric data is special-category personal data. Processing it is prohibited and is only possible if one of the conditions listed in that article applies.
Complying with the KVKK loyalty card decision: audit trail and a 120-day plan
A minimum audit trail
KVKK's Personal Data Security Guide considers it necessary to record the transaction activity of all users regularly (for example, as log records). The guide's table of technical measures also includes an authorisation matrix, access logs, data masking and key management. The minimum fields we recommend for the verification service:
- Time; store, till, cashier and basket IDs
- The member's pseudonymous ID and masked number
- Transaction type, method, result (success, wrong code, timeout, offline, anonymous sale), number of attempts
- Version of the opt-in preference applied; document number, if any
The code itself and the full number are never written to the log. Define access through your authorisation matrix, and the retention period through your data destruction policy.
A step-by-step plan from 31 October 2026 to 28 February 2027
- Days 1–15, inventory: List every point where the number alone opens a transaction (store and franchise tills, e-commerce, call centre). Approve the matrix and start work on the legal texts with your legal team.
- Days 16–60, development: The verification service, mandatory tokens in the CRM, the SMS template and limits, the QR code, the opt-in screen, anonymous sales and logs.
- Days 61–90, pilot store: At peak hours, measure the time verification adds at the till, the SMS delivery time and the rate of failed verifications. Cut the connection on purpose to test the offline flow. Cashier training is finalised at this stage.
- Days 91–120, rollout: Roll out in groups of stores, monitor the indicators every day and leave a buffer before the deadline.
Vendors: Under Article 12(2) of Law No. 6698, if another party processes the data on your behalf, you are jointly responsible with them for the security measures. Review your till, CRM, app and SMS contracts. If you use off-the-shelf software, ask your vendor:
- Which verification methods do you support, and do you support the opt-in preference?
- If verification fails, are writes to points, the profile and documents blocked?
- Do you have SMS limits, a budget alert and an exportable audit trail?
How Partnerfy can help
We start a project like this at the till. In a pilot store, we observe the peak hour and map what the number, the card and the QR code write to which systems today. We then build the verification service as an API layer that is independent of the till software, and we tie the rule to the write point in the loyalty/CRM system. That way, different till versions and franchises all follow the same rule. On the SMS side, we set up limits, a backup provider and consent records with Turkish providers such as NetGSM, Verimor and İletimerkezi, and we build the QR and opt-in screens in the app. We do not write the legal texts; we place the texts your lawyer has approved correctly into the screens and templates. To discuss the scope, get in touch with us or take a look at our approach to API integration.
Sources
- Official Gazette, 28 February 2026, Issue 33182: principle decision 2026/266 (in Turkish)
- KVKK: Announcement of the loyalty card principle decision (in Turkish)
- Official Gazette, 13 August 2026, Issue 33339: decision 2026/1491 (in Turkish)
- KVKK: Announcement on the extension of the compliance period (in Turkish)
- KVKK: Principle decision 2025/1072 on SMS verification codes (in Turkish)
- KVKK: Announcement of principle decision 2026/347 (in Turkish)
- KVKK: Announcements and Principle Decisions lists (in Turkish)
- Law No. 6698 on the Protection of Personal Data (in Turkish)
- Law No. 5326 on Misdemeanours (in Turkish)
- KVKK: Personal Data Security Guide, April 2025 (in Turkish)
- OWASP: Multifactor Authentication Cheat Sheet
- IETF RFC 6238: TOTP
- GİB (Revenue Administration): About the e-Arşiv Fatura (in Turkish)
- KVKK: The risk that comes with QR codes: quishing (in Turkish)