--- title: What is Ads.cert, and how can it reduce ad fraud in programmatic? description: What is the IAB Tech Lab's ads.cert initiative, and how can it help programmatic buyers and sellers reduce ad fraud and invalid traffic ('IVT')? Pixalate explains ads.cert and details how it acts as a complement to the existing ads.txt initiative. image: https://www.pixalate.com/hubfs/Blog_Media/Blog%20photos/ads-cert-reduce-ad-fraud-cover.png --- [![pixalate-full-logo](https://www.pixalate.com/hs-fs/hubfs/Pixalate_Logos/pixalate-full-logo.jpg?width=150&height=60&name=pixalate-full-logo.jpg "pixalate-full-logo")](https://www.pixalate.com) Search **Menu** ** ** ![](https://www.pixalate.com/hubfs/Blog_Media/Blog%20photos/ads-cert-reduce-ad-fraud-cover.png) [Thought Leadership](https://www.pixalate.com/blog/topic/thought-leadership) | 6 min read # What is Ads.cert, and how can it reduce ad fraud in programmatic? Written by [Tyler Loechner](https://www.pixalate.com/blog/author/tyler-loechner) Jun 20, 2018 11:16:50 AM Ad fraud and invalid traffic (“IVT”) can take on many forms, but falsified information in the bid request is one of the most common challenges. The IAB’s upcoming ads.cert initiative aims to address such challenges by creating a validated, public chain of command. If you think of a programmatic ad transaction as a huge game of telephone — in which many different players have access to the message from Point A to Point Z — ads.cert essentially allows the final player (the buyer) to validate the original message with the first player (the seller). Pixalate fully supports the IAB’s ads.cert initiative and we intend to keep you apprised on adoption trends and all future related ads.cert news. ![ads-cert-and-ads-txt](https://www.pixalate.com/hs-fs/hubfs/Blog_Media/Blog%20photos/ads-cert-and-ads-txt.png?width=600&name=ads-cert-and-ads-txt.png) ### **Now that you get the gist of ads.cert, here’s some more detailed information** Ads.cert is part of the OpenRTB 3.0 framework, which, in the IAB Tech Lab’s own words, is focused on “secure supply chain standards.” The IAB says the [OpenRTB 3.0 framework](https://iabtechlab.com/wp-content/uploads/2017/09/OpenRTB-3.0-Draft-Framework-for-Public-Comment.pdf) “is the largest overhaul of the OpenRTB protocol since its inception in 2010,” and that “[t]he purpose of this major update is to meet the market’s demand for security, transparency, authentication, and trust in programmatic advertising.” One of the major changes in the new protocol is “a signed supply chain to enable the demand side to validate many of the fields in the bid request and to have a clear chain of custody.” Those signed bid requests are what people refer to when they say “ads.cert.” Here is the IAB tech Lab’s document that goes into “Signed Bid Requests” in greater detail. Think of it as a complement to the existing ads.txt initiative, which has seen [widespread adoption](https://blog.pixalate.com/iab-ads-txt-q1-2018-trends-report) since it launched in the summer of 2017. Ads.cert is meant to complement ads.txt — not replace it. ### **Why does ads.txt need a complement, and how does ads.cert help?** Ads.txt was designed to reduce “spoofing” in the open programmatic marketplace for desktop display advertising. Spoofing is when one site (often a lesser-known site) pretends to be a different site (often a well-known site) in order to increase the perceived value of the inventory they sell. But ads.txt has limitations. - **Ads.txt validates sellers; it does not validate the inventory** While ads.txt does validate that certain sellers are authorized to sell certain publishers’ ad inventory, it does not validate any information about the inventory itself. When an impression is traded in the open programmatic marketplace, all sorts of data points are shared with the buyer. Many buyers decide whether or not to buy the inventory (and for how much) based on some of these factors. Some of the data points shared include: - Ad Type (i.e. video versus display) - IP Address (can be cross-referenced against blocklists) - Device (i.e. smartphone, tablet, laptop, etc.) - Browser (i.e. Chrome, Safari, Firefox, etc.) - Location (i.e. where the user is located) How ads.cert helps: Ads.cert validates the inventory via a signed “chain of custody” report. This means buyers will be able to check ads.txt to confirm the publisher on which the inventory is available and use ads.cert to confirm certain data points about the inventory. - **Ads.txt doesn’t guard against display-to-video arbitrage** ![ads-cert-display-video-arbitrage](https://www.pixalate.com/hs-fs/hubfs/Blog_Media/Blog%20photos/ads-cert-display-video-arbitrage.png?width=600&name=ads-cert-display-video-arbitrage.png) This is more of a subset of the section above, but it’s worth highlighting on its own since it’s a common issue in the digital display marketplace. Because ads.txt does not validate the ad type, resellers can take a display impression and sell it as a video impression. Here’s what MediaPost [wrote](https://www.mediapost.com/publications/article/315703/how-the-300x250-became-the-most-common-and-frau.html) on display-to-video arbitrage in a recent article, citing [research](https://blog.pixalate.com/in-banner-video-ad-unit-programmatic-invalid-traffic-mediapost-openx-pixalate) from Pixalate in conjunction with OpenX: *"The blocky 300x250 banner ad has long been one of the most common ad units in the display advertising marketplace, but thanks to some ingenuity, cunning and outright fraud, it has also become one of the most common video advertising units sold via programmatic ad exchanges."* ### **How ads.cert validates inventory: Keys, signatures, and ‘messages’** Ads.cert will introduce a few new words to the programmatic ad industry’s dictionary, including “keys,” “signatures,” and “messages.” - **What are ‘messages’ in ads.cert?** The IAB Tech Lab uses the term “message(s)” to refer to OpenRTB bid requests. We will use the same terminology. The message contains information about the inventory, such as device type, ad type, IP address, browser, operating system, and more. The IAB notes that each message “needs to have something unique (a random message identifier) to the message to prevent reuse of the message and signature by a downstream system.” - **What are ‘signatures’ in ads.cert?** The ads.cert initiative asks publishers (or a designated partner; more on that below) to “sign” the message in order to validate the information included in the message. The signature is created by stringing together all field values for a given request. The IAB shares the following example: ![iab-tech-lab-signature-example-ads-cert](https://www.pixalate.com/hs-fs/hubfs/Blog_Media/Blog%20photos/iab-tech-lab-signature-example-ads-cert.png?width=600&name=iab-tech-lab-signature-example-ads-cert.png) The guidelines note: *“For the sample values in the table, the input string into the signature would be as follows:* *ABC7E92FGD6A;12345678;newsite.com;;192.168.1.1;;* *That string would be used to create the signature string which would be inserted into ps (in the case of generating the request) or checked against the value that is received in ps (in the case of validating the request).”* - **What are ‘keys’ in ads.cert?** **Public key: **Per the IAB, publishers are required to make a public key file accessible via HTTP and/or HTTPs (similar to how ads.txt works). The IAB adds: “Note that the public key must be secured yet accessible to be read by outside systems to validate the messages against the signatures.” The public key will be used by buyers to confirm the message (e.g. confirm the inventory). **Private key: **The private key is encrypted and should only be accessible to the publisher (or designated partner), as it is needed to generate and sign messages. ### **Ads.cert: How messages, signatures, and keys all work together to authenticate programmatic ad inventory** ![ads-cert-how-it-works](https://www.pixalate.com/hs-fs/hubfs/Blog_Media/Blog%20photos/ads-cert-how-it-works.png?width=600&name=ads-cert-how-it-works.png) When a publisher has an available ad impression, the publisher/SSP will build the bid request (“message”), create the signature based on the information in that message, and sign it using the private key. As noted by the IAB, “No downstream system can make changes in the signed fields.” The advertiser/DSP can then use the domain’s public key to authenticate the message. Per the IAB, this can be done in real-time or offline. ### **Either the publisher or a single delegated authority has to sign the message** The IAB notes that there are two ways in which messages can be signed: 1. “The publisher uses a self-hosted software system to create the message and signature, then providing both to the approved advertising system listed in the ads.txt file” or 2. “The publisher designates a single primary advertising system to create and sign the messages. This system then provides the message and signature to all advertising systems listed in the ads.txt file.’ In both scenarios, the IDs and domains can be validated via ads.txt while the message and signatures can be validated via ads.cert. ### **Ads.cert requires OpenRTB 3.0 support and is still in a period of public comment; Pixalate will track its progress** It should be noted that of this writing, the ads.cert initiative is still in a period of public comment. Additionally, ads.cert will require OpenRTB 3.0 support. Furthermore, as of the IAB’s September 2017 framework, ads.cert did not fully support mobile in-app because “signatures are not fully supported due to the lack of a reliable method to retrieve the public key since there is no known domain.” The ads.txt initiative faced a similar issue within the mobile app ecosystem, but the IAB appears to be making progress in this area: In early June 2018, the IAB Tech Lab [released its first guidance](https://iabtechlab.com/press-releases/iab-tech-lab-seeking-feedback-for-mobile-app-support-for-ads-txt/) for the use of ads.txt within mobile apps. When the ads.cert initiative is officially released, Pixalate intends to track its adoption. *Want more data-driven insights? Sign up for our blog! * ### Search Blog Search ### Follow Pixalate ### Subscribe to our blog *By entering your email address and clicking Subscribe, you are agreeing to our [Terms of Use ](https://www.pixalate.com/terms)and [Privacy Policy.](https://www.pixalate.com/privacypolicy) Previous Story [← Pixalate Week in Review: June 11 - 15, 2018](https://www.pixalate.com/blog/programmatic-ad-fraud-news-week-in-review-june-15-2018) [** ](https://www.pixalate.com/blog) Next Story [Webinar: Reducing IVT in Mobile Apps →](https://www.pixalate.com/blog/how-to-reduce-ivt-mobile-apps-webinar-panel) ## You May Also Like These Stories on Thought Leadership [![](https://www.pixalate.com/hubfs/Q%26A%20with%20Krush%20Media%20-%20cover.png) ](https://www.pixalate.com/blog/krush-media-qa) [Case Studies](https://www.pixalate.com/blog/topic/case-studies) ### [Q&A with Steven Slaughter, Head of Ad Ops & Yield at Krush Media, on managing a clean CTV and Mobile Ad Supply Chain](https://www.pixalate.com/blog/krush-media-qa) Jun 27, 2023 12:00:00 PM | 4 min read [![](https://www.pixalate.com/hubfs/Q%26A%20with%20Screencore%20-%20cover.png) ](https://www.pixalate.com/blog/screencore-qa) [Case Studies](https://www.pixalate.com/blog/topic/case-studies) ### [Q&A with Jess Okan, Co-founder and CEO of Screencore, on strategies for minimizing ad fraud in the connected TV ecosystem](https://www.pixalate.com/blog/screencore-qa) May 30, 2023 7:00:00 AM | 6 min read [![](https://www.pixalate.com/hubfs/Oleksandra%20Kazantseva.png) ](https://www.pixalate.com/blog/bizzclick-qa) [Case Studies](https://www.pixalate.com/blog/topic/case-studies) ### [Q&A with Oleksandra Kazantseva, Head of Programmatic at BizzClick, on transparency, trust, and security](https://www.pixalate.com/blog/bizzclick-qa) Apr 17, 2023 2:00:00 PM | 4 min read ** ### Subscribe to our blog *By entering your email address and clicking Subscribe, you are agreeing to our [Terms of Use ](https://www.pixalate.com/terms)and [Privacy Policy.](https://www.pixalate.com/privacypolicy) ![pixalate-logo-red-small](https://www.pixalate.com/hs-fs/hubfs/2018NewTemplate/pixalate-logo-red-small.png?width=208&name=pixalate-logo-red-small.png "pixalate-logo-red-small") ** By entering your email address and clicking Subscribe, you are agreeing to our [Terms of Use](https://www.pixalate.com/terms) and [Privacy Policy](https://www.pixalate.com/privacypolicy) Products [Analytics](https://www.pixalate.com/products/analytics) [Blocking](https://www.pixalate.com/products/blocking) [Media Rating Terminal](https://www.pixalate.com/products/mrt) [Publisher Trust Indexes](https://www.pixalate.com/rankings/?group=app&reportId=publisherTrustIndex) [Seller Trust Indexes](https://www.pixalate.com/rankings/?group=app&reportId=publisherTrustIndex) [IoT Device Rankings](https://www.pixalate.com/rankings/?group=app&reportId=iotDeviceReach) Resources [Blog](https://blog.pixalate.com/) [Press](https://www.pixalate.com/press) [Careers](https://www.pixalate.com/jobs) [Team](https://info.pixalate.com/pixalate-leadership-team) Contact Email [** sales@pixalate.com ](mailto:sales@pixalate.com) [** privacy@pixalate.com ](mailto:privacy@pixalate.com) US: [** +1 888 749 2528 ](tel:+1%20888%20749%202528) EU: [** +44 (0)800 011 2050 ](tel:+44%20(0)800%20011%202050) Slack: [Join ATSAPI Slack Channel ](https://atsapi-pixalate.slack.com/join/shared_invite/zt-10dtow5cj-OEtlNr5yzJkrZMQUqcEEow#/shared-invite/email) Offices Global Offices US 1775 Greensboro Station Place, Suite 425, McLean, VA 22102 UK 20 North Audley Street London, W1K 6WE, United Kingdom EU 10 Earlsfort Terrace Dublin 2, D02 T380, Ireland Singapore 10 Anson Road, #22-02 International Plaza, Singapore 079903 [![facebook](https://www.pixalate.com/hubfs/footer/icons/facebook.png) ](https://www.facebook.com/pixalate) [![x](https://www.pixalate.com/hubfs/footer/icons/twitter-x.png) ](https://twitter.com/pixalateinc) [![linkedin](https://www.pixalate.com/hubfs/footer/icons/linkedin.png) ](https://www.linkedin.com/company/pixalate) ![wechat](https://www.pixalate.com/hubfs/footer/icons/wechat.png) [![slack](https://www.pixalate.com/hubfs/footer/icons/slack.png) ](https://atsapi-pixalate.slack.com/join/shared_invite/zt-10dtow5cj-OEtlNr5yzJkrZMQUqcEEow#/shared-invite/email) [Terms of Use](https://www.pixalate.com/terms) [Privacy Policy](https://www.pixalate.com/privacypolicy) [GDPR Compliance](https://www.pixalate.com/gdpr) Disclaimer Copyright © 2025 Pixalate [Back to top **](https://www.pixalate.com/blog/ads-cert-explainer-reduce-ad-fraud#) # Disclaimer Disclaimer: The content of this page reflects Pixalate’s opinions with respect to the factors that Pixalate believes can be useful to the digital media industry. Any proprietary data shared is grounded in Pixalate’s proprietary technology and analytics, which Pixalate is continuously evaluating and updating. Any references to outside sources should not be construed as endorsements. Pixalate’s opinions are just that - opinion, not facts or guarantees. Per the MRC, “'Fraud' is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes. Also per the MRC, “‘Invalid Traffic’ is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.” ** ** *By clicking Download and entering your email address, you are agreeing to our [Terms of Use](https://www.pixalate.com/terms) and have read and acknowledge our [Privacy Policy](https://www.pixalate.com/hubfs/2024-08-20_Pixalate_Privacy_Policy.pdf). *Copyright © 2025 Pixalate** * * * * * * * * * * * * * * * * * * * * * * * * * * * * × ## Subscribe to the Pixalate Blog The first step in ad fraud prevention. Loading... By entering your email address and clicking Submit, you are agreeing to our [Terms of Use](https://www.pixalate.com/terms) and [Privacy Policy](https://www.pixalate.com/privacypolicy). ![pixalate-logo-white](https://www.pixalate.com/hubfs/Blog_V2_08_26_2016/logo/Pixalate_Logo_WHITE.png) ##### Contact Us12 Loading... ![pixalate-logo-white](https://www.pixalate.com/hubfs/Blog_V2_08_26_2016/logo/Pixalate_Logo_WHITE.png) ##### Download GSTI Loading... Schedule your demo today Please complete all fields Loading... By entering your email address and clicking Submit, you are agreeing to our [Terms of Use](https://www.pixalate.com/terms) and [Privacy Policy](https://www.pixalate.com/privacypolicy). * * * * *