GDPR, TCF and Consent Strings: What a DSP Must Handle in Europe

Every programmatic ad bought in Europe starts with a question most buyers never see: did this person agree to have their data used for advertising, and by whom? The answer travels inside the bid request as a short encoded text called a consent string. If a DSP cannot read it, it is guessing.

Guessing is expensive. A DSP that bids on personal data without a valid legal basis exposes itself, its clients and its supply partners to regulatory risk under the GDPR. A DSP that ignores consent signals in the other direction, and simply stops bidding in Europe, gives up some of the most valuable inventory in the world. The right answer sits in between, and it is mostly an engineering problem.

This guide explains how the GDPR applies to programmatic buying, what the IAB Europe Transparency and Consent Framework (TCF) is, what is inside a TCF consent string, how that string reaches a DSP in an OpenRTB bid request, and the checks a DSP must run before it bids. It is practical guidance, not legal advice.

Why the GDPR Matters to Programmatic Buyers

The General Data Protection Regulation came into force on 25 May 2018. It applies whenever a company processes personal data of people in the European Union, and in the programmatic world almost everything counts as personal data: cookie IDs, mobile advertising IDs, IP addresses and precise location are all identifiers that can single out a person or a device.

A second law sits next to it. The ePrivacy Directive covers storing or reading information on a user’s device, which is exactly what a cookie or a device ID lookup does. In practice that means a DSP usually needs consent before it can read or set its own cookie on a European user’s browser, even before it does anything else with the data.

For a buyer, this creates three practical questions on every European impression:

• Does the GDPR apply to this request at all?
• Has the user agreed to the specific uses the DSP wants, such as building profiles or measuring results?
• Has the user agreed to this particular company, the DSP itself, processing their data?

What Is the IAB Europe Transparency and Consent Framework?

The Transparency and Consent Framework is a voluntary standard run by IAB Europe. It gives publishers, technology vendors and consent tools one common way to describe what data is used for, who uses it, and what the user said about it. IAB Europe describes three groups of participants:

• Publishers: the owners of the sites and apps where data is collected.
• Vendors: third-party companies such as ad servers, measurement providers, agencies, SSPs and DSPs.
• Consent Management Platforms (CMPs): the tools that show the consent banner, record the user’s choices and turn them into a consent string.

Vendors register on the Global Vendor List (GVL), a public list maintained by IAB Europe. Each registered vendor gets a numeric ID and declares which purposes it processes data for and on which legal basis. As of November 2026 the official list holds more than 1,200 registered vendors. When a user makes a choice in a consent banner, the CMP records it against those vendor IDs.

TCF v2.2 launched on 16 May 2023. In April 2025 IAB Europe launched TCF v2.3, which makes the Disclosed Vendors section of the consent string mandatory to resolve an ambiguity around legitimate interest. Participants had until 28 February 2026 to adopt v2.3, so any DSP buying European inventory today should expect v2.3 strings.

The TCF Purposes a DSP Should Know

The TCF does not ask a user one yes-or-no question. It splits data use into standard purposes, each with a fixed number and name. A DSP declares which ones it needs, and the consent string records the user’s answer for each. These are the eleven purposes on the official Global Vendor List:

Next to these, the TCF defines special purposes that do not need consent, such as ensuring security and preventing fraud, and delivering and presenting ads. It also defines special features that need a separate opt-in, the most relevant being the use of precise geolocation data.

Each purpose rests on a legal basis: either consent or legitimate interest. Since TCF v2.2, purposes 3 to 6, the profiling purposes, can only rely on consent. For a DSP that runs audience targeting or retargeting, this is the single most important rule: no consent for purposes 3 and 4, no personalised bid.

What Is Inside a TCF Consent String?

The TCF consent string, also called the TC string, is a compact encoded text that the CMP creates after the user makes a choice. Decoded, the core part of the string contains:

• Metadata: the TCF version, when the string was created and last updated, the CMP’s ID, the consent language and the version of the Global Vendor List used.
• Purpose consents: one yes or no for each purpose the user was asked about.
• Purpose legitimate interests: whether the user was shown, and did not object to, legitimate interest processing for each eligible purpose.
• Special feature opt-ins: for example, whether precise geolocation may be used.
• Vendor consents and vendor legitimate interests: a yes or no for each vendor ID on the list.
• Publisher restrictions: rules the publisher set for specific vendors, such as requiring consent where a vendor would otherwise use legitimate interest, or blocking a purpose altogether.

Under TCF v2.3 the string also carries a Disclosed Vendors segment, which lists the vendors that were actually shown to the user in the consent notice. That lets a vendor tell the difference between “the user objected to me” and “the user was never told about me”.

The key point for buyers: a consent string is two-dimensional. A DSP needs the purpose to be allowed and its own vendor ID to be allowed. A user can agree to personalised advertising in general but reject one specific DSP, and the string records both answers.

How the Consent String Reaches the DSP

The consent string moves through the supply chain alongside the ad request. The usual path looks like this:

1. The user visits a site or opens an app, and the CMP shows a consent notice.
2. The user makes a choice, and the CMP stores it as a TC string, usually in a first-party cookie or app storage.
3. When an ad slot loads, the publisher’s ad stack reads the string and passes it to the SSP.
4. The SSP adds it to the OpenRTB bid request it sends to every connected DSP.
5. The DSP decodes the string, checks its own permissions and decides how, or whether, to bid.

In the OpenRTB bid request, two fields carry the signal. OpenRTB 2.6 has a native regs.gdpr field, set to 1 when the GDPR applies and 0 when it does not, and a native user.consent field that holds the TC string itself. Older OpenRTB 2.5 integrations put the same values in extensions, as regs.ext.gdpr and user.ext.consent, so a DSP connected to many supply partners should read both locations. Our guide to the anatomy of a bid request shows where these objects sit in the full request.

Some partners also send a Global Privacy Platform (GPP) string in regs.gpp and regs.gpp_sid. GPP is an IAB Tech Lab container that can hold the TCF string next to other regional signals, so a DSP should extract the TCF section and apply the same logic.

The string does not stop at the DSP. Ad tags and tracking pixels can receive it through standard macros, such as ${GDPR} for the applies flag and ${GDPR_CONSENT_XXX} for the string, where XXX is the vendor ID of the company being called.

The Checks a DSP Must Run Before It Bids

All of this happens inside the bidding window, which is usually a few dozen to a few hundred milliseconds, as described in our guide to how real-time bidding works. The consent logic must be fast, predictable and the same for every request. A sound DSP runs these checks in order:

1. Does the GDPR apply? Read the gdpr flag. If it is 1, consent rules apply. If it is missing on traffic from an EU country, treat the request as if the GDPR applies.
2. Is the string present and valid? A missing, empty or broken string means no consent. Do not use personal data.
3. Is the DSP’s vendor ID allowed? Check the vendor consent and vendor legitimate interest sections for your own ID.
4. Are the needed purposes allowed? Check purpose 1 before reading the user’s cookie or device ID, purposes 3 and 4 before using audience segments, and purpose 7 before measurement.
5. Do publisher restrictions change anything? Apply any restriction the publisher set for your vendor ID before acting on the vendor and purpose answers.
6. Is a special feature needed? Only use precise geolocation if that special feature opt-in is set.

The result should not be a simple bid or no-bid. A well-built DSP picks one of these modes per request:

The contextual mode is worth building well. Many European users refuse personalised advertising, and buyers who can still bid on context and format keep reaching that inventory. Our article on cookieless advertising covers the targeting options that still work without user-level data.

Common Consent Mistakes in DSPs

Most consent problems are small engineering shortcuts, not legal misunderstandings. The common ones:

• Checking purposes but not the vendor. The user said yes to personalised ads, but not to your company. Using the data is still not allowed.
• Syncing user IDs without purpose 1. Cookie syncs and ID lookups count as accessing the device. They need purpose 1 and vendor consent first.
• Treating a missing string as consent. When the GDPR applies and no string arrives, the safe default is no personal data.
• Reading only one OpenRTB location. Some partners send regs.gdpr, some send regs.ext.gdpr, some send GPP. Read all of them.
• Using an old vendor list. Refresh your copy of the Global Vendor List on a schedule.
• Dropping the string downstream. If creatives and trackers do not receive the string through macros, they cannot make their own decision, and the buyer carries that risk.
• Not logging the decision. If a regulator or partner asks why a user’s data was used, you need the consent state that applied at the time of the impression.

The same discipline applies to data you bring into the platform. If you connect a DMP to your DSP, audience segments should only be activated on requests where the consent string allows profiling for your vendor ID.

Where Regulators and Courts Stand

The TCF is a self-regulatory standard, not a law, and regulators have examined it closely. In March 2024 the Court of Justice of the European Union ruled in a case involving IAB Europe that a TC string can be personal data when it can be linked to an identifier such as an IP address. So the string itself deserves the same care as other user data.

For a DSP owner, the practical lesson is simple. The TCF gives you a shared language, not a legal shield. Agree your role in each data flow with qualified legal advice, document your consent logic, and make sure the platform behaves as documented.

What Changes When You Own the DSP

When you buy through someone else’s platform, their consent logic decides how your campaigns behave in Europe, and you often cannot see why European reach is lower than expected.

When you own the platform, consent becomes something you can configure and audit:

• You decide how strict the no-consent default is, and whether contextual bidding runs on requests without profiling consent.
• You can report European reach by consent state, so clients understand why an audience campaign scales differently in France than in Brazil.
• You control how long consent records and logs are kept, and who can access them.
• You choose which supply partners to connect based on how cleanly they pass gdpr flags and consent strings.

AdTech Europe’s DSP includes a Consent Management and TCF module that integrates with the IAB Transparency and Consent Framework to manage consent signals across GDPR regions, so targeting and measurement follow both advertiser and publisher permissions.

Ready to Run Consent-Ready Buying on Your Own DSP?

AdTech Europe supplies demand-side platform technology to agencies, ad networks, media buying teams and adtech entrepreneurs who want to own their buying stack instead of renting one. The platform runs under your own brand and domain, reads consent signals from connected supply, and keeps the bidding rules in your hands.

As of November 2026, you can rent the DSP for $500 a month (monthly plans carry a one-time setup fee equal to one month) or $5,000 a year, license it for $25,000 once or in 12 payments, or own the complete source code for $50,000. Current figures in every supported currency are on the pricing page, and the White Label DSP page shows the branded option. To plan a European setup around your clients and supply, schedule a programmatic strategy meeting with our team.

FAQs

What is a TCF consent string?

A TCF consent string, or TC string, is an encoded text created by a consent management platform after a user makes a privacy choice. It records which purposes and which vendors the user allowed, and it travels with ad requests so every company in the chain can check it.

Where is the consent string in an OpenRTB bid request?

In OpenRTB 2.6 it is in the user.consent field, with the regs.gdpr field set to 1 when the GDPR applies. Older OpenRTB 2.5 integrations use user.ext.consent and regs.ext.gdpr. Some partners also send it inside a GPP string in regs.gpp.

What should a DSP do if there is no consent string?

If the GDPR applies and no valid string arrives, the DSP should not use personal data. That means no user IDs, no audience segments and no cookie syncs. Depending on its legal advice, it may skip the request or bid only on non-personal signals.

Which TCF purposes does a DSP need for retargeting?

Retargeting uses profiles, so it needs consent for purpose 3, create profiles for personalised advertising, and purpose 4, use profiles to select personalised advertising. It also needs purpose 1 to read the user’s cookie or device ID, plus consent for the DSP’s own vendor ID.

What is the current version of the TCF?

The current version is TCF v2.3, launched by IAB Europe in April 2025. It makes the Disclosed Vendors section of the consent string mandatory. Participants had until 28 February 2026 to adopt it.

Is the TCF required by law?

No. The TCF is a voluntary industry standard run by IAB Europe. The GDPR and the ePrivacy Directive are the laws. The TCF is a shared way for companies to collect, pass and respect consent so they can meet those laws at auction speed.

Can a DSP still bid without personalised advertising consent?

Often, yes. If the DSP’s vendor ID is allowed but profiling purposes are refused, it can bid using limited data such as the site, app, ad format and coarse location. This contextual bidding keeps European reach while respecting the user’s choice.