Manav.id
Vertical · 5 min read

Self-exclusion integrity: the protection enforced by matching details the excluded person knows

Self-exclusion integrity: the protection enforced by matching details the excluded person knows

There is a control in gambling designed to be used by someone against their own future behaviour, and it is implemented as attribute matching against an adversary who knows the matching key perfectly — because the matching key is their own personal details.

Why does self-exclusion fail?

Because it is enforced by matching details the excluded person controls. Self-exclusion is the strongest protection a person can invoke for themselves, and it is implemented as a name, date of birth and address comparison — all of which the excluded person can vary, and some of which change legitimately.

Key takeaways
  • Exclusion registers are attribute-matching systems, and the person most motivated to defeat them has perfect knowledge of the attributes.
  • Binding exclusion to an enrolled credential rather than to personal data raises the cost of evasion without creating a larger sensitive dataset.
  • An exclusion register is among the most sensitive datasets in existence; data minimisation is part of the design, not an afterthought.

A person, not a threat model

Self-exclusion registeredname, DOB, addressRegisters at another operatora middle initial addedMatch failsfuzzy matching is tuned downAccount openedprotection defeated
Every variation is something a legitimate customer also does.

Start with who this is about. Someone sits down, recognises that their gambling has become harmful, and takes a deliberate step to remove their own access. That act requires more self-awareness than most people manage about anything.

Weeks or months later, in a different state of mind, the same person tries to get back in. Both of those people are the same person, and the control exists because the first one asked for protection from the second.

Everything that follows should be read with that in mind. This is not a fraud control and framing it as one produces bad design.

How exclusion is enforced today

National and operator-level schemes record an excluded person's details — name, date of birth, address, sometimes email and payment identifiers — and operators match new registrations against the register.

Matching is fuzzy, because legitimate variation exists: a middle name included or omitted, a new address, a maiden name. Fuzzy matching creates the tolerance that evasion exploits.

VariationLegitimate causeDefeats matching?
Name spelling or orderingTransliteration, marriage, informal formsOften
AddressGenuine relocationOften
Email addressRoutineYes
Payment methodNew card or accountYes
Date of birthNot legitimateYes, and it is the clearest evasion signal

An operator tightening the matching to close these gaps generates false positives against legitimate customers with common names, which is its own harm and its own regulatory problem.

What a credential changes

A credential is not derived from personal data. Exclusion binds to the credential, and re-registration with a new name, address and email does not produce a new credential unless the person enrols a new one on a new device.

That is a meaningfully higher bar than editing a form field, and it is worth being precise about how much higher.

What it does not do

A determined person can obtain a new device, decline to enrol, or use an operator that does not participate. No technical control prevents that, and any article implying otherwise is misleading people who are looking for help.

What the control does is raise the cost from type a different email address to acquire and enrol a separate device. In gambling harm research, friction at the moment of relapse has measurable effect precisely because the impulse is time-limited. Raising cost is a legitimate goal even when prevention is impossible.

The data minimisation argument

This is where the design is unambiguously better rather than merely different.

A national exclusion register holds the identities of people who have declared a gambling problem. That is among the most sensitive datasets anyone maintains — it reveals a health-adjacent condition about named individuals, held centrally, shared with commercial operators.

DesignWhat the register holdsBreach consequence
Attribute matchingNames, dates of birth, addresses of people with gambling problemsDirect exposure of a highly stigmatised condition
Credential bindingPublic keys of enrolled credentialsNo personal data; keys are not identifying without the enrolment record

An operator checking a credential against a register of public keys learns whether this credential is excluded. It does not receive a list of excluded people, which is what it receives today.

The design, with its safeguards

  1. Enrolment happens at the moment of exclusion, while the person has made the decision and is engaged.
  2. The register stores the credential's public key and the exclusion period. No name, no address, no date of birth.
  3. Operators check presented credentials against the register. A match blocks registration and deposit.
  4. Existing attribute matching continues alongside, because credential coverage builds slowly and a partial control should not replace a working one.
  5. Reversal of exclusion follows the scheme's existing cooling-off requirements — the credential does not make reversal easier.

Point five matters. The credential should not become a faster route back in. Whatever waiting period and re-engagement process the scheme requires applies unchanged.

What operators should measure

Not evasion attempts, which are difficult to count and easy to misclassify. Measure re-registration attempts by excluded individuals that were blocked, and the share blocked by attribute matching versus credential matching.

If credential matching blocks materially more, the control is working. If it does not, the enrolment coverage is too low to matter yet and the answer is enrolment, not a different control.

The tuning problem nobody can win

Matching sensitivity, both failure directions
SettingEffect
TightExcluded people slip through with minor variations
LooseUnrelated people are wrongly excluded
BetweenBoth, proportionally

A wrongly excluded customer complains loudly and is a regulatory problem of its own, so operators tune toward the tight end. That choice is rational per operator and it is what makes the protection porous in aggregate.

Objections and honest limits

“National schemes solve this.” They centralise the register, which helps materially. They still match on the same attributes, so the tuning problem moves rather than disappearing.

“This needs a national identity system.” It needs a credential the person enrols once and cannot vary, which is not the same thing. The register can hold a public key and no personal data at all — which is a privacy improvement over holding names and addresses.

Making exclusion durable

  1. Bind exclusion to an enrolled credential. Not to attributes the person can vary.
  2. Hold a key, not a dossier. The register needs no name, date of birth or address.
  3. Check at registration and at deposit. People who slip through the first check reach the second.
  4. Make removal deliberately slow. A cooling-off period is the point of the protection.

Terms used here

Self-exclusion
A voluntary request to be barred from gambling, enforced by operators and sometimes by a national scheme.
Fuzzy matching
Comparing records allowing for variation, tuned between missing genuine matches and producing false ones.
Cooling-off
A mandatory delay before an exclusion can be lifted, which is the substance of the protection.

Frequently asked questions

Does this prevent an excluded person gambling? No. It raises the cost of re-registration from editing a form to acquiring and enrolling a new device. No technical control prevents a determined person from gambling elsewhere.

Does it make the register more sensitive? The opposite. A register of public keys contains no personal data, where the current register contains the identities of people who have declared a gambling problem.

What if someone loses their device? They re-enrol through the scheme's process, which should verify identity against the existing exclusion record. Device loss must not become an exclusion reset.

Should this replace attribute matching? No. Run both. Credential coverage builds over years and a partial control should never displace a working one.

Why not just improve the matching? Both directions fail. Tighter matching lets excluded people through; looser matching wrongly excludes unrelated customers, which is its own regulatory problem.

Does this require a national identity system? No. The register can hold a public key and no personal data, which is more private than holding names and addresses.

Where should the check run? At registration and again at deposit, because people who pass the first check reach the second.

Where this fits in Manav

Manav proves a specific person authorised a specific action, without a vault, a token or surveillance. The biometric never leaves the device and the platform receives a signature rather than a profile.

What we do not do →

Sources and further reading