BeAware decides what happens next. Configurable rule trees across multiple brands, jurisdictions, and event types — no code changes, no deployments, just configuration. Rules fire in real time as events arrive on the bus, not on the next scheduled job.
Every PAM event — sign-up, deposit, wager, KYC update, loss pattern, withdrawal — flows onto the message bus. BeAware consumes them, evaluates configured rule trees, and fires actions in parallel. Operators own the rules; developers don't need to ship code to change behaviour.
Graph-based editor for triggers, conditions, and actions. No SQL, no DSL, no code reviews to add a new bonus rule.
Rules fire from the RabbitMQ event bus the moment the event lands. No cron lag, no batch windows.
Hundreds of independent rules across brands and jurisdictions evaluate in parallel — none blocks another.
Rules are scoped to brand and jurisdiction. A Sweden-only SOW flag never fires on a Curaçao deposit.
Bonus credit, email, SMS, CRM postback, segment update, account flag, withdrawal hold, limit change, support ticket.
Every rule evaluation logged with inputs, branch taken, and actions fired. Replayable from the back-office.
First deposit triggers a 100% match; second deposit gets free spins; third triggers a CRM follow-up. All configured per brand, with cap and wagering rules attached.
Repeated session losses trigger a responsible-gaming overlay before the next deposit attempt. Thresholds tuned per jurisdiction.
When KYC verifies and source-of-wealth clears, deposit and withdrawal limits update on the player's wallet without operator intervention.
Multiple deposits from new IPs in a short window automatically place withdrawals on hold and open a back-office ticket for the risk team.
BeAware doesn't run on a schedule. It consumes domain events from the PAM message bus the instant they're published — and every step of the evaluation is logged for replay.
Sign-up, deposit, wager, KYC update, withdrawal — every state change in PAM emits an event with the player, brand, jurisdiction, and payload. BeAware consumes from a dedicated queue with retry semantics.
The rule registry finds every active rule whose trigger matches the event type and is scoped to the player's brand and jurisdiction. Hundreds of rules can match; they evaluate in parallel.
Each rule walks its condition tree. Branches that don't apply short-circuit. The evaluation has access to the player record, current wallet, KYC status, segment, and any rule-specific lookups configured in the editor.
Each action dispatches through the relevant PAM service: bonus credit, email send, CRM postback, segment update, account flag, withdrawal hold, support ticket. Failures are retried; the audit row captures the full chain.
BeAware is not a separate product to deploy and maintain — it's a worker service in the same .NET solution as PAM, sharing the same auth, audit, and back-office shell.
Subscribes to the same message bus PAM uses. No new infrastructure to operate.
Independent rules run concurrently. A slow third-party callback in one action never blocks the next event.
Every saved rule is versioned. Roll back to a previous version if a new rule misbehaves.
Rules are scoped at the database level. Sweden-only rules cannot accidentally fire on a Curaçao deposit.
Past events can be replayed against a new rule version to preview impact before turning the rule on for live traffic.
The rule editor lives in the PAM back-office shell. Same login, same RBAC, same audit pipeline as the rest of the platform.
We'll walk you through how operators currently use the visual editor to manage hundreds of rules across brands and jurisdictions — and how it's wired into the rest of the platform.