1) Definitions: bonus vs credit vs equity
In broker operations, these words are often used loosely. Your CRM must not be loose. A robust design starts with clear definitions:
- Cash balance: funds deposited by the client (or funds that are withdrawable cash)
- Bonus balance: promotional funds with conditions and restrictions
- Credit: funds added under a risk/finance policy (often recoverable, limited, and controllable)
- Equity: cash + bonus/credit + unrealized PnL - fees (depending on platform and reporting)
The easiest way to reduce disputes is to be explicit about what is withdrawable. In most models, bonus is not withdrawable until a release condition is met. Credit may or may not be withdrawable based on policy.
2) Policy model: types, eligibility, restrictions
A "bonus system" is not one feature. It is a set of policies. Brokers usually need multiple bonus types with different rules.
Common bonus types brokers run
- Deposit bonus: e.g., 20% of deposit up to a cap
- Welcome bonus: first deposit only, often with stricter conditions
- Reload bonus: repeat deposits on a schedule
- Rebate/cashback: post-trade reward per volume (often safer than upfront bonus)
- Loss recovery credit: controlled credit used to stabilize retention, usually with strict limits
Eligibility controls
Eligibility is where fraud starts. Your CRM should support:
- KYC status gating (e.g., only verified clients)
- Country/region eligibility (compliance constraints)
- Account group and leverage restrictions
- Deposit method restrictions (some PSP rails have higher chargeback risk)
- One-per-client or one-per-household rules (policy decision)
Restrictions that must be explicit
- Whether bonus can be used for margin
- Whether withdrawals are blocked while bonus is active
- Which symbols count for turnover (and which do not)
- Time window for meeting conditions
- What events trigger cancellation (chargeback, policy breach)
3) Wallet and ledger rules (ledger-safe accounting)
Your CRM bonus system is only as good as your accounting model. If you mutate balances without a ledger, you cannot prove anything. Brokers need a ledger-first design: every change is an entry with reason, actor, and references.
Recommended wallet model
- Separate buckets: cash, bonus, credit
- Maintain a double-entry ledger or an equivalent auditable event log
- Use idempotency keys for all money-impacting operations (PSP webhooks, retries, manual actions)
- Store the bonus policy snapshot applied at the time of grant
Why policy snapshot matters
Brokers update promotions. If a policy changes later, you still need to explain why a specific client\'s bonus was restricted or clawed back. Storing the policy snapshot prevents "moving goalpost" disputes.
4) Turnover and volume calculation (what counts)
Turnover rules are where systems become inconsistent. You need a deterministic calculation that can be reproduced later.
Define eligible volume
Most brokers restrict turnover to avoid abuse:
- Count only specific symbols or symbol groups
- Exclude hedged volume or offsetting trades (policy choice)
- Exclude extremely short-duration trades (anti-abuse)
- Exclude trades during abnormal market conditions (rare, but sometimes used)
Volume normalization
Define how you normalize volume across symbols. The simplest approach is lots-based volume with symbol-specific multipliers. More robust models calculate notional volume. Whatever you choose, store the formula and the inputs used.
Turnover progress tracking
- Track progress per bonus grant (not just per client)
- Store which trades contributed to progress (or store an immutable derived snapshot per day)
- Handle late trade updates or corrections from the trading platform
5) Withdrawals, lockups, and release logic
Withdrawal behavior is what clients feel. If your withdrawal logic is ambiguous, you create tickets and disputes.
Common release models
- Locked bonus: bonus stays non-withdrawable; only profits become withdrawable after conditions
- Convertible bonus: bonus converts to cash when turnover target is met
- Partial release: a percentage releases per milestone
Withdrawal gating rules
- Allow withdrawal of cash deposits but cancel the bonus on withdrawal
- Block withdrawals until a minimum turnover is achieved
- Allow withdrawals but reduce bonus proportionally (requires careful math)
Whatever model you implement, your CRM must generate a clear explanation: what is withdrawable today, why it is limited, what the client needs to do to unlock it, and what will happen if they withdraw now.
6) Clawbacks and reversals
Clawback is not a feature; it is an incident response mechanism. Common clawback triggers:
- Deposit chargeback or deposit reversal
- Promotion policy violation
- Multi-account abuse confirmed
- Manual compliance action
Clawback design principles
- Clawbacks must be ledger events with references (PSP dispute ID, compliance case ID)
- Clawbacks should be idempotent (no double clawback on repeated webhook)
- Handle edge cases: bonus already converted, bonus consumed in margin, negative equity
7) Common abuse patterns and prevention controls
Every bonus policy will be tested. Your CRM should assume adversarial behavior from a small percentage of users.
Abuse patterns brokers see frequently
- Multi-account farming: many accounts harvesting welcome bonuses
- Deposit/withdraw cycling: using deposits to trigger bonuses then attempting quick cash-out
- Hedge turnover farming: opening offsetting trades to manufacture volume
- Short-duration scalping: generating volume with minimal market exposure
- Chargeback abuse: deposit for bonus then chargeback
Controls that reduce damage
- Eligibility gating on KYC and risk tier
- Device/IP heuristics and identity matching (policy + tooling)
- Turnover rules based on eligible volume, not raw volume
- Milestone-based release rather than instant conversion
- Maker-checker approvals for large credits and exceptions
8) Approvals, audit trails, and exception workflows
Bonus and credit operations must be auditable. The difference between a scalable broker and a support nightmare is workflow discipline.
Workflows brokers usually need
- Bonus grant: automated by deposit event or manual by staff
- Bonus cancellation: on withdrawal, on policy breach, or by compliance
- Credit grant: typically requires approval and documentation
- Bonus conversion: automated when conditions met, with a full evidence trail
- Clawback: linked to a chargeback/compliance case
Audit trail requirements
- Who performed the action (staff user ID)
- Why it was done (reason code + notes)
- What policy was applied (snapshot)
- References (deposit ID, PSP transaction ID, case ID)
- Before/after balances for cash/bonus/credit
9) Implementation checklist
- Define clear balance buckets and withdrawal rules
- Implement ledger-first accounting with idempotency
- Store policy snapshots at time of bonus grant
- Implement deterministic turnover calculation
- Build clawback and reversal workflows for chargebacks
- Instrument abuse prevention (eligibility, volume rules, approvals)
- Make every action auditable with reason codes and references
Where Brokeret fits
Brokeret helps brokers build operationally safe CRM workflows: wallet and ledger foundations, approvals, audit trails, payment integrations, and policies that can be enforced consistently. If you want a bonus and credit system that scales without disputes, we can help.