Screen scraping has quietly powered a large share of UK accounting workflows for years, and it just became a compliance liability rather than a convenient workaround. Following the HMRC screen scraping policy update published in May 2026, firms using browser automation to reach client data now face a direct regulatory problem, not a theoretical one. This guide explains what screen scraping is, what HMRC’s update says, why regulated APIs already solved this in banking, and what to audit in your stack this quarter.
Key Takeaways
- HMRC’s 2026 policy paper confirms that browser automation, screen scraping, and robotic process automation breach Government Gateway terms, whether reading or writing data.
- HMRC may block access to the associated Agent Services Account where unauthorised access is detected, which can disrupt filing and leave taxpayers exposed to penalty risk.
- Regulated APIs are explicitly outside the scope of this restriction, since they use tokenised, consented access rather than collecting sign-in details.
- Open Banking solved the same underlying problem in banking years ago; the same shift toward regulated, permissioned access is now being pushed into tax data.
What Is Screen Scraping and How Do Screen Scraping Tools Work?
Screen scraping is credential-based access to a web portal, followed by automated extraction of whatever appears on screen. Screen scraping tools log in using a stored username and password, navigate the portal as a human would, and pull data from the rendered page rather than through a defined data contract.
In accounting and finance workflows, screen scraping tools have typically been used to pull bank transaction data, tax account information, or payroll records into a central platform without a dedicated integration for each source. The appeal was speed: no partnership negotiation, no API access request, just a script pointed at a login page.
Screen Scraping Tools Depend On Structure That Was Never Designed To Be Machine-Read
A bank or government portal’s page layout was built for a human reading a screen, not a script parsing HTML. Screen scraping tools break whenever that layout changes, however minor the change.
What Does The HMRC Screen Scraping Policy Update Actually Say?
The HMRC screen scraping policy update, published as a formal policy paper on 27 May 2026, reaffirms that automation tools including browser automation, screen scraping, scripted sign-in and robotic process automation are not permitted under existing Government Gateway Terms and Conditions.
This applies whether the tool is reading data or writing it, and covers access to HMRC web services including the Agent Services Account, Business Tax Account and Personal Tax Account.
| HMRC Position | Detail |
|---|---|
| Screen scraping tools | Not permitted under Government Gateway terms, read or write |
| Credential sharing | Prohibited under HMRC’s Online Services Terms and Conditions |
| Non-compliance response | HMRC may block the associated web services account where unauthorised access is detected |
| API access | Explicitly outside the scope of the restriction |
The HMRC Screen Scraping Policy Update Draws A Clear Line Around APIs
HMRC’s policy paper is specific on this point: The authorisation of HMRC’s own APIs does not fall within scope, because APIs do not require software to request or collect sign-in details. Where an API requires user authorisation, the user signs in directly with HMRC and grants consent; the software receives tokenised access instead. This is the same architectural distinction that separates screen scraping tools from Open Banking connections in the banking world.
As reported by AccountingWEB’s coverage of the policy paper, the update has left firms using automation for HMRC access facing a genuine operational question about what replaces it.
Why Did Banking Face the Same Screen Scraping Problem First?
Before Open Banking existed, third parties reached bank account data the same way accounting software still reaches HMRC data today: by asking for the customer’s online banking credentials and scraping the resulting screens. This credential sharing model created real risk. A platform holding a customer’s actual bank login was a single point of failure if that platform was ever compromised.
Regulated Open Banking data sharing replaced that model with consented access: a customer grants a specific, scoped permission for a defined period, authenticated through their own bank using multi-factor authentication, with no credential ever leaving the bank. The HMRC screen scraping policy update pushes tax data access toward that same architecture.
Why Do APIs Beat Screen Scraping Tools on Technical Grounds?
The technical case against screen scraping tools was true before HMRC’s policy update and remains true regardless of any single regulator’s position.
- Screen scraping breaks on page changes: A layout update or redesigned login flow can silently break extraction with no warning.
- Screen scraping struggles with multi-factor authentication: Modern login flows increasingly require a second factor, which automated scripts cannot reliably complete without workarounds that themselves violate terms of service.
- Screen scraping has no audit trail: There is no structured consent record showing what was accessed, when, and under what authorisation.
- Screen scraping has no clear liability model: When credential-based access goes wrong, responsibility between platform, vendor, and customer is often disputed.
An API for bank transactions avoids all four problems by design: a defined data contract, consented access with an audit trail, and no dependency on simulating a human user through multi-factor authentication prompts.
What Should Accounting Platforms Do About Screen Scraping Now?
The practical response to the HMRC screen scraping policy update starts with an audit, not a rebuild.
First, map where screen scraping tools currently sit in your stack, across both banking data access and HMRC-facing workflows. Second, separate these two categories explicitly, since banking data and tax data face different regulatory paths. Third, move banking data onto a regulated connection. A reliable bank feed built on Open Banking removes the screen scraping dependency for that category immediately, with consented access and an audit trail built in from day one.
It is important to be precise here: this shift addresses banking data access, not HMRC or tax data access. Finexer does not provide access to HMRC systems or tax data. The HMRC screen scraping policy update is the market context that makes moving banking data off screen scraping urgent; it is not a problem Finexer’s product solves directly.
How Does Finexer Fit into This Shift Away from Screen Scraping?
Finexer’s Data product replaces credential-based bank access with FCA-authorised, consented Open Banking connections, addressing the bank-data half of this problem directly.
- Consent records and per-connection status replace the credential-sharing model, giving platforms the audit trail screen scraping tools never provided.
- Coverage spans the large majority of UK banks through one regulated integration, removing the need for separate scraping scripts per institution.
- Finexer’s banking data API is built specifically to be the banking-data replacement accounting platforms need as they retire screen scraping tools from that part of their stack.
Which Accounting Platforms Are Most Affected by This Shift?
Accounting and ERP platforms relying on scraped banking data for reconciliation face the most immediate pressure to migrate, since bank feeds sit at the core of their product.
Payroll and invoicing platforms that scrape banking data to confirm payments carry similar exposure, particularly where confirmation speed affects payroll runs.
Bookkeeping platforms integrating scraped data into client-facing dashboards should prioritise the switch first, since client trust depends directly on data reliability. A bookkeeping automation software stack built on regulated APIs avoids the silent breakage risk screen scraping tools carry.
Bottom-line
The HMRC screen scraping policy update did not create a new risk; it made an existing one explicit and enforceable. Screen scraping tools were always fragile, credential-dependent, and difficult to audit. HMRC’s 2026 policy confirms automation-based access to its web services breaches Government Gateway terms, with account blocking as a stated consequence.
Banking solved the equivalent problem years ago through regulated, consented APIs. The practical move now is auditing where screen scraping sits in your stack, separating banking data from tax data, and moving banking data onto a regulated connection first.
Does The HMRC Screen Scraping Policy Update Affect Banking Data Access?
No. HMRC’s policy update covers access to HMRC’s own web services, including the Agent Services Account. It does not directly regulate banking data access, though the same technical and risk arguments apply to both.
Are Screen Scraping Tools Banned Outright, Or Restricted In Specific Cases?
HMRC’s policy states automation tools including screen scraping are not permitted under existing Government Gateway terms, covering both reading and writing data, regardless of the specific use case.
Can Software Still Use HMRC’s Own APIs Safely?
Yes. HMRC’s policy explicitly excludes its own APIs from this restriction, since they use tokenised, consented access rather than collecting sign-in details.
Does Finexer Provide Access To HMRC Or Tax Data?
No. Finexer’s Data product covers banking data access through regulated Open Banking connections. It does not provide HMRC or tax data access of any kind.
Ready to replace screen scraping with a regulated banking data connection? See how Finexer’s consented Open Banking API gives your platform an audit trail from day one.
Explore with AI
About the Author
Ravi Ranjan
Ravi Ranjan is Co founder & CEO of Finexer