The rulebook as an interface: the FCA makes its Handbook machine-readable

On 6 August 2026 the Financial Conduct Authority (FCA) switched on an application programming interface (API) for its Handbook. Systems can now reach structured rulebook content directly. Alex Smith, the FCA's Head of Cross-cutting Policy & Strategy, put the purpose plainly in the announcement: "It enables systems to access structured Handbook content directly."

That reads like a technical footnote. It is not one. Until now, a regulator's rulebook was, to a machine, a pile of web pages. Anyone wanting to track rule changes automatically had to scrape and parse them, with every break that a layout change brings. The rule text is now a queryable data source. For anyone automating compliance processes or pointing agents at them, the foundation has shifted.

What the FCA built the interface for

The announcement is unusually open about who it is meant for. It names firms with in-house technology teams, RegTech and technology providers, developers of compliance tools and, explicitly, developers of artificial intelligence applications. The stated benefits are mapping rules onto products, activities and customer journeys in near real time, and tracking and comparing rule changes as they happen.

The fourth justification is the striking one, because a supervisor would not have phrased it this way until recently. The FCA wants to supply "trusted, up-to-date data to support more useful, accurate and transparent AI tools". Here a regulator deliberately provides the data layer that other people's AI tools are meant to sit on. The logic holds up. A language model answering compliance questions is only as reliable as the rule text it can reach, and anyone sourcing that text second hand inherits every transcription error along the way.

Access costs nothing. A registered account is enough. Use falls under the Terms & Conditions, and protected endpoints carry a rate limit applied per authenticated user and endpoint path. The interface is not accessed through the website but through ordinary development tooling.

The limitation is absent from the announcement

The blog promotes the fact that the interface serves both the current and the forthcoming state of the rulebook. What it leaves out sits in the technical notice accompanying the launch, and it is the single most consequential sentence in the whole release: "The API does not provide past versions." A call carrying a date in the past returns an error.

This separates two kinds of compliance work cleanly. The forward-looking case is solved. Which rules apply today, which take effect when, what has changed since the last version: that is exactly what the interface is built for, and it does the job better than any scraping arrangement.

The backward-looking case is not. Audit, internal review, enforcement proceedings and the assessment of legacy contracts nearly always turn on the same question. Which rule applied on a given date, and in which version? Anyone who has to answer that question cannot get it from the interface, and will still need to version the rulebook themselves.

Machine-readable is not machine-executable

The second issue is what the FCA is actually claiming. What the FCA serves is structured rule text. It is not executable rule logic. The distinction matters a great deal, and the FCA understands it better than most, having spent a decade pursuing the second option.

The story starts in November 2016 with a TechSprint on digitising reporting instructions. A year later the Bank of England and the FCA ran a joint TechSprint titled "Model Driven Machine Executable Regulatory Reporting". The Digital Regulatory Reporting programme that followed ran two pilot phases. The first, from June to December 2018, tested whether reporting requirements could be expressed in executable form. The second, from February to October 2019, worked with domain-specific languages alongside a cost-benefit model. Seven institutions took part, listed as "Barclays, Credit Suisse, HSBC, Lloyds, Nationwide, NatWest and Santander".

The Viability Assessment of January 2020 sets out the scale involved. The FCA receives "500,000 scheduled regulatory reports" a year, and British firms spend an estimated "1.5 to 4 billion pounds a year" on regulatory compliance. A programme with that much leverage has not failed, yet it has not reached scale either. It was folded into the authority's data strategy, where a third phase now works on improving core data for supervisors and on the groundwork for technology-driven reporting.

Seen against that history, the Handbook API is less a breakthrough than a pragmatic intermediate step: not the executable rule, but the rule text in reliably structured form. That is the part of the problem which nine years have shown to be solvable.

Why European institutions should be watching

For firms without British business this looks at first like news from another jurisdiction. The comparison still pays off, because it brings the European position into sharper focus.

The European Banking Authority (EBA) runs an impressive counterpart in the Interactive Single Rulebook. It gathers level 1 texts, delegated and implementing acts, technical standards, guidelines, recommendations and the associated Q&As in one place. It also carries a disclaimer that goes to the heart of any automated use: "This Interactive Single Rulebook is meant purely as a documentation tool and has no legal effect." This is followed by "The EBA does not assume any liability for its contents." and a pointer to the Official Journal via EUR-Lex for the authentic text.

The EBA offers no interface to go with it. Access runs through a table of contents and a search box in the browser. Anyone in the EU wanting to build what British institutions can now simply call is still parsing web pages or the Official Journal.

This is not a league table but a description of two postures. The EBA takes care to protect itself on legal grounds and places its tool firmly alongside the binding text. The FCA supplies data and, in the same announcement, calls it "trusted". Anyone opening up the regulatory data space for agents and automated controls will find the second posture easier to work with.

What this means in practice

Four starting points for compliance, internal audit and everyone responsible for compliance architecture.