Catching the Requisition Before It Happens
Should HM Land Registry build an AI-enabled registration-readiness service — and if so, how far up the complexity curve should it go?
Every conveyancer knows the particular deflation of the requisition that need never have happened. The transfer executed without the witness’s address. The name on the transfer that does not quite match the name on the register. None of these is a point of law. Each is discovered weeks after completion, once the money has moved and the file is, in every sense that matters to the client, closed. We find the defect after we have submitted the application — a strange way to run a system that already knows, with some precision, what that defect is likely to be.
By HM Land Registry’s own figures, around 20% of the roughly 4.4 million applications it received in a recent year — some 800,000 — attracted a requisition, most carrying more than one point. HMLR estimates that nearly half of those could have been avoided. It sends more than 200,000 requisitions a year on name variations alone. It is a measured, published and largely administrative problem. The question here is whether it is also a predictable one — and if it is, whether HMLR should help us predict it before we file, rather than diagnose it after.
The planning instinct, and its limits
The obvious comparison is with planning permission. Anyone promoting a development of any complexity does not simply lodge the planning application and hope; they seek the local planning authority’s pre-application view first — now a routine, expected step — precisely to surface the objections and conditions that would otherwise emerge late and expensively. Land registration offers no equivalent: we prepare the application, submit it, and wait to be told what is wrong. If the planning system lets you test an application before you commit it, why should the registration system not?
The analogy is a useful provocation but a poor template. Pre-application planning advice is discretionary judgement about a discretionary decision: the officer is previewing how a balancing exercise might fall. Registration is not a balancing exercise. HMLR determines whether documentary and procedural requirements have been met — a far more rule-bound task. That cuts both ways. It makes a readiness service cleaner than planning pre-app, because much of what triggers a requisition can be expressed as a rule rather than a view. But it also raises the stakes: a rule-bound “pass” looks far more like a promise than a planning officer’s cautious preview ever does.
What HM Land Registry already does
One has to be honest about what HMLR already does, because it does more than the “reactive registry” caricature suggests. Applications have been digital by default since 2022, submitted through the Digital Registration Service or the Business Gateway APIs, with validation built into each stage. HMLR is now rolling out “Digital Checks”, which bring the caseworker’s simplest checks forward to submission — flagging a misspelled name or wrong title number as the application is lodged — already embedded inside conveyancing platforms. For complex commercial and infrastructure work, HMLR has for years run a human Pre-submission Enquiry Service under a Direction made pursuant to section 100(4) of the Land Registration Act 2002 — a service that will, on request, indicate whether plans and documents are likely to meet registration requirements and flag obvious requisition points. Strategy 2025+ (November 2025) commits it to automating straightforward transactions by 2030 and to near-instant, AI-assisted register updates, under human oversight, by 2035; from December 2025 it began publishing every firm’s avoidable-requisition rate.
So the proposition is not that HMLR should invent pre-submission checking. It already has it — at two ends of a spectrum. At the trivial end, Digital Checks catch typos. At the complex end, scarce human specialists advise on infrastructure deals. The interesting territory is the vast middle: the substantive-but-routine requisition — the defective execution, the name discrepancy needing evidence, the missing consent, the plan that will not do. That is where most of the 947,000 live, reached today by neither deterministic validation nor human specialists at scale.
The middle band — and what a readiness engine would do
Picture a Registration Readiness service that occupies that middle. A practitioner assembles the intended application — transfer, charge, plan, consents, prescribed forms — and, before submission, the system compares it against the title register and plan, the relevant Practice Guides, the prescribed procedural requirements, and the anonymised pattern of past requisitions in comparable applications. It returns a graded assessment:
no apparent issue identified;
possible requisition — practitioner review recommended;
likely requisition — remedy before submission; or
a point too novel for automated help, requiring human judgement.
For each flag it gives the issue, the authority for it, the likely registration consequence, a suggested cure and — critically — a confidence level and an honest admission of where it cannot assist.
This is not an “AI chatbot” bolted to the register. The right architecture is unglamorous: deterministic rules and conventional document validation for anything expressible as a requirement; structured comparison against the register for discrepancies; machine-learned pattern analysis for the probabilistic middle; and retrieval-grounded generation, tightly leashed to Practice Guides and statute, only for the explanation layer. Generative AI is the narrator, not the decision-maker. The real product is not a clever model but authoritative, codified registration-readiness infrastructure.
Prediction is not verification
Here is the conceptual hinge of the whole idea: the difference between “this application is unlikely to generate a requisition” and “HMLR has verified that this application complies.” These are not the same statement, and a great deal turns on not letting the second masquerade as the first. HMLR’s existing human service is scrupulous about this — it will not guarantee to accept a registration until the application is actually made with all supporting documentation. Here automation makes the problem harder, not easier. A caveated letter from a named technician reads as guidance. A confident, HMLR-branded “Registration Readiness: PASS” reads, to a busy fee-earner at six on a Friday, as approval. The authority signal is louder precisely because it is automated.
That is where the legal exposure sits. A public authority’s pre-submission indication invites arguments about reliance and, if framed as an assumption of responsibility, about negligent misstatement. It could seed a legitimate-expectation argument if a “pass” is thought to bind the eventual determination. This is manageable only through express, durable framing: non-binding decision-support and risk identification, never verification or approval. The uncomfortable question, to which I will return, is whether those disclaimers hold once the tool becomes de facto standard.
The feedback loop, and its poison
The most seductive element is the feedback loop: application, pre-submission check, submission, outcome, anonymised learning, better prediction. In principle it converts HMLR’s institutional experience of what goes wrong into a predictive service no private vendor can replicate — HMLR alone holds the ground truth of what was requisitioned and why.
But historical requisitions are a treacherous training set. HMLR’s own audit found it raises requisitions correctly about 97% of the time — which means roughly 3% of the historical record is wrong. Past practice has also been inconsistent between offices and across time. A model trained naively on “what caseworkers tended to requisition” learns to predict caseworker behaviour, not legal correctness — and those are not the same thing. Left unchecked, it would launder yesterday’s inconsistency into tomorrow’s authority, entrenching error with the gloss of objectivity. The feedback loop is only safe if it is curated against the law, not merely mined from the past.
The transparency dividend
There is a subtler benefit here, slightly threatening to the institution. To build a model that must justify every flag against a stated authority, HMLR would have to codify precisely why applications are requisitioned — and in doing so it would expose the seams between its public Practice Guides, the strict legal requirements, and how applications are in fact processed. Those three do not always coincide. Forcing them into alignment is uncomfortable, but the discomfort is the point: a readiness engine is also, unavoidably, an audit of HMLR’s own consistency. That may be the most valuable thing it produces.
Who should build it
None of this settles who should build it. Three models present themselves. HMLR could own the whole service; but building practitioner-facing software is not its comparative advantage, and a monopoly interface would ossify. The private sector could build competing tools on HMLR’s public data and APIs — indeed at least one pre-validation product already markets exactly this — but private tools lack the authoritative grounding and the consistency that only the registry’s own data confers. The persuasive answer is the hybrid: HMLR owns and publishes the authoritative reference data, the graded prediction engine and the API; vendors build the practitioner experience and embed it inside case-management systems. Digital Checks, now appearing inside third-party conveyancing software, are already that direction of travel. The registry supplies the truth; the market supplies the interface.
Where this actually leads
Follow the trajectory and the destination is not better bundle-checking. It runs from requisition prediction, through remediation assistance, to genuine registration readiness, to intelligent submission, and finally to machine-readable conveyancing — in which transaction data is structured from the outset, so defects surface during preparation, not after completion. As HMLR itself has put it, the output can only be as trusted as the inputs; the real prize lies in reliable, structured information at the point the conveyancer certifies what happened. Registration readiness is the on-ramp to that world, not the destination.
The quiet rewriting of competence
A question worth posing, without pretending to resolve it. If HMLR eventually offers a free tool that identifies avoidable defects with very high accuracy, does running it before submission slowly become part of competent conveyancing? No such duty exists today, and I assert none. But standards of competence have always tracked the tools reasonably available. Once checking a bundle is free, instant and reliable, not checking it starts to look less like a choice than an omission. Public infrastructure has a way of quietly rewriting the standard of care.
A qualified yes
So, a qualified yes. HMLR should seriously explore a controlled Registration Readiness service — but a particular one. It should be non-binding, source-grounded decision-support and requisition-prediction, never automated verification. It should be built as authoritative infrastructure and an API in the hybrid model, not as a chatbot HMLR owns end to end. It should aim squarely at the substantive-but-routine middle, since the trivial end is already handled and the complex end properly belongs to humans. And it should hold the line between prediction and verification as if the system’s credibility depended on it — because it does.
The deeper shift is worth naming. For twenty years the ambition has been to process applications faster. The more interesting ambition is to stop defective applications being submitted at all — to move the moment of quality control back from the registry’s desk to the practitioner’s screen. If that is where this leads, the question is no longer how quickly HMLR can register what we send. It is whether, before long, we will send anything that is not already registrable — and what “a complete application” will mean when incompleteness has become something the system simply will not let us file.
Sources and further reading
HM Land Registry, Strategy 2025+ (November 2025). HM Land Registry, “HM Land Registry requisitions” guidance and Practice Guide 50: requisition and cancellation procedures (GOV.UK). HM Land Registry blog, “More customers are saving time and money with right-first-time applications” (November 2025). Direction 7: Pre-submission Enquiry Service and Application Management Service, made under section 100(4), Land Registration Act 2002. Digital Registration Service and Digital Checks (HM Land Registry). Artificial Intelligence Playbook for the UK Government (Government Digital Service, February 2025). Land Registration Act 2002; Land Registration Rules 2003.