openrtb.field.moved
What it means
The field exists in the version you validated against, but at a different path. The 2.6 promotions are the big ones: regs.ext.gdpr became regs.gdpr, user.ext.consent became user.consent, and source.ext.schain became source.schain.
Why it matters
A consumer built for this version reads the new path only. Data sent at the old location is silently ignored, so whatever it governs never takes effect. For the privacy fields that can mean EU traffic with no visible consent signal, which buyers must treat as consent absent.
How to fix it
Write the value at the path this finding names as the replacement. While you still serve partners on older versions, populate both paths with identical values, and retire the old one when those integrations upgrade.
Example that trips it
{ "regs": { "ext": { "gdpr": 1 } } }On 2.6 the flag lives at regs.gdpr; a 2.6-native buyer never sees this one.
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.