Required for applicable API calls.
HMRC production-onboarding answer
Yes is the
required behaviour.
SMRC’s design requirement is to submit the fraud-prevention headers required for every applicable HMRC API request. The data must describe the real user, device, software and network context—never invented placeholder values.
Accurate status: “Yes” records SMRC’s mandatory implementation commitment. The supplied desktop code does not yet transmit the full header set, and HMRC’s Test Fraud Prevention Headers API has not yet confirmed it. Live HMRC filing therefore remains locked.
Connection architecture
Windows desktop, direct to HMRC.
The current intended architecture is DESKTOP_APP_DIRECT: the SMRC Windows application initiates the user’s applicable HMRC API request directly. If an SMRC intermediary server is introduced later, the connection method and required vendor/server headers must be reassessed before release.
No SMRC intermediary server in the current design.
Reviewed against HMRC guidance current on 27 July 2026.
Until collection, formatting and HMRC testing pass.
Required desktop-direct register
Fourteen headers. Real values only.
Values are collected at the point the user initiates an applicable HMRC API action. Structured values use HMRC’s required percent encoding and US-ASCII transport rules.
Gov-Client-Connection-Method
DESKTOP_APP_DIRECT identifies the selected architecture.
Gov-Client-Device-ID
A persistent UUID identifies the originating installation without exposing a password.
Gov-Client-Local-IPs
Available local IPv4 and IPv6 addresses, collected immediately before the request.
Gov-Client-Local-IPs-Timestamp
The paired UTC collection timestamp, including seconds and milliseconds.
Gov-Client-MAC-Addresses
Available network-interface addresses, percent encoded and separated correctly.
Gov-Client-Multi-Factor
MFA type, last-successful UTC time and stable non-secret factor reference, where applicable.
Gov-Client-Screens
Positive screen dimensions, scaling factor and colour depth for every attached screen.
Gov-Client-Timezone
The device’s current offset in the required UTC±hh:mm form.
Gov-Client-User-Agent
Operating-system family/version and available device manufacturer/model.
Gov-Client-User-IDs
The Windows user identity and SMRC user identity, where one exists—never a password.
Gov-Client-Window-Size
Positive width and height of the active SMRC window when the user submits.
Gov-Vendor-License-IDs
A consistent one-way hash of the licence reference; the raw activation key is never sent.
Gov-Vendor-Product-Name
The percent-encoded marketed product name: SMRC Payroll.
Gov-Vendor-Version
The versions of each SMRC component that handled the request.
Controlled request path
Collect, validate, send, evidence.
- 1Collect at user action
Capture volatile network, screen, window and time values immediately before the applicable request.
- 2Validate locally
Reject invalid dimensions, timestamps, identifiers or non-ASCII transport values before transmission.
- 3Send with the API call
Add the required Gov-Client and Gov-Vendor headers to the same authorised HMRC request.
- 4Keep safe evidence
Record header names, validation outcome and correlation evidence without logging secrets or unnecessary raw identifiers.
Privacy and security
Explain the collection before it happens.
Fraud-prevention metadata can include device, network, screen, software, licence and user identifiers. SMRC must disclose that collection, minimise it to HMRC’s requirements, protect it in transit and avoid displaying it in ordinary customer reports.
- No passwords, OAuth tokens or raw licence keys in headers
- No placeholder values such as “null” or “undefined”
- No silent substitution when a required value cannot be collected
- No sensitive values in application logs or support emails
- Exceptional missing data must be discussed with HMRC
Acceptance evidence
“Yes” must be proven by requests.
Before live access is enabled, SMRC needs successful Test Fraud Prevention Headers API results and representative sandbox evidence across different devices, Windows users, displays and network conditions.