Real-time comp authorization for integrated resorts: how it works
Comps move cash-equivalent value through hundreds of hands, around the clock, with almost no real-time governance. This is how that governance actually runs on the floor — the flow, the latency, the architecture, and the guardrails.
An integrated resort issues comps continuously: free play, meals, suites, show tickets, rebates. Each one is cash-equivalent value leaving the building, authorised by a staff member on a terminal, at a pace no manual sign-off process can keep up with. Most floors close that gap with policy documents and after-the-fact review. Real-time comp authorization closes it at the moment of the decision instead.
CompWarden's AEGIS platform is the comp authority engine for exactly this problem. It checks every comp against a delegation-of-authority (DOA) matrix in real time and seals the outcome before value moves. Here is what happens on each request.
The flow of a single comp
A staff member raises a comp on the floor. Four things follow, in order, without anyone waiting on a phone call:
- Request. The comp — type, amount, patron, requester — arrives at the engine from the terminal.
- Authority check. The engine resolves the request against the DOA matrix in milliseconds: the right role, the right comp type, the right limit.
- Within authority: instant approval, with the required evidence attached to the decision. Above the limit: automatic escalation up the reporting line until it reaches someone whose authority covers it — at 3am, the duty manager's mobile, not a day-shift desk.
- Seal. The decision is written to the tamper-evident audit trail, carrying its ledger anchor and the exact matrix version that produced it.
From the requester's side, an in-authority comp is approved on the spot. Nothing about the pace of the floor changes — what changes is that every approval is now a governed, provable decision rather than an unrecorded act of goodwill.
Why it's fast enough for a terminal on the floor
Speed here is an architectural choice, not a tuning exercise. AEGIS runs two deliberately separate engines:
- A decision engine that answers authority checks — and only authority checks — in milliseconds. It is what sits in front of the terminal.
- A workflow engine that runs escalations, reminders, and holds. This is the slower, stateful work, and it runs without blocking the real-time response.
Because escalation and follow-up never sit in the critical path, an in-authority comp never waits on them. The moment a decision is made it is published to a Kafka-compatible event stream, so escalations and downstream systems can react to the same event without holding up the terminal.
Resilient by design
A floor cannot stop because a data centre did. AEGIS runs as containerised services at two sites in different countries, one writing and one following it continuously, with automatic failover if the first fails — so losing a site means a short interruption while the standby takes over, not a lost record. When a phone cannot reach the service there is no stale-rules guess: where the operator has switched it on, a host can grant from a small, expiring allowance issued beforehand, signed on the phone, handed in on reconnection and reviewed by a person with anything outside the allowance flagged; otherwise the comp waits for a governed decision.
Guardrails before value leaves
Authority is not the only check. Before any incentive reaches a patron, two more run inside the authorization path:
- Exclusion checks — a self-excluded or barred patron is stopped before value moves, not flagged after.
- Responsible-gaming caps and cooldowns, set per comp type — a limit or a cooling-off window applies to the comp being issued, in the moment it is issued.
Because these sit in the path itself, a comp that would breach an exclusion or a cap never becomes a comp. The guardrail is enforced at the point of authorization, alongside the DOA check, on the same millisecond-scale decision.
The decision, side by side
| Decision engine | Workflow engine | |
|---|---|---|
| Answers | Authority checks only | Escalations, reminders, holds |
| Latency target | Milliseconds | Off the critical path |
| In front of the terminal | Yes | No |
| Blocks the real-time response | No | No |
| Seals to the tamper-evident ledger | Yes — with matrix version | Yes — escalated outcomes |
Where to go deeper
Real-time authorization is the surface. Three parts underneath it each have their own guide:
- The matrix that every check resolves against — the delegation-of-authority matrix for casino comps.
- The record every decision is sealed to — building a defensible audit trail for comp approvals.
- The same governance applied to non-human requesters — AI-agent governance for casino comps.
Player-comp and loyalty systems issue value; AEGIS governs, authorises, and audits it, complementing your casino management system rather than replacing it.
Frequently asked questions
How fast is a real-time comp authorization decision?
An authority check against the delegation-of-authority matrix is answered in milliseconds. On our production host the median is about 6 milliseconds server-side, and because a dedicated engine answers only authority checks, the response is fast enough to sit in front of a live transaction without a staff member waiting on a spinner. Network time between the terminal and the server is additional.
What happens when a comp exceeds a staff member's limit?
It escalates automatically up the reporting line until it reaches someone whose authority covers it. At 3am that routes to the duty manager's mobile, not a day-shift desk. The escalation runs on a separate workflow engine, so it never blocks the real-time authority response on the floor.
Does the floor keep operating if a data centre fails?
AEGIS runs at two sites in different countries with continuous replication and automatic failover, typically within a few minutes. If a terminal cannot reach the service, the comp waits for a governed decision, except where the operator has switched on offline allowances: a host's phone can then grant within a small, expiring allowance issued beforehand, and every such grant is handed in and reviewed by a person, with anything outside the allowance flagged.
What checks run before a comp reaches a patron?
Exclusion checks and responsible-gaming caps and cooldowns, set per comp type, run before any incentive reaches a patron. They sit in the authorization path itself, so a comp that would breach an exclusion or a cap is stopped before value leaves, not flagged afterwards.
See AEGIS govern a live comp decision
Watch a comp checked against the authority matrix, escalated, and sealed — in milliseconds.
Book a demo →