Operations: anti-fraud
Bricqs ships fraud controls in three layers: built-in (rate limits, idempotency, server-side scoring), configurable (velocity caps, identity rules, review thresholds), and your-side (CAPTCHA on cold traffic, payment-method binding, manual ops escalation). This page covers all three.
Key takeaways
Quick read- Server-side scoring is non-negotiable. Anything client-side gets gamed within hours of launch.
- Idempotency keys are the cheapest fraud control. Every grant, deduct, and event must have one.
- Velocity caps catch automated abuse before review queues fill up.
- Hold high-value rewards (jackpots, cash prizes) for 24 to 72 hours pending verification.
- Run a monthly fraud audit; trends matter more than individual cases.
Layer 1: built-in
What runs without configuration
Rate limits
1000 req/min/key, 5000 req/min/tenant. Burst 100/sec. Returns 429 with Retry-After. Most automation hits this before it can do damage.
Idempotency
Required on grants, deducts, and events. Same key inside 24h returns duplicate: true. Prevents replay attacks and accidental retries.
Server-side scoring
Engagement outcomes (spin, scratch, contest scoring) are decided on the server. The client animates to the predetermined result.
Auth scope checks
Participant tokens cannot call admin endpoints. Admin keys cannot impersonate. Scope mismatches return 403.
Tenant isolation
Every query is filtered by tenant_id. Cross-tenant data leaks are not possible via the API.
Audit log
Every admin action and high-value reward issuance is logged with actor, timestamp, IP, and request body. Queryable via /admin/audit-log.
Layer 2: configurable
What you turn on per program
Each contest, challenge, and engagement accepts a fraud config. Defaults are conservative; tighten by program where the prize value justifies it.
{
"id": "april_quiz_cup",
// ... other config
"fraud_rules": {
"max_score_per_minute": 1000,
"max_score_per_hour": 50000,
"max_rank_jump_per_hour": 200,
"block_disposable_emails": true,
"block_repeat_payment_methods": true,
"block_repeat_devices": true,
"review_threshold_score": 9000,
"auto_disqualify_on_velocity_breach": false
}
}review_threshold_score puts top entries in a manual review queue before prizes are paid. auto_disqualify_on_velocity_breach is off by default; humans review velocity flags.
Layer 3: your side
Controls Bricqs cannot ship for you
Things you must add to your stack:
CAPTCHA on cold traffic
hCaptcha, Turnstile, or reCAPTCHA on email gates and signup forms.
Bricqs cannot do this; the bot has to be stopped before it gets to your server.
Identity binding
Payment method, phone number, or government ID for high-value prizes.
Required by most jurisdictions for cash prizes above a threshold.
Email and phone verification
Block disposable email domains; require SMS OTP before claiming high-value rewards.
Bricqs ships a disposable list; you decide when to enforce.
Manual ops escalation
A queue your ops team checks daily.
Bricqs surfaces flagged entries; humans decide.
Channel-side controls
WhatsApp Business, your CRM, your ESP. Most spam-the-friend abuse is fixed
on those platforms, not in the loyalty engine.Webhooks
Subscribe to fraud signals
Events worth subscribing to:
fraud.velocity_breach
Fired when a participant exceeds a configured velocity cap.
Payload includes the cap, the observed value, and a 5-minute history.
fraud.suspicious_rank_jump
Fired when a contest entry climbs the leaderboard faster than expected.
Subject to false positives during legitimate spikes; humans review.
fraud.review_required
Fired when a high-value reward is held for verification.
Acknowledge in your ops tool; resolve via /admin/fraud/decisions.
reward.disqualified
Fired when a reward is denied after review.
Useful for support tooling and for de-listing the entry from leaderboards.Audits
A monthly cadence that scales
Disqualification rate by program
Should sit below 5%. Above 10% suggests the rules are too tight or the program is being targeted.
Top-percentile concentration
Top 1% of participants drive what share of total prizes? Above 60% is a flag for power-user gaming or a small abusive ring.
Repeat-IP and repeat-device share
Bricqs blocks at config; the audit confirms the block is firing. Persistently high counts suggest config drift.
Review SLA
Average time from review_required to resolution. Above 72 hours produces support tickets and damages brand.
Common mistakes
What goes wrong
Skipping idempotency keys to ship faster. Retries double-credit and the program leaks.
No exceptions. Every grant, deduct, and event has an idempotency_key. Format: participant : subject : period.
Auto-disqualifying on velocity. Legitimate users get banned during legitimate spikes.
auto_disqualify_on_velocity_breach=false by default. Humans review; let the queue do its job.
Not blocking disposable emails. Cold-traffic spin campaigns get scraped overnight.
Enable block_disposable_emails on engagements with prizes. Bricqs ships the list; you turn it on.
Ignoring fraud webhooks. Issues compound until finance notices.
Subscribe to fraud.* events. Route to your ops tool. Daily review keeps the queue manageable.
Putting CAPTCHA in front of authenticated users.
CAPTCHA belongs on cold traffic and on email gates. Logged-in users with verified identities should not be challenged repeatedly.
Developer FAQ
Common questions when integrating gamification with Bricqs.
Ready to ship?
Wire it up with the Bricqs SDK or API
Headless SDK for React UIs, REST API for any backend. Same engine behind both.