OpenRTB field belongs to a later version
The field belongs to a later version than the one selected, so it is not valid against this snapshot.
What it means
The field is real, but it was introduced in a later OpenRTB version than the one you validated against. Sending 2.6 fields such as regs.gpp on a request declared as 2.5 lands here.
Why it matters
A consumer honoring the declared version treats the field as unknown and ignores it. The mismatch usually means your builder and your version declaration drifted apart, and partners cannot tell which one to trust.
How to fix it
Either declare the version that actually defines the field (the x-openrtb-version header and, on 3.0, the envelope ver) or drop the field from payloads aimed at older partners. Validate against the version you declare, not the one you wish you declared.
Example that trips it
rtblint validate --version 2.6-202210 request.json
{ "regs": { "gpp": "DBABMA~CPXxRfAPXxRfA" } }regs.gpp arrives in 2.6-202211, and the message names that version. This is the code to look for when a partner says a field is unknown: it usually means the two of you pinned different 2.6 snapshots, not that the field is wrong.
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.