Intégration de la protection contre la fraude aux points
Flash protège le grand livre de points avec un modèle geler puis verdict : des détecteurs codés en dur fonctionnent la nuit et gèlent les points suspects dès qu'ils sont trouvés (toujours dans le dossier du membre, mais non utilisables et suspendus après expiration), puis SoClaw examine chaque retenue et annule, libère ou l'intensifie — via la même liste de travail MCP gouvernée que la reconquête.
Ce guide est destiné à l'opérateur/intégrateur exécutant l'agent. Pour un aperçu de l'entreprise, consultez la SoClaw page produit ; les outils de liste de travail s'appuient sur le serveur MCP gouverné dans le MCP Guide d'intégration et partagent la liste de travail des tâches d'agent avec le guide de reconquête.
Gel en cas de détection, décision après examen
Une alternative plus sûre au système d'attribution puis de récupération : les points sont bloqués dès qu'une règle est appliquée, ce qui empêche tout retrait pendant la vérification. Un lot gelé reste inscrit au registre, mais est exclu du solde disponible, de toute possibilité d'échange et de toute date d'expiration. Seul le verdict a un impact sur les points.
# Nightly, server-side (no agent involved):
for detector in enabled_detectors(team): # master switch + per-detector checkbox
for hold in detector.detect(team): # each hold = one entity, e.g. a referral or order
freeze(hold.targets) # FREEZE suspect points (idempotent, reversible)
enqueue(kind="fraud_points_hold", subject_key=hold.subject_key) # one review task
# Agent side (self-hosted OpenClaw + SoClaw decisions skill):
task = claim_agent_task(kind="fraud_points_hold") # NO_TASKS_AVAILABLE / AGENT_TASKS_DISABLED → STOP
facts = get_agent_task(task.id) # ids + signal + evidence (no PII)
complete_agent_task(task.id,
decision="block" | "allow" | "escalate", # block=void, allow=release, escalate=leave frozen
reason="<why>")Un signal unique ne se confirme jamais automatiquement. Un détecteur se contente de geler et d'ouvrir une revue — le block/allow/escalate La décision finale revient à l'agent (ou à un humain). Les abus détectables par machine (auto-parrainage, cycles de parrainage, limitation du nombre d'invitations, hachage des reçus en double) sont bloqués de manière synchrone ailleurs et n'atteignent jamais cette file d'attente.
Les détecteurs
Chaque option est une case à cocher facultative associée à un bouton principal. Seuls les signaux ayant une base réelle et vérifiable sont autorisés ; la prise de contrôle de compte, la revente de points et les opérations fictives sont délibérément exclues (aucun signal de contrepartie, d’instrument de paiement ou d’appareil ne permet de les détecter avec certitude).
same_household_referralUne recommandation convertie dont le référent et le référent sont un ménage confirmé (≥0,9) — une auto-référence probable.
Se bloque : Bonus de parrainage pour les deux parties.
refunded_order_unclawed_pointsUne commande intégralement remboursée ou annulée dont les points d'achat attribués sont toujours présents (non encore récupérés).
Se bloque : Les points d'achat de l'acheteur pour cette commande.
household_welcome_farmingUn foyer confirmé dans lequel deux membres ou plus détiennent chacun encore un bonus de bienvenue – possibilité d'agriculture multi-comptes.
Se bloque : Bonus de bienvenue pour chaque membre signalé.
zombie_referralParrainage récompensé il y a plus de 30 jours, mais le membre invité n'a jamais passé de commande depuis — une inscription probablement fictive.
Se bloque : Bonus de parrainage pour les deux parties.
order_velocity_burstUn membre qui a passé un nombre inhabituellement élevé de commandes dans une courte fenêtre avec les points toujours non dépensés – un proxy de wash-trading.
Se bloque : Points d'achat toujours présents suite à l'afflux de visiteurs.
behavior_outlierUn membre dont l'activité de points sur 30 jours (nombre de transactions, points accumulés, nombre d'échanges) présente une valeur aberrante statistique extrême (score z robuste ≥ 6) par rapport à la distribution des membres de l'équipe.
Se bloque : Les points toujours présents du membre depuis la fenêtre aberrante.
Dans behavior_outlier — le détecteur statistique
Contrairement aux cinq détecteurs de règles, behavior_outlier évalue l'activité de points de chaque membre sur 30 jours par rapport à la distribution de l'équipe (trois indicateurs par membre : nombre de transactions, points accumulés et nombre d'échanges), à l'aide d'un score z robuste (médiane + MAD, afin que quelques gros clients ne puissent pas fausser la référence).
z = (x − median) / (MAD × 1.4826) # per feature, vs the team's own members
flag when z ≥ 6- Étages avant tout déclenchement. Le membre doit avoir effectué au moins 10 transactions de gains dans la fenêtre, et l'équipe doit avoir au moins 50 membres actifs pour constituer une base de référence ; en dessous de ces seuils, le détecteur ne produit aucun signal.
- Même pipeline de gel → révision. Le gel s'exécute avant la mise en file d'attente de la tâche de révision ; Les lots gelés restent inscrits (inutilisables, leur expiration est suspendue) ; la décision (libération / annulation / escalade) est prise par SoClaw ou un humain – jamais de sanction automatique.
- Un seul avis par membre et par mois au maximum. L'objet est défini sur
behavior_outlier:{memberId}:{YYYYMM}et les membres ayant déjà un lot gelé sont ignorés (pas de surnombre). - Désactiver comme les autres. Une case à cocher par détecteur, activée par défaut lorsque le type de tâche de fraude est activé pour l'équipe.
- Preuve tangible. Chaque fonctionnalité signalée dans la charge utile de la raison comporte
{value, teamMedian, robustZ, flagged}ainsi que les seuils appliqués : le réviseur voit précisément pourquoi le membre a été signalé, et non une note.
Sémantique des verdicts
| Décision | Effet |
|---|---|
block | Fraude confirmée : les points gelés sont annulés (supprimés définitivement, ne seront jamais réutilisés). |
allow | Fausse alerte : les points sont remis à disposition. Une période de grâce est accordée pour éviter toute pénalité en cas d'expiration tardive. |
escalate | Pas clair – les points restent gelés et l’affaire est laissée à un humain. Recommandé lorsqu'un seul signal ne suffit pas pour juger. |
Chaque effet passe par une écriture idempotente existante — le gel, l'annulation et la libération sont indexés par (action, hold, member), et l'effet est appliqué avant la finalisation de la tâche, de sorte qu'un bail perdu ne laisse jamais une modification partiellement appliquée. Aucun nouveau moyen de générer des revenus pour l'agent.
Contrôles d'administration et sécurité intégrée
- Interrupteur principal — La détection de fraude est désactivée jusqu'à ce qu'un propriétaire/administrateur de l'organisation active la tâche de blocage des points pour l'équipe, et qu'un interrupteur de désactivation de la plateforme la bloque globalement. Les deux doivent être activés pour que toute détection soit effectuée.
- Liste de vérification par détecteur — chaque détecteur est une case à cocher (aucun paramètre enregistré = activé lorsque le maître est actif). Désactiver un détecteur désactive uniquement la vérification correspondante.
- Escalade de mise en attente obsolète : une mise en attente sans verdict après deux semaines est automatiquement transmise à un humain. Les points restent gelés : ils ne sont jamais libérés automatiquement (la fraude ne peut pas attendre) ni annulés automatiquement (le membre peut être innocent).
- Audit complet — Les actions de gel, d'annulation, de levée et d'escalade sont toutes consignées dans la liste de tâches avec leur motif ; aucune décision n'est prise sans suivi.