Client
A national land registration authority responsible for registering property title, ownership changes and charges
Sector
Land Registration & Property Fraud
Engagement
Real-time fraud-risk scoring for property transfer and remortgage applications, screened against known identity-fraud indicators before registration completes - multi-quarter programme.
What the client needed
Property fraud - most often an unoccupied or unmortgaged property sold or remortgaged by someone impersonating the true owner using forged or stolen identity documents - was almost always being caught after the fact: a legitimate owner returning from abroad, a mortgage lender chasing a payment nobody recognised, or a buyer discovering the "seller" had no right to sell. By then the registration had completed, the funds had usually already moved, and unwinding it meant lengthy legal proceedings with no guarantee of full recovery for whoever was left holding the loss. The client's own case review had found the same warning signs recurring across confirmed fraud cases - a change of correspondence address shortly before a high-value transfer, first-time use of an unfamiliar conveyancer, or a property with no mortgage and no recent registered activity suddenly being sold at speed - but nothing in the existing application process brought those signals together at the moment a case officer could still act on them.
How we worked
- Built a risk-scoring engine that ran automatically against every transfer, remortgage and change-of-ownership application at the point of submission, rather than as a manual check applied to a small sample.
- Worked with the client's fraud and legal teams to encode the recurring warning signs from confirmed historical cases into scoring rules, covering correspondence-address changes, dormant or unencumbered properties, unfamiliar conveyancer relationships and unusually rapid transaction timelines.
- Added identity-document cross-referencing against the authority's own historical registration records, so a document inconsistent with a property's registration history - a name spelled differently to prior filings, for instance - raised a flag rather than passing through unquestioned.
- Designed the scoring output as a triage queue for existing caseworkers, ranking applications by risk rather than replacing officer judgement with an automated block, since a wrongly halted legitimate sale carries its own real cost to genuine buyers and sellers.
- Built a feedback loop so caseworker outcomes - confirmed fraud, false positive, or genuine transaction - retrained the scoring rules over time, rather than leaving the initial rule set static as fraud patterns shifted.
- Ran a phased rollout against historical closed cases first, letting the fraud team validate the scoring against outcomes they already knew before it screened a single live application.
Measured results
All figures verified with the client. Specific case, applicant and property detail withheld in line with our standard confidentiality terms and ongoing-investigation handling requirements.
- The scoring engine identified the large majority of a validation sample of previously confirmed fraud cases as high-risk at the point of submission, when tested against historical closed cases before going live.
- Since going live, caseworkers have intervened in a meaningful number of high-risk applications before registration completed, several of which were subsequently confirmed as attempted identity-fraud transfers.
- The triage queue has let the fraud team concentrate manual review effort on the applications most likely to be fraudulent, rather than spreading a fixed review capacity thinly and evenly across all applications.
- The false-positive rate has fallen as the feedback loop has retrained the scoring rules against confirmed outcomes, reducing friction for genuine buyers and sellers caught by an early, more conservative rule set.
- The authority is now assessing whether to extend the same scoring approach to a wider range of application types beyond the original transfer and remortgage scope.
"The cases that stayed with our team were always the ones where every warning sign was there in the file, just never in one place at one time for anyone to see before we registered the transfer. This platform put those signs in front of a caseworker while there was still a transaction to stop, not after someone's home had already changed hands without their knowledge."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
Land registration systems exist to record who owns what, not to independently verify that the person applying to change a registration is who they claim to be - that verification has historically sat with conveyancers and lenders further up the transaction chain, each checking their own piece and none holding a complete view. The brief was explicit that the platform could not become a gatekeeper with the power to unilaterally block registrations: the authority's statutory role, and the legal weight its register carries, meant any automated flag had to route to a human caseworker with the authority to investigate and decide, never to an automatic refusal. That constraint shaped the entire design around triage and evidence, not adjudication.
The false-positive cost mattered as much as the fraud-detection benefit. A genuine sale delayed by days over an incorrectly raised flag has a real cost to a buyer and seller who may be part of a wider chain of dependent transactions, and an early, overly cautious rule set risked doing exactly that at scale. Balancing sensitivity against that disruption cost, rather than simply maximising detection, was as much a design decision as any of the fraud-signal logic itself.
Why historical validation came before live scoring, not after
Fraud-detection logic is only as credible as its performance against cases the fraud team already knows the answer to, and testing it live against real applications first would have meant learning from mistakes made against genuine buyers and sellers rather than against a closed historical dataset. Running the scoring engine against years of the client's own confirmed fraud cases and confirmed genuine transactions before it screened a single live application let the fraud team see exactly where the rules over- and under-flagged, and refine them against known outcomes rather than live consequences. That validation step took longer than the initial rule-building itself, and was worth every week of it.
Designing the feedback loop as the durable part of the system
Fraud patterns shift as soon as a detection method becomes known, and a static rule set built against last year's confirmed cases has a shelf life. The platform's caseworker feedback loop - recording whether a flagged application turned out to be fraud, a false positive, or simply unusual but genuine - was built from the outset as the mechanism that would keep the scoring current, rather than an afterthought bolted on once the initial rules stopped performing. That loop, more than the original rule set, is what we'd point to as the part of this build likely to still be earning its keep years from now.
Lessons learned
The first lesson was that a fraud-detection platform inside a statutory register lives or dies on being designed as a triage aid from day one, not retrofitted into that role after an early version was built to block automatically - the legal and reputational stakes of a wrongly halted genuine transaction are too high for anything else.
The second lesson was that historical validation against closed cases deserved as much programme time as building the scoring logic itself, since it was the only way to build the fraud team's confidence - and ours - before the system touched a live application.
The third lesson was that the feedback loop needed to be treated as core infrastructure, not a future enhancement, because fraud patterns move faster than any fixed rule set can keep up with on its own.
If your organisation is weighing how to catch fraud earlier in a process that currently only confirms it after the harm is done, we would be glad to discuss what a programme like this might look like for you. Email sales@halfteck.com.