A rejected application is not a closed case. The file goes back, the reviewer moves on, and four days later a cleaner version of the same document arrives under a new email address. Nothing in the detection stack failed. It simply has no memory.
That memory is the document blocklist, and it is where repeat applicant fraud is actually won or lost. Not a spam filter, not a deny list of file hashes, but a record of decisions: we have judged this before, this is the evidence, this is how long the judgment stands, and this is how someone challenges it.
Our earlier piece on AI-generated document fraud covers the detection question — whether the artifact in front of you is genuine. This one starts one step later. The decision has been made. Now it has to persist, apply to the right people, and expire.
A blocklist is a key, not a list
Storing the list is trivial. Choosing the key is the entire design. The key decides who else gets caught, how many minutes of effort it takes to evade, and how defensible the whole control is when someone asks why they cannot open an account.
Pick the wrong key and you get one of two failures. A key that is cheap to change blocks nobody for long; the same applicant returns with a new address before the entry is even indexed. A key that is widely shared blocks strangers, and you will not hear about most of them — they leave.
Five keys, five different error profiles
Most identity intake systems can block on five things. They are not interchangeable.
| Key | What it actually identifies | Cost to change | Collateral risk |
|---|---|---|---|
| Document number | One issued credential | High — requires a new document | Low; transcription errors aside |
| Face template | One person, across documents | Very high | Low, but the match threshold is the control |
| Email or phone | One reachable channel | Low — minutes | Moderate; recycled numbers, shared family lines |
| IP address | A network path at one moment | Very low | High — carrier NAT, offices, campuses, VPNs |
| Device fingerprint | A browser or handset configuration | Low to moderate | Moderate; shared and public machines |
The pattern is easier to state than to hold to under pressure: block on what is expensive to change and specific to one person; score on what is cheap to change or shared by many. Document number and face template belong on the first side. IP address belongs firmly on the second, and it is the one teams reach for first because it is the easiest to log.
Face matching earns its place only with a stated threshold and a stated error rate, because a template comparison is a probability, not an identifier. If the face key is doing real work, the liveness and matching layer beneath it has to be honest about what it measures — the argument in liveness without keeping a face applies directly to the quality of anything you then block on.
An entry without an expiry is not a decision
Blocklists default to permanent because nobody chooses permanence; they simply never write the expiry field. The result is a control that grows monotonically, is never reviewed, and eventually contains entries whose evidence no longer exists anywhere.
Tier the entries instead, and let the tier carry the duration.
- Unconfirmed suspicion — a signal fired, no adjudication happened. Short life, 90 days, auto-expiring with no action required.
- Adjudicated fraud — a human confirmed it against retained evidence. Long life, 2 years, with an explicit review at expiry rather than a silent renewal.
- Reported to an authority — held while the case is open, because the retention is now driven by the case, not by you.
- Sanctions and legal lists — not your blocklist at all. That is a lookup against someone else's source, on that source's refresh cadence, and mixing it into your own table quietly turns a compliance obligation into a local cache.
Expiry is not leniency. It is the mechanism that forces evidence and decision to stay attached to each other. An entry that cannot survive its own review was never defensible.
Contestation is part of the control
If a blocked person cannot discover that they are blocked and cannot challenge it, the blocklist is not a control. It is a wall with no door, and its error rate is unknowable by construction.
A contestation path needs four concrete things: a route that a rejected applicant can actually find, a human who decides, a published deadline — acknowledge in 1 business day, decide in 5 — and a written record of who lifted the entry and on what evidence. In several jurisdictions a decision taken solely by automated means carries a right to human review; check what applies to your markets before assuming the appeal is a courtesy.
A blocklist you cannot appeal is not a fraud control. It is an untested hypothesis about strangers.
The appeal is also the cheapest source of truth you have about your own precision. Every overturned block is a labelled false positive that arrived without you having to run a study.
False positives have a measurable budget
Precision on a blocklist is not observable from the blocked side — you never see what a wrongly blocked applicant would have done. So measure the things that are observable, per key.
| Measure | What it tells you | The trap |
|---|---|---|
| Hit rate per key | Whether the key catches anything | A key with no hits is cost, not safety |
| Appeal rate | Whether the door is findable | Near-zero usually means hidden, not correct |
| Overturn rate | Observed false positives | Only counts appeals that were made |
| Time to overturn | What the error costs a real person | Averages hide the long tail |
An overturn rate near zero is the finding that deserves the most suspicion. It means either the keys are near-perfect or the appeal path is unreachable, and those two states look identical on a dashboard. Only one of them is good news, and the cheap way to tell them apart is to check whether the appeal rate moved when you last made the route more visible.
Watch the rates separately for each key. An aggregate overturn rate of 2% can easily be 0.1% on document number and 30% on IP address, and the aggregate is the number that keeps the IP rule alive.
What the entry has to record
A blocklist is a database of people your company has accused of something. It inherits every access, retention and disclosure obligation that implies, and the entry has to carry enough to justify itself years later.
- Key type and value — hashed where the comparison allows it, so the table is not a plaintext roster of accusations.
- Reason and evidence pointer — the specific signal and the artifact it came from, not a category label.
- Decider and timestamp — which rule or which person, with the version of the rule that fired.
- Tier and expiry — the two fields that make the entry reviewable.
- Appeal and lift history — every challenge, outcome, and the evidence that lifted it.
That is the same discipline described in audit trails for non-deterministic outputs: a record is only useful if it lets a later reader reconstruct why the decision was reasonable at the time it was taken.
The five-line review
- Which key does each entry hang on, and why is that key defensible?
- What is the expiry, and what actually happens when it arrives?
- How does a blocked person find out, and who decides their appeal?
- What is the overturn rate per key, and who reads it?
- Who can lift an entry, and where is that written down?
A detection stack answers whether the document in front of you is real. A blocklist answers what the company does with that answer tomorrow, and to whom. The second question has more people in it, and most of them are not the fraudster you built it for.