Blog · Privacy
DSA transparency in OpenRTB: where enforcement stands in 2026
Two years after the EU Digital Services Act became fully applicable in February 2024, the harmonized transparency reporting rules for online platforms took effect in mid-2025, and the first reports under that framework were published in February 2026. The ad-tech side of DSA compliance runs through a single OpenRTB community extension: regs.ext.dsa on the request and bid.ext.dsa on the response. Here is what the extension actually asks for, and what is and is not verifiable about who enforces it.
What the DSA requires, in ad-tech terms
Article 26 of the Digital Services Act requires online platforms to disclose, for every ad shown to a user in the EU, who the ad was for, who paid for it, and (for very large platforms) meaningful information about the targeting parameters used to select it. That disclosure has to be populated at serve time, which means the data has to travel through the bid stream, not get attached after the fact. IAB Tech Lab published a community extension for this in January 2024, stewarded by its Global Privacy Working Group in partnership with IAB Europe, which provides policy-level implementation guidance while Tech Lab maintains the technical spec.
The request shape: regs.ext.dsa
The extension sits under regs.ext.dsa in a 2.6 request. It has not been promoted to a first-class Regs field, so unlike gpp or gdpr it stays inside ext and is versioned separately from OpenRTB itself.
dsarequired(integer): whether the publisher expects a DSA transparency object on the bid response, detailed in the table below.pubrender(integer): the publisher's capability and intent to render the transparency notice to the user. 0 means the publisher cannot render it, 1 means the publisher could render it depending on the buyer'sadrendervalue, and 2 means the publisher will render it regardless.datatopub(integer): controls whether transparency data should be sent back to the publisher independent of who renders it, from 0 (do not send) to 2 (send transparency data).transparency(array): one object per entity applying targeting parameters, each with adomainstring and adsaparamsinteger array (for example, 1 for profiling, 2 for basic advertising, 3 for precise geolocation).
| dsarequired | Meaning |
|---|---|
| 0 | Not required. No DSA object expected on the bid response. |
| 1 | Supported. Bid responses with or without a DSA object will both be accepted. |
| 2 | Required. Bid responses without a DSA object will not be accepted. |
| 3 | Required, and the publisher is itself an Online Platform under the DSA. Bid responses without a DSA object will not be accepted. |
Full field paths for this and every other regulatory signal in a 2.6 request are on privacy signals in OpenRTB.
The response shape: bid.ext.dsa
A compliant bid answers back with its own bid.ext.dsa object: behalf (up to 100 characters naming who the ad is displayed on behalf of), paid (up to 100 characters naming who paid for it, required even when it matches behalf), its own transparency array describing which parameters the buy side applied, and adrender (0 or 1) indicating whether the buyer will render the notice itself. When dsarequired is 2 or 3, a bid response missing this object is non-compliant and, per the spec's own language, should not be accepted.
What dsarequired means operationally
In practice dsarequired is the field that turns a legal obligation into a bidding decision. A value of 2 or 3 means a bidder that cannot populate bid.ext.dsa should not bid at all on that impression, since the response will be rejected regardless of price. A value of 0 or 1 means the extension is informational for that request. The dsarequired: 3 case, where the publisher itself is an Online Platform under the DSA, is the strictest: it applies to large publisher-side platforms with their own direct Article 26 obligations, distinct from an SSP or ad network passing traffic through on their behalf.
Who requires it now
What is verifiable publicly: the DSA has applied in full since February 17, 2024, an EU Implementing Regulation standardizing transparency reporting templates took effect July 1, 2025, and the first reports under that harmonized format were published in February 2026. IAB Europe has run an ongoing call for industry adoption of the OpenRTB DSA extension and published implementation guidance for it. What is not independently verifiable from public sources is a complete list of which specific European exchanges or SSPs currently reject bid responses lacking bid.ext.dsa at the transaction level; that behavior is a per-platform bidding policy, not something the DSA regulatory text or the OpenRTB extension itself mandates as universal. If you operate in EU traffic, the reliable way to find out is to check what your specific demand or supply partners send and require, not to assume industry-wide enforcement uniformity.
What to check in your own requests
Confirm regs.ext.dsa.dsarequired is present and correctly typed as an integer 0-3 on EU traffic, that pubrender and datatopub are set to values your rendering pipeline actually matches, and that every transparency entry carries a real domain rather than a placeholder. On the bid side, verify behalf and paid are populated whenever dsarequired is 2 or 3, since an empty or missing value there is the most common way a compliant-looking bid gets rejected downstream. Run a sample request and response pair through the bid request tester or the CLI to catch type mismatches and unknown keys under ext.dsa before they show up as silent bid loss.