Fraud is one of the most prevalent issues in the ad-tech industry. As quickly as technology evolves to fight it, fraudsters are adapting new techniques to continue their ill-intentioned campaigns.

While the industry has enjoyed recent success in tackling specific types of fraud such as unauthorised arbitrage and domain spoofing via the launch of the IAB’s ads.txt initiative, both advertisers and publishers must be wary of being lulled into a false sense of security, believing that ads.txt is a silver bullet that will banish ad fraud to the history books.

While ads.txt is a step in the right direction, it is just a starting point, and has several limitations. We will only get closer to defeating ad fraud when we move on from the current mechanism — which simply lists authorised vendors of inventory — to one that authenticates all partners working along the digital supply chain.

What ads.txt gets right

There is no denying that digital advertising needs ads.txt — and after initial fears over low adoption, DoubleClick figures indicate the scheme is well-supported, with files published on over 100,000 domains. There are two key reasons for this strong uptake. First, it is a remarkably simple idea – with publishers using an ads.txt file to list who is permitted to sell their inventory, directly or as a reseller — and second, it is very cheap to implement.

Widespread adoption of the initiative is bringing greater transparency to the digital media supply chain, helping to build trust and developing good relationships between publishers, networks, ad-tech providers and advertisers. Google sees the wide adoption of ads.txt as a major contributor to the increase in the value of inventory passing through its network, and we are noticing a similar pattern in the form of an 8.3% increase in RPM (revenue per thousand impressions) for publishers that have implemented the protocol.

Ads.txt is helping publishers exert control over content and curtail domain spoofing, as well as rogue operators dishonestly selling arbitraged inventory. Fraudsters misrepresenting lo- quality sites in a bid to fool advertisers and networks into thinking they are buying high-quality impressions are finding the going a lot tougher.

What else is needed?

As with the majority of new initiatives, there are a few drawbacks to ads.txt. Anyone involved in publishing will testify it is a manual process, which is prone to inaccuracies such as simple spelling mistakes. It is worrisome that around 18% of the Top 1000 Alexa sites’ ads.txt files have errors. Because of the high risk of human error, publishers must continually monitor for inconsistencies or partner with monetisation experts who can ensure ads.txt files are correctly implemented.

In addition to the human error factor, there is also a gaping omission in the ads.txt system, which cannot go unnoticed. Ads.txt might authorise vendors, but it does not authenticate the site, or other third parties involved in the bidding process. It is a little like visiting a Rolex dealer who is authorised to sell the famous watch brand but cannot provide proof the watch itself is genuine.

Before placing a bid, buyers receive information from the publisher that can include domain name, user location, device type, ad unit, and on-page placement. It is here that fraudsters can still strike, editing details to make inventory appear far more valuable than it is by misrepresenting the website or placement where the ad will appear, or pretending a standard display space is designed for a more expensive medium, such as video. The latter con is widespread and relies on ads.txt files failing to specify the types of media a vendor is authorised to sell, leaving room to game the system.

What is ads.cert?

Although currently still under development, ads.cert is the next evolution of ads.txt, which aims to address this issue by moving toward an authenticated supply chain. It uses cryptography to track the path of an inventory request from the originating publisher to their advertising platform, filtering through an open network before reaching the server delivering the ad back to the original publisher, providing an audit path from the beginning of the process to the end.

Ads.cert offers protection by encouraging all parties in the chain to add their digital signature and certificate to identify themselves. This means if a third party edits any part of the ad request, they must verify their legitimacy, and their change will be recorded for all to see. They may, for example, be an ad-tech company providing proof of the site’s performance on viewability and fraud.

New standards to fight fraud

Ads.cert is a much-needed addition to ads.txt, but it can only work with the IAB’s Open RTB 3.0 standard, a major update to the Open RTB protocol,  devised to tackle fraud and ensure transparency and trust in programmatic advertising. However, the 3.0 standard is not backwards compatible and cannot, therefore, protect legacy networks.

Advertising networks, as well as supply-and-demand platforms, will need to pay to upgrade to 3.0 so, although adoption is crucial, we are unlikely to see this on a mass scale any time soon. Because the success of ads.cert depends on its adoption rate, hopefully ads.txt will be a starting point that leads publishers to embrace the authentication of ads.cert, and networks and advertising platforms to upgrade to the Open RTB 3.0 standard.

Although things are moving in the right direction for reputable, premium publishers and the advertisers they wish to sell their inventory to, forward momentum must be maintained. It would be disastrous for publishers to think adopting ads.txt is the final word in fighting fraud. It is instead just the opening round in a battle that needs to move on from authorisation to authentication, from ads.txt to ads.cert.