Türkiye Bans Under-15s From 1 November and Hands You an Age Token. Here's What Your Platform Has to Build.

Most age-check laws tell the platform to run the check. Türkiye’s new rule does something different. The state runs the check and hands the user a token. The platform’s job is to accept it.

That sounds easier. It isn’t, and the start date is 1 November 2026. This post covers what the rule says, what you have to build, and what the reports still leave unclear.

What the rule says

I’m working from news reports and one English translation, not from the Turkish text. Sources are Biometric Update, MediaNama, PPC Land and a legal summary from the law firm Pekin Bayar Mizrahi. The translation has drafting errors, so check the details with a Turkish lawyer before you act.

The reported facts:

• The Presidency of Cybersecurity published the regulation in the Official Gazette (the government’s journal of new rules) on 10 October 2026. PPC Land gives the issue number as 33396.
• It starts on 1 November 2026. Parliament passed the underlying law in April 2026.
• It covers Turkish and foreign social media providers that people in Türkiye can reach. The reports mention no minimum user count.
• Providers may not serve anyone under 15. Users aged 15 to 17 get a restricted service.
• New accounts need a government age token from 1 November. Existing accounts must be checked by 31 March 2027.

On penalties, I could not confirm the numbers. Only The Next Web reports fines of up to 3% of global revenue, advertising bans and cuts to internet bandwidth. PPC Land and the Pekin summary say the regulation sets no fine amounts. They point to Additional Article 4 of Law No. 5651, Türkiye’s 2007 internet law. All of them agree that platforms get notice and a reasonable chance to fix a breach first. The Pekin summary adds that the regulator weighs how serious the breach is, how many children it affects and whether you acted in good faith.

The state does the check

Here is how the token works, as reported.

1. The user logs in to e-Devlet, Türkiye’s e-government portal.
2. The user asks for an age token.
3. The user uploads the token to your platform.

The token says only two things: whether the user is over 15, and whether the user is over 18. It carries no name and no exact age. That’s good for privacy, and it matches the approach we described in double anonymity. PPC Land points out one open question: the text doesn’t say whether the Presidency logs token requests. If it does, someone could link a token back to a person. That risk sits with the state, not with you.

Your job changes. You no longer collect a selfie or a document. You build four things:

• Intake. A screen where the user adds the token, in the sign-up flow and in the existing-account flow.
• Validation. Code that confirms the token is real and unused.
• Storage. A small record: the result (under 15, 15 to 17, 18 or over), the date, and nothing else.
• Binding. A link between that result and one account.

I haven’t seen the technical specification for the token. I don’t know its format, how you check its signature, or how long it stays valid. Ask the Presidency or your legal counsel for it. Don’t design the validation step until you have it.

Five account states, one policy table

The token gives you two thresholds. Your product needs more states than that, because existing accounts have until 31 March 2027. A new user with no token is blocked. An old user with no token is not, yet.

State	What you know	Treatment
New, no token	Nothing	Cannot create an account
Existing, no token	Nothing, deadline pending	Keep access, prompt for a token
Under 15	Token says under 15	No service
15 to 17	Token says over 15, not over 18	Restricted service
18 or over	Token says over 18	Full service

Write the rules as one table in code. Then no feature can quietly ignore it. The reported teen limits are private accounts by default, no personalised ads, no live streaming, no endless scrolling feeds, no contact sync and messaging only with accounts the teen follows.

type Account =
  | "new_no_token" | "existing_no_token"
  | "under_15" | "teen_15_17" | "adult_18";
type Feature =
  | "sign_up" | "public_profile" | "live_stream"
  | "personalised_ads" | "algorithmic_feed" | "contact_sync";

export const ALLOWED: Record<Account, Record<Feature, boolean>> = {
  new_no_token:      { sign_up: false, public_profile: false, live_stream: false, personalised_ads: false, algorithmic_feed: false, contact_sync: false },
  existing_no_token: { sign_up: false, public_profile: true,  live_stream: true,  personalised_ads: true,  algorithmic_feed: true,  contact_sync: true  },
  under_15:          { sign_up: false, public_profile: false, live_stream: false, personalised_ads: false, algorithmic_feed: false, contact_sync: false },
  teen_15_17:        { sign_up: true,  public_profile: false, live_stream: false, personalised_ads: false, algorithmic_feed: false, contact_sync: false },
  adult_18:          { sign_up: true,  public_profile: true,  live_stream: true,  personalised_ads: true,  algorithmic_feed: true,  contact_sync: true  },
};

Add a test for the rules that matter most. A later edit must not weaken them.

const TEEN_BLOCKED: Feature[] = ["live_stream", "personalised_ads", "algorithmic_feed", "contact_sync"];

test("a 15 to 17 account never gets the blocked features", () => {
  for (const f of TEEN_BLOCKED) expect(ALLOWED.teen_15_17[f]).toBe(false);
});

test("an under-15 account gets nothing", () => {
  expect(Object.values(ALLOWED.under_15).some(Boolean)).toBe(false);
});

One detail: the existing_no_token row is temporary. Put the end date, 31 March 2027, in config, not in the table. When it passes, that state should stop existing.

Visitors have a different token

Some users are in Türkiye for a short time and have no e-Devlet login. MediaNama and PPC Land report that they can get a separate token using passport details. PPC Land calls it an exceptional token. The reports don’t explain how misuse of it is prevented.

Treat it as a second intake path with the same output: a result and a date. Don’t store the passport data. If you serve tourists, test this path, because it will be the least used and the most broken.

A token is not a person

The token proves that someone logged in to e-Devlet and asked for it. It doesn’t prove that the person holding your app is that someone. A parent can fetch a token and give it to a 12-year-old. An older sibling can do the same.

The regulation seems to expect this. It reportedly requires providers to run their own age assurance after sign-up and to suspend an account on reasonable suspicion. The suspended user must verify again before the account comes back. We covered the general problem in binding verification to the right person.

“Reasonable suspicion” has no definition in the reports. Pick signals you can defend, and write them down. Examples: a teen-pattern device, a school-hours usage pattern, or a user report. Then pick the recheck you run. A weak signal gets a light recheck. A strong signal gets a harder one. Keep a record of why you suspended each account. You may have to show it.

The back-book: 31 March 2027

The back-book is every account you already have. The reported deadline is 31 March 2027, about five months after the start date.

Here is a model. The numbers are my assumptions, not Xident customer data.

• 600,000 existing accounts in Türkiye.
• 150 days from 1 November to 31 March.
• If you ask everyone at once, 600,000 token requests land in the first week.

Spread across the period, that’s 4,000 accounts a day. Send prompts in waves, starting with the accounts most likely to be under 15 or most active. Leave time at the end for appeals.

What happens to under-15 accounts is reported as follows: the provider notifies the user, closes the account, and deletes the data unless an appeal starts. The Pekin summary says an account that misses the deadline is closed or moved to the restricted service. It also says content and personal data can’t be deleted while an appeal is open. Our post on back-book remediation covers the deletion steps in more detail. One caution: don’t delete on a timer. If an appeal is open, hold the data.

Appeals are part of the rule

The reports say every provider must offer a free appeal against an age decision, a suspension or an account closure. A person must review it, not only software. The appeal has to work in Turkish. Providers must also report appeal statistics to the Presidency each year and publish them on their own site. The Pekin summary lists application and appeal numbers, acceptance rates and average time to a decision.

So build the appeal flow now, not after the first complaint. Count four numbers from day one: appeals received, appeals upheld, time to a decision, and appeals by decision type. Our appeals guide has a working design.

What is still unclear

Some parts of the rule are hard to build to, and the reports don’t settle them.

Screenshot blocking. The rule reportedly says platforms must use technical measures to block screenshots of teen content. On Android, an app can set a flag that stops screenshots inside it. On the web, you can’t block them. On iOS, an app can detect a screenshot after it happens, not stop it. I haven’t seen what the regulator accepts. Ask before you spend months on this.

“Addiction” and feed rules. The reports say endless scroll, autoplay and algorithmic feeds are banned for teens. The word “addiction” isn’t defined, and it’s unclear what a lawful feed looks like. A chronological list with a page limit is the safest guess. It’s a guess.

Advertising. Personalised ads are banned for 15 to 17 year olds, with no parental override. Whether customer-list matching and ad measurement count is not clear from the English text.

Where Xident fits

The state token is the main path for Turkish users, and Xident doesn’t replace it. This post doesn’t claim that Xident reads or validates e-Devlet tokens. That intake is your own integration.

Xident helps in the gaps around the token. A Check runs in the browser and estimates an age band (+12, +15, +18, +21 or +25). The +15 and +18 bands match the two Turkish lines. So a Check can be your light recheck when you have reasonable suspicion about a token-verified account. A user near the line can escalate to a document Verification. The result comes back to your server as a decision you can act on. The same flow serves your markets that have no state token.

Xident doesn’t block screenshots, run your appeals team or decide what counts as reasonable suspicion. Facial estimation also has an error range of a few years, so it’s a good first filter and a poor final judge for someone aged 14 or 15. We explained the buffer in estimation near the age line. The pricing page has the current terms, and the docs show how to start a Check from your own code.

Before 1 November: six checks

1. Get the token specification. Ask the Presidency or your counsel for the format, signature and validity rules.
2. Build intake and storage. Store the result and the date. Don’t store the token longer than you need to validate it.
3. Block new sign-ups without a token for Türkiye, and make the policy table the single source of truth.
4. Switch on the teen rules for 15 to 17 accounts: private by default, no personalised ads, no live streaming, no algorithmic feed, no contact sync.
5. Plan the back-book in waves, and put 31 March 2027 in config.
6. Open the appeals flow with a human reviewer who reads Turkish, and start counting.

If your team already works on other under-16 rules, compare notes with our UK policy table and the Malaysia guide. The age line differs. The structure is the same.