TCF string is not a TCF 2 core string
user.consent, or a GPP section that should be TCF (sids 2 and 5), is not a TCF 2 core string (starts with C, long enough, TCF alphabet).
What it means
TCF 2.x core strings start with C (version bits = 2). TCF 1 started with B. The core segment must be long enough to hold the required bit fields, and only A-Z a-z 0-9 - _ . appear. This check is shape, not a full vendor-bit decode.
Why it matters
A malformed consent string is worse than none: CMPs and DSPs that try to decode it error out, and the bid is skipped rather than run as non-personalized.
How to fix it
Take the string from a TCF 2.2 CMP. Do not put "yes", a US Privacy string, or a TCF 1 string in user.consent.
Example that trips it
{ "user": { "consent": "yes" } }Check your payload
Paste a bid request or response into the tester to see whether this code fires against it, or gate on the id in CI with the CLI: the id is stable, wording is not.
Back to the full diagnostic code reference.