Exclusion lists and comps: keeping incentives away from excluded patrons

A patron who has excluded themselves, or whom a regulator has excluded, must never receive an incentive. Meeting that obligation reliably means checking before value moves — not remembering to check after.

Every operator knows the rule. Self-excluded and regulator-excluded patrons are not to be marketed to, rewarded, or comped. The difficulty is not the rule; it is honouring it on every comp, every campaign, and every shift, without depending on a member of staff to recognise a name. This guide sets out why the exclusion check belongs inside the authorization path, and what changes when it lives there.

The obligation

An excluded patron receiving an incentive is not a minor error. It is a compliance failure and a reputational one, and a single missed check is enough to cause it. The patron who asked to be kept away has instead been drawn back with a free-play offer or a comped meal; the operator has done the precise thing exclusion exists to prevent. Regulators treat these failures seriously, and rightly so — the people on an exclusion list are frequently the people least able to absorb the harm.

Because one miss is enough, the control cannot be probabilistic. It has to hold every time, which means it cannot rest on memory or goodwill.

Check before value, every time

The reliable place for an exclusion check is before any incentive reaches a patron — not as a report run the next morning, and not as a cross-reference someone is expected to remember. In AEGIS, the exclusion check runs inside the real-time authorization path, as part of the same authority decision that governs whether a comp is allowed at all. The authority decision returns in under about five milliseconds, so the check adds no friction the floor would feel a reason to skip.

The same check applies whether the incentive is a single comp at the desk or a batch offer campaign sent to thousands. There is no path by which value reaches a patron without passing it. That is the point of putting the check before value rather than after: an excluded patron is stopped at the decision, not discovered in an audit.

Lists change, so the check must be live

Exclusion lists are not static. A patron can be added in the morning and must be honoured by the afternoon. A check run against a stale nightly export leaves a window in which a freshly excluded patron can still be comped — exactly the window in which the decision to exclude was most deliberate and most recent.

AEGIS checks against the current list at the moment of the comp, in real time, rather than against a periodic snapshot. The decision reflects the list as it stands now. A patron excluded this morning is excluded this afternoon, with no lag to explain to a regulator later.

Consistent across the enterprise

Exclusion is meaningless if it is honoured at one property and forgotten at the next. Because patron identity and worth are tenant-wide in AEGIS, an exclusion recorded anywhere is recognised everywhere. The patron who excluded themselves at one property cannot walk into a sister property and be comped as though the record did not exist. Cross-property consistency is a property of how identity is modelled, not a procedure each site has to run on its own.

This is also where responsible-gaming caps and cooldowns and exclusion reinforce each other: both are patron-level protections resolved inside the same authority decision, so an at-risk patron is treated consistently regardless of where the comp originates.

Proof it ran

It is not enough for the exclusion check to run; you have to be able to show that it ran. Every decision AEGIS makes is sealed to an immutable audit trail — hash-chained and anchored into immudb, a store the platform itself cannot alter. For any comp, at any date, you can demonstrate to a regulator that the exclusion and responsible-gaming checks were performed and what they returned.

That turns a policy statement into evidence. Instead of asserting that excluded patrons are never comped, you can produce the sealed decision for any comp and let the record speak. The same discipline that governs offer campaigns applies here: the proof is a by-product of the decision, not a report someone has to reconstruct after the fact.

Where this sits

AEGIS does not replace the systems that hold your exclusion data or calculate patron worth. It is the governed authorization layer that consults exclusion status as part of every comp and campaign decision, and complements your casino management system rather than standing in for it. What it adds is the guarantee that the check happens in the right place — before value, every time — and the proof that it did.