HMRC fraud prevention headers: what they are, and what happens when you get them wrong

If your software talks to HMRC's VAT or Income Tax MTD APIs, you are required by law to send fraud prevention headers with every request. Get them wrong and you risk a £3,000 penalty. Keep getting them wrong and HMRC can block your software from their APIs entirely.

What fraud prevention headers actually are

Every time your software sends something to HMRC on a taxpayer's behalf, it has to attach a set of HTTP headers describing where that request came from. Device identifiers, connection details, timezone, screen information, which user was signed in, what version of your software is running.

The purpose is fraud detection. If someone files two thousand returns from one machine at three in the morning, HMRC wants to be able to see that. The headers are how they see it.

The important part for a vendor: this is not guidance and it is not best practice. HMRC states plainly that you are required by law to submit header data for the VAT (MTD) and Income Tax Self Assessment (MTD) APIs, including all associated endpoints.

What happens if you get it wrong

HMRC has published a compliance and sanctions process, and it escalates in a predictable order.

• First, a conversation. HMRC monitors submitted header data and gets in touch where it is incorrect or missing.
• Then a financial penalty. A £3,000 penalty applies to developers that fail to support the data transmission requirement.
• Then loss of access. HMRC states that where an application continues to submit incorrect or missing data after discussions, providers may be fined and blocked from using HMRC APIs.

That last one is the one that should hold your attention. For a product whose entire function is filing to HMRC, losing API access is not a compliance problem. It is the end of the product.

There is a grace period, and it is finite

HMRC allows a six month window to accommodate new and amended headers. After that, patterns of non compliance are monitored and can enter the sanctions process. The grace period is for changes to the specification, not for never having implemented it.

Why competent teams still get this wrong

This is rarely incompetence. It is almost always one of four things.

The required headers depend on your architecture

HMRC defines eight connection methods: desktop application direct, desktop application via server, web application via server, mobile application direct, mobile application via server, batch process direct, other direct, and other via server. The header set you owe depends on which one you are.

Classify yourself wrong and you will send a complete, well formed, carefully implemented set of the wrong headers. Everything looks fine from your side. It is not fine.

It was implemented once, at launch, by someone who left

Header implementation usually happens during the push for production credentials, then never gets touched again. Meanwhile the specification is amended, your architecture changes, you add a mobile app, you move to a new auth provider. Nobody goes back.

The agency that built it is not the agency that maintains it

If your platform was built by an outside development shop, the header implementation was almost certainly a ticket in a sprint two years ago. The people who wrote it have moved on. The people maintaining it inherited it as code that already worked and have no reason to question it.

Nothing visibly breaks

This is the real reason. Wrong headers do not throw errors your customers see. Returns still file. Nobody complains. The first signal is a letter from HMRC, and by then the pattern is already established.

How to check yours

HMRC publishes a Test Fraud Prevention Headers API specifically so vendors can validate what they are sending. It is free and it is public.

HMRC also checks this at the gate. Compliant fraud prevention header information must be provided before production access to the MTD APIs is granted at all, and a specialist team reviews your sandbox calls to confirm it. So if you are live, you passed once, on test traffic, on the day you were approved.

The question is whether you still pass. Nothing in that process repeats, and nothing in it asks how those headers are stored or exposed once collected. Sending them correctly and handling them safely are two different questions, and HMRC only ever asked you the first one.

The wider point

Fraud prevention headers are worth checking on their own merits. They are also a useful proxy for something larger.

A vendor who has not looked at their headers since launch has usually not looked at their access controls, their payment gates or their API surface either. Not through negligence, but because the people who built it are the only people who have ever examined it, and they have no reason to doubt their own work.

HMRC's own guidance tells taxpayers to carry out due diligence on the developers of the software they use, and to check that the product meets security standards. Your customers are being told to ask. It is worth having an answer that does not come from the people who wrote the code.

That is what a Build Review is for. And if you just want the headers checked, we do that free.