Industry Standards To Fight Fraud Might Be A Double-Edged Sword

"Data-Driven Thinking" is written by members of the media community and contains fresh ideas on the digital revolution in media.

Today’s column is written by Salah Shami, senior director of product at Bidtellect.

It’s not news that leaders in the digital advertising industry have expressed concern over the prevalent challenges with fraud, brand safety and transparency. In response, industry bodies such as the IAB and the Trustworthy Accountability Group (TAG) have developed specific compliance guidelines and standards for companies throughout the digital supply.

For example, the IAB released the Ads.txt guidelines, and TAG has developed various programs, particularly around malware and fraud. Many in the industry on both the buy and sell sides have announced general compliance and enforcement. It is great to see adoption on the rise, with power players setting the stage around the new norm, thereby increasing the importance of falling in line.

While I greatly applaud and see tremendous value in the introduction of industry standards, simply following these guidelines is not enough to move the industry forward in cleaning up the ecosystem and eliminating fraud. Unfortunately, many companies believe that simply complying with these initiatives is sufficient.

There are still a number of gaps, even in the most recent iteration of the Ads.txt guidelines, released last month. Keep in mind that, at the time of writing, there is barely 13% adoption across the top 1,000 domains, and the app space still left wide open. Announcing compliance now is no different than bragging to the rest of the class that you did the homework everyone is expected to complete.

Ads.txt’s Fundamental Shortcomings

To put Ads.txt into perspective, let’s revisit what it does. Domain X sells inventory to supply-side platform (SSP) Y. Demand-side platform (DSP) Z buys inventory from Y. So, when Z checks X’s Ads.txt file, all looks good and the impression is served.

But non-premium domains can still spoof themselves as premium domains. Publishers, which deal with larger SSPs, may not properly vet the inventory they’re onboarding. SSPs may not even be verifying these domains as they put together the RTB request. With so much changing hands, simply creating a tool that allows buyers to ask sellers if they know an agent isn’t enough. And with Ads.txt files being public, motivated spoofers just need to ensure that their stories line up with what’s been published.

We Must Be Proactive, Not Reactive

With the emergence of fraudulent behaviors that question the integrity of advertising, some brands have begun to lose consumer trust. And as we’ve seen for many years, bad actors and fraudsters will continue to find new ways of gaming the system. Therefore, it is vital that technology companies not turn a blind eye to the deeper challenges the industry faces. Instead of only complying with existing industry initiatives, those that do more will be in the best position to offer safe environments.

For example, participating in these industry initiatives and integrating with leading third-party vendors such as Integral Ad Science should be table stakes and not considered “leading the charge.” Companies that view these efforts as enough will be vulnerable.

More than just developing “proprietary methodologies” – a term heard all too often that actually discourages sharing – we should actively facilitate open dialogue between all players, sharing what we’ve learned. It’s critical that DSPs and SSPs work together to be a part of the solution, not simply hope that someone else is taking care of it. Did the domain of the RTB request match the domain of the impression? Are these flagged impressions coming from the same IP? Where is this central repository so that the industry can share, reference and take action against these learnings?

When you look at it like that, it becomes clear that Ads.txt is no more than simple baseline guidance. Compliance around a larger industry initiative does not mean that we shouldn't be actively exploring other ways in which we can cut off fraudsters, even if that means we have to work in smaller, more tactical groups to take them down while we wait for meaningful guidance.

Make no mistake, this is not, by any means, intended to undercut the importance of taking the right steps, though once again, there’s still a lot to be done. If we really feel strongly about bringing around change, we must remain proactive. Future iterations of Ads.txt and RTB guidelines should hit fraudsters where it hurts: their pockets.

How do we ensure that Domain X is getting credit for what DSP Z bought? When we figure that out, spoofing a domain will carry no value.

This doesn’t guarantee that the problem will not move elsewhere. However, it is this kind of thinking that can put us on the offensive instead of simply playing defense.

Follow Bidtellect (@Bidtellect) and AdExchanger (@adexchanger) on Twitter.

5 Comments

  1. Salah, I'm not sure I follow your statement that "non-premium domains can still spoof themselves as premium domains. " That's true, but how do these non-premium domains get their account ID listed in the premium domain's ads.txt file in order to get paid for the spoofing?

    Reply
    • Ian Trider

      Or, more precisely, any DSP respecting ads.txt and not bidding on unauthorized sources will not bid on a source not listed, therefore they will not bid on the spoofed inventory -- it is not coming from an SSP account that the publisher lists as authorized. At that point, the fraudster can generate as many bogus impressions as they want -- ads.txt respecting DSPs will not buy them.

      I would like to know more about the specific scenario that there is concern for. It certainly seems like ads.txt defends against the majority of cases of domain spoofing.. provided that the DSP wishes to respect the data.

      Reply
  2. Salah, Sounds like you should get involved in the standards process and bring some new use-cases.

    Ads.txt was intended to solve one clearly defined problem, the misrepresentation of inventory on the open market allowing unauthorized entities to get paid.

    It's up to buyers such as yourself to innovate with the data provided.

    Ads.txt is step 1 of N steps to add authorization framework data to the supply chain, not the final step.

    However at current implementation rates it's may be the fastest adopted IAB standard in years despite the cries that it is not a silver bullet to solve all use cases of ad fraud.

    Reply
    • Salah Shami

      I certainly welcome the opportunity to share and discuss what we’ve personally observed. I completely understand that ads.txt is only one piece of the solution to a giant problem, and as stated, I applaud & support this being the first major step of many. In fact, our company, under my management, has already implemented the appropriate protocol and we are sifting through the data, further demonstrating our support for all initiatives that contribute to a safer ecosystem for advertisers.

      However, my intention was to 1) call attention to the fact that some are touting compliance as a differentiator, whereas for me, I consider it table stakes and 2) to your point, remind others of the fact that this is not a silver bullet.

      I’ve personally sorted through the top 100 mismatches and am particularly frustrated with the fact that even those who’ve rushed to adoption have made basic errors in their implementation. We’ve begun the dialogue to have the right people correct this, domain & SSP alike, though back to my main point, everyone’s so eager to announce adoption but how many have done it correctly?

      Reply
  3. Salah, you should read the spec and tell us how non-premium domains can spoof themselves as premium domains. You can't spoof the ID in the domain's ads.txt file.

    Reply

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>