The Short Version

TCF v2.3 is an evolution of v2.2, not a re-architecture. The TC String format is compatible, existing purposes and features are preserved, and most publisher-facing UI requirements carry over unchanged. The meaningful changes concentrate in four areas:

• Clearer rules on how CMPs must present vendor information and retention periods.
• New requirements for granular second-layer controls that regulators have been demanding since the 2022 Belgian DPA decision.
• Tightened policy enforcement around dark patterns, equal prominence, and pre-ticked options.
• Adjustments to the Global Vendor List (GVL) schema and the vendor disclosure flow.

Why v2.3 Exists

Every TCF version is a negotiation between three audiences: publishers who need to keep monetizing, vendors who need a stable technical interface, and regulators who keep finding specific compliance gaps. v2.3 is a direct response to three pressures:

1. Enforcement actions against "legitimate interest" overuse under v2.2. Several European DPAs held that too many vendors were claiming LI for purposes where only consent was actually lawful. v2.3 tightens the vendor-declared legal basis disclosures and surfaces them earlier in the consent UI.
2. Ongoing complaints about dark patterns. The updated Policies make the equal-prominence rule more explicit and close loopholes around pre-ticked toggles on the second layer.
3. Operational feedback from large CMPs and publishers. v2.2 introduced several required disclosures that were difficult to implement cleanly on mobile and CTV. v2.3 streamlines the mandatory disclosure set and allows more of it to live in a layered view.

TC String Compatibility

The TC String itself remains backwards compatible. A v2.3 CMP produces strings that v2.2 vendors can read, and a v2.3 vendor can consume v2.2 strings during the transition period. The version indicator in the string's core segment identifies which policy version the CMP is claiming compliance with, and the GVL version pointer moves forward independently.

What this means practically: you do not need to rev every vendor at the same time, and you do not need to force a fresh consent event on every user the day you deploy v2.3. A phased rollout is explicitly supported.

Key Technical Changes

1. Vendor Disclosure and Retention

v2.3 requires CMPs to surface each vendor's declared data retention period in the layered UI, not only in a separate vendor list. The retention value has always been part of the GVL, but v2.2 did not mandate that users see it alongside purposes. v2.3 closes that gap because regulators argued users could not make an informed choice without knowing how long their data would persist.

2. Stricter Second-Layer Controls

On the second layer — the "manage preferences" view — v2.3 is explicit that toggles for non-essential purposes and vendors must default to off. Pre-ticked boxes or pre-enabled sliders are a policy violation even if the user never explicitly clicks "accept." CMPs that previously relied on a "soft opt-in" pattern will need to re-render the second layer.

3. Equal Prominence Enforcement

The equal prominence rule has existed since v2.1, but v2.3 defines it with less room for interpretation: the "reject all" control must be at the same layer, same visual weight, same color contrast class, and same interaction distance as "accept all." Hiding reject behind a link, a smaller button, or a secondary screen is now an explicit compliance failure rather than a judgment call.

4. Legitimate Interest Signalling

Vendors that declare legitimate interest as a lawful basis under v2.3 must now also declare which purposes they have assessed and for which they have completed a Legitimate Interests Assessment. CMPs are required to pass this declaration through to the user interface so that users can object with full information. In practice this means the "object" flow now shows vendor-specific LIA status rather than a generic toggle.

5. GVL Schema Updates

The Global Vendor List schema adds fields for retention granularity, LIA status, and a machine-readable link to each vendor's privacy policy section for the declared purposes. CMPs that cache the GVL must refresh their schema parser to understand the new fields before pointing at a v2.3 GVL.

Policy Changes That Affect UX

The TCF is both a technical spec and a set of Policies. Several of the v2.3 Policy changes land directly on the consent UI:

• No more "continue without accepting" as the reject equivalent unless it visually matches the accept button and produces the same TC String as a full reject would.
• Language parity — the consent notice must be available in every language that the site itself is available in, not only the user's browser language. CMPs must support locale override.
• Persistent access — users must be able to reach the preferences center from every page of the site, not only the landing page, and the access link must be labeled in a way that a non-expert user would recognize as consent-related.

What Publishers Must Do

1. Confirm your CMP vendor's v2.3 support. Ask for the exact date their v2.3-certified build will be available and the version string it will report.
2. Refresh your GVL cache logic. If you self-host any GVL mirror, update the schema parser before the v2.3 GVL rolls out, or your CMP will fail to validate new vendors.
3. Rewrite your second-layer UI so that every toggle defaults to off, equal prominence is visually enforced, and retention periods are displayed alongside purposes.
4. Re-run your compliance audit. The easiest regulatory wins are dark-pattern violations that v2.3 now calls out explicitly. Fix them before your next enforcement review.
5. Plan a re-prompt strategy. While the TC String is backwards compatible, the Policies encourage publishers to re-seek consent when the scope or disclosure of processing changes materially. Decide whether your v2.3 rollout qualifies as "material" for your audience.

What Vendors Must Do

1. Complete a Legitimate Interests Assessment for every purpose where you declare LI, and submit the result to the GVL.
2. Update your GVL entry with the v2.3 schema fields: retention granularity, LIA declaration, and the privacy-policy deep link.
3. Validate your TC String parser against the v2.3 reference strings provided by IAB Europe.
4. Coordinate with your CMP partners on a shared cutover date, so that the first buyer request carrying a v2.3 string does not land on a v2.2-only vendor.

Common Migration Pitfalls

• Treating v2.3 as a UI redesign opportunity. It is tempting to bundle brand updates with the v2.3 rollout, but doing so complicates compliance testing. Ship a compliance-only v2.3 release first, then iterate on design.
• Missing the retention display requirement. Teams often update the vendor list view but forget that retention now has to appear in the purpose-by-purpose layered view as well.
• Assuming the TC String is enough. A compliant string produced by a non-compliant UI is still non-compliant. Regulators have repeatedly fined operators whose strings looked fine but whose banners hid the reject button.
• Leaving CTV and mobile out of scope. v2.3 applies to every surface where TCF signals are produced. Publishers who ship a web update and ignore their CTV or mobile apps create a hybrid non-compliant environment.

Conclusion

TCF v2.3 is not a disruptive break with v2.2, but it is a meaningful tightening of the rules that hold the European programmatic ecosystem together. The direction of travel is clear: more transparency, fewer dark patterns, more granular user control, and less tolerance for the edge cases that used to slip through. CMPs and publishers that treat v2.3 as a quick patch will find themselves right back in front of the regulator. Those that use the migration to clean up second-layer UX, retire legitimate-interest shortcuts, and rebuild a real equal-prominence consent flow will come out the other side with inventory that actually clears in the v2.3 era — and a consent posture that will survive whatever v2.4 brings next.