Bonus engine with abuse controls
Bonuses enforce their own terms: bet caps, payout ceilings, per game weighting, expiry and player wellbeing guardrails. Players watch progress update live.
Player engagement
Bet caps, payout ceilings, per game weighting and expiry are rules the engine applies as play happens, not terms somebody has to police afterwards.

A campaign is defined once: reward type, amount, wagering multiplier, contribution rules, expiry and a cap per player. From that point the engine applies those rules to every round as it settles, so what the terms say and what the platform does cannot drift apart.
Written as rules, not as copy
The campaign definition is the thing that runs. There is no second document for somebody to enforce by hand.
Applied while the player is playing
Rules are evaluated on the round rather than in a report somebody reads on Monday morning.
The abuse case closes itself
A term that holds during play does not arrive three weeks later as a chargeback and a reconciliation that will not balance.

Each one is set when the campaign is written and enforced from then on. None of them depends on somebody noticing a pattern in a weekly report.
A stake cap stops a bonus balance being pushed through in a handful of very large rounds.
The most a campaign can cost is decided when it is written rather than discovered once it is over.
Contribution rules decide which titles count towards wagering, and by how much each one counts.
A campaign closes on its own date, and the number of times one player can receive it is fixed in advance.
Limits that protect the player sit beside the ones that protect the margin, inside one campaign definition.
A player who can watch the terms being applied does not discover them at the moment they try to withdraw.
Progress that updates live
Wagering progress moves as rounds settle, with no refresh and no support ticket.
Which balance the bonus applies to
Real, bonus and locked funds are shown separately, so the amount that is theirs to withdraw is never a guess.
The rules attached to this bonus
Maximum bet, eligible games and the expiry date, stated where the bonus is rather than in a page of terms.
What is left to complete
The remaining wagering requirement, expressed as a number rather than a percentage nobody can act on.
The end of campaign surprise
Nothing about the payout ceiling or the stake cap arrives as news at the point of withdrawal.
The most common support contact
Most tickets are not about something going wrong. They are about not being able to tell whether it went right.
The argument after the fact
The record shows which rule applied and when, so a disputed bonus is a question with an answer.
Two recordings from the running platform, one of the campaign builder and one of the player record it acts on.
Bonuses
Configure incentives. Reward type, wagering terms, expiry and per player limits are set as rules the engine enforces.
Bonuses: Configure incentives. Reward type, wagering terms, expiry and per player limits are set as rules the engine enforces.
The engine owns the terms and their enforcement: what a campaign rewards, what it costs at most, which games count, how long it lasts, how many times one player can receive it, and what the player is shown while it runs. Every grant and every adjustment joins the same audit trail as deposits, withdrawals and staff actions, so a bonus question and a payments question are answered from one record.
This is a bonus engine, not campaign automation. Scalara does not replace a customer relationship platform, a customer data platform or a business intelligence suite, and it does not run affiliate management. Segmentation, lifecycle messaging and attribution stay with the tools you already use, and the boundary is written down in full on what we do not do.
The wellbeing limits described above are settings inside a campaign, available now. They are not the same thing as Harm-First Orchestration, the decision order that puts player harm and fraud ahead of commercial optimisation across the whole platform. That layer is in active development and is described as design intent rather than behaviour available today. Read how the decision order is designed for what it will and will not do.
The terms are enforced by the engine while the play is happening, not reconciled afterwards. A bonus carries its own bet cap, payout ceiling, per game weighting and expiry, and a bet that would breach one of them is refused at the point it is placed rather than clawed back later. The engine also reads the account it belongs to, so a player under a compliance hold or a wellbeing limit cannot use a bonus to work around it.
What it does not do is judge intent. A pattern that looks like organised abuse across several accounts is surfaced for a human to decide on, because that decision carries a duty to the player as well as to the business.
Not for the players already on it. A claimed bonus keeps the terms it was claimed under for its whole life, because changing them underneath a player is both a compliance problem and a fair treatment problem.
What you can do is close a campaign to new claims, or publish a new version with different terms that applies from that point forward. Every version is kept, and the audit trail records who changed what and when, so a regulator asking which terms a specific player agreed to can be answered from the record rather than from memory.
Each capability below is a row in the platform index, where its tier sits beside the method and the date behind it. Read the full feature matrix.
Bonuses enforce their own terms: bet caps, payout ceilings, per game weighting, expiry and player wellbeing guardrails. Players watch progress update live.
Deposits, bonuses and account events appear on the player's screen the moment they happen, with no refresh and no support ticket.
We will build it in the running platform and show you which limit would have caught it, and where the record of that would sit.
The session starts with your campaign and the problem it caused, not with a slide about our roadmap.