The Global Vendor List (GVL) is the official, machine-readable registry of every adtech vendor participating in IAB Europe's Transparency and Consent Framework. Each vendor has a numeric ID, a declared set of processing purposes, and a declared legal basis for each purpose. Every consent banner operating under the TCF builds its vendor screen from this list, and every TC string references vendors by their GVL IDs.

What the GVL contains

The list is published by IAB Europe as a JSON file that CMPs fetch and cache. For each vendor it records:

  • ID and name: the stable numeric identifier used in TC strings (for example, Google advertising products appear under vendor ID 755).

  • Purposes: which of the standardised TCF purposes the vendor processes data for, split into purposes requiring consent and purposes claimed under legitimate interest.

  • Special features and special purposes: capabilities such as precise geolocation that require their own opt-in.

  • Device storage disclosures and retention: what the vendor stores on the device and for how long - a disclosure requirement tightened in TCF v2.2.

  • Privacy policy URL per declared language.

How often the list changes

IAB Europe publishes GVL updates weekly. Vendors join, leave, or change their declarations, and each published list carries a version number - the same version number your CMP embeds in the TC strings it creates. That coupling matters: a TC string that references vendor consents is only meaningful against the vendor list version it was built from.

This is also why consent needs periodic refreshing. A visitor who consented against last year's list has never seen this year's new vendors, so their old string cannot cover them - one of several reasons a TC string gets rejected downstream.

Why publishers should care about vendor count

Nothing forces a publisher to enable every vendor on the list, and enabling all of them is a compliance liability: regulators have repeatedly criticised banners asking for consent to hundreds of vendors as incompatible with informed consent. Practical guidance:

  • Curate: enable only vendors your ad stack actually uses. Your SSP or ad network can tell you which vendor IDs they require.

  • Restrict: TCF lets publishers impose per-vendor purpose restrictions, recorded in the TC string's publisher restrictions segment.

  • Audit: periodically compare the vendors you enabled against the third parties that actually load on your pages. A cookie scan and a vendor risk assessment catch drift in both directions.

How CMPs consume the list

Operationally, the GVL is a versioned JSON document that CMPs download, cache, and ship to the browser in trimmed form. Three implementation details matter to publishers:

  • Caching rules: IAB Europe requires CMPs to respect the list's publication cadence rather than hammering the endpoint - which means a vendor added on Thursday appears in banners only after the CMP's next list refresh, not instantly.

  • Language versions: vendor names and purpose texts exist in every supported banner language; the CMP must serve the visitor's language, and the TC string records which language was shown.

  • Trimming: a well-configured CMP sends the browser only the vendors the publisher enabled, not the full registry - one of the easiest wins for banner load performance.

Legal weight: the list is not a shield

A recurring misunderstanding is that enabling a GVL vendor outsources responsibility for it. It does not. The Belgian DPA's enforcement against IAB Europe established that participants in the framework carry their own accountability, and publishers remain jointly responsible for the processing they trigger on their pages. The GVL gives you standardised declarations to rely on - purposes, retention, storage disclosures - but choosing WHICH vendors to enable, and being able to justify that choice, stays with you. That is why the curation advice above is a compliance point, not just a UX one.

A worked curation example

A mid-size publisher running Google Ad Manager plus two SSPs typically needs: vendor 755 (Google Advertising Products), the two SSPs' own vendor IDs, their measurement provider, and whatever their header-bidding wrapper requires - usually a list of ten to twenty vendors, not four hundred. The workflow: ask each monetisation partner for their required GVL IDs, enable exactly those, run a cookie scan after a week to catch anything loading without a matching vendor entry, and repeat the audit quarterly. Every vendor you do not enable is one less name on the banner, one less declaration to review after list updates, and one less liability to explain.

The GVL and Google

Google's advertising products participate in the TCF as GVL vendors, but Google also maintains its own Additional Consent mechanism for ad partners that never registered with IAB Europe. If you monetise with AdSense or Ad Manager, you will encounter both - our guides to Google Additional Consent and AdSense cookie consent explain how they fit together.

Inspecting vendor consents in practice

To see exactly which vendor IDs a given consent string covers, paste it into the free TCF String Decoder - it lists per-vendor consent and legitimate-interest flags and shows publisher restrictions. If you are still choosing a consent platform for a TCF setup, our CMP comparison checklist covers the questions worth asking, and this guide helps you decide whether you need TCF at all.