Wiki · Concept · Last reviewed June 25, 2026

Transparency and Consent Framework

The Transparency and Consent Framework is IAB Europe's consent-signaling framework for digital advertising: a way for publishers, CMPs, vendors, and advertisers to communicate disclosure, legal-basis, and user-choice signals.

Category: Concept / Ad Tech Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: TCF, IAB Europe, consent, TC String, CMP, real-time bidding, privacy

Definition

The Transparency and Consent Framework, or TCF, is a voluntary framework maintained by IAB Europe with technical specification work stewarded by IAB Tech Lab. Its purpose is to help online advertising participants communicate information about device access, personal-data processing, declared purposes, legal bases, vendors, and user choices under the GDPR and ePrivacy Directive.

The TCF is not itself a privacy law and does not automatically make an advertising practice lawful. It is infrastructure: policies, technical specifications, a Global Vendor List, consent management platform rules, and a Transparency and Consent String, usually called a TC String. It turns a user-interface event into a machine-readable signal that advertising systems can read.

The useful definition is therefore narrow: TCF standardizes how certain adtech actors declare, request, store, and transmit transparency and choice information. It does not prove that the notice was understandable, that consent was freely given, that all downstream vendors obeyed the signal, or that later AI training, profiling, memory, or enrichment uses share the same legal basis.

How It Works

A publisher or app operator presents a consent interface, often through a consent management platform, or CMP. The CMP asks the user about purposes, features, vendors, and legal bases, then packages the resulting signals into a TC String. The CMP API lets scripts and vendors request that data without manually unpacking the encoded payload.

The Global Vendor List provides a shared table of registered vendors and declarations. The TC String can signal which vendors were disclosed, which purposes were accepted or rejected, and which legal-basis choices the publisher or CMP says apply. This matters in Real-Time Bidding because many parties may receive or act on advertising requests after the banner is gone.

In web implementations, the CMP API uses the __tcfapi interface so scripts can query status and TC data. The governance point is not the JavaScript name; it is the dependency chain. A publisher, CMP, vendor tag, ad exchange, demand-side platform, and measurement vendor may all act on the same encoded preference artifact while each remains responsible for its own legal basis, disclosure, contractual limits, and actual processing behavior.

Current Status

As of this June 25, 2026 review, IAB Europe says TCF v1.1 launched in April 2018, followed by v2.0, v2.1, v2.2, and v2.3. Its TCF page says participants had until February 28, 2026 to adopt v2.3, which made the disclosed-vendors section mandatory in the TC String to address vendor-disclosure ambiguity.

The IAB Europe policy page reviewed for this entry identifies version 2026-05-29.5.0.b. It sets policies for CMPs, vendors, publishers, and framework user interfaces, and says applicable law prevails if law and TCF policies conflict.

The legal record is not just industry documentation. In March 2024, the Court of Justice of the European Union ruled in Case C-604/22 that a TC String can constitute personal data when it can be associated with an identifier, and addressed when IAB Europe may be a joint controller. In May 2025, the Belgian Data Protection Authority said the Market Court confirmed that the TC String is personal data and that IAB Europe acts as joint controller for processing user preferences within the TCF, while rejecting the DPA's broader conclusion that IAB Europe controls processing that occurs entirely within OpenRTB.

Evidence Boundary

A TCF record has three layers. The first is the user-facing event: what the person saw, in which language, with which defaults, vendors, purposes, buttons, and withdrawal path. The second is the signal: the TC String, CMP ID, Global Vendor List version, policy version, timestamp, jurisdiction, and publisher restrictions. The third is downstream conduct: which vendors actually received data, read or stored identifiers, bid, measured, profiled, trained, enriched, or forwarded the information.

Compliance evidence is weak if it preserves only the second layer. A TC String can show that a system recorded a choice, but it cannot by itself show that the interface met GDPR consent standards, that the ePrivacy storage/access rule was satisfied, that the Global Vendor List was accurate, or that vendors stopped processing after refusal or withdrawal.

The CJEU and Belgian DPA record also sets a boundary for controller claims. The TC String may be personal data, and IAB Europe may be a joint controller for processing preferences within the TCF. That does not mean IAB Europe is automatically controller for every downstream OpenRTB or adtech processing operation unless influence over the purposes and means of that later processing is established.

Governance and Safety

The TCF makes adtech consent claims more inspectable. It creates named purposes, vendor declarations, CMP responsibilities, policy versions, and encoded signals that can be audited. Without such structure, downstream actors can claim permission without preserving a readable trail.

The risk is mistaking the signal for consent itself. Valid consent still depends on the screen, wording, defaults, granularity, withdrawal path, power relationship, vendor disclosure, and actual data flow after the choice. A technically valid TC String can coexist with a manipulative banner or downstream processing that exceeds what the person understood.

IAB Europe's own policies reinforce that the framework is bounded: participants must follow applicable privacy and data-protection law; vendors should not create signals where no CMP signal exists; and contractual obligations can override more permissive signals. For governance, those rules matter because consent signaling is also a supply-chain problem. The control has to survive scripts, redirects, server-side bidding, data clean rooms, measurement pixels, and vendor-to-vendor forwarding.

AI systems intensify the boundary problem. Models may support ad targeting, fraud detection, dynamic creative optimization, or audience enrichment. That does not mean a TCF signal authorizes unrelated model training, memory, profiling, agent access, or data brokerage. AI reuse should be mapped as a separate processing purpose with its own legal basis, notice, retention limit, vendor controls, deletion route, and proof that refusal changes behavior.

Defense Pattern

Source Discipline

Use IAB Europe for policy status and framework claims. Use IAB Tech Lab or the official GitHub repository for technical specifications. Use CJEU and Belgian DPA sources for legal claims.

For consent doctrine, cite GDPR text and EDPB guidance rather than industry materials. For device storage and access, distinguish GDPR personal-data processing from ePrivacy cookie or terminal-equipment rules. For interface claims, preserve the actual banner and flow; a technical string without the screen is not enough.

Do not say that TCF compliance equals GDPR compliance, that a TC String is "just metadata," or that IAB Europe controls all OpenRTB processing. Also do not use a TCF source to prove that a vendor's AI training, audience enrichment, or model-improvement use was authorized unless that source names the purpose, vendor, legal basis, and actual downstream processing at issue.

Spiralist Reading

Spiralism reads the TCF as the moment consent becomes logistics.

The user sees a banner. The market sees a transportable permission artifact. The moral question is whether the artifact still carries the person's understanding, or only the industry's need for a signal that machines can move.

Open Questions

Sources

Return to Wiki