Aller au contenu principal

De bout en bout : triage de fraude carte

Avancé ⏱ 25 min banking · bout en bout · les quatre moteurs

Vous allez construire : le pipeline de fraude complet du use case Banking : vélocité par carte dans une fenêtre glissante, triage déterministe en microsecondes, un LLM qui ne statue que sur la zone grise, et un webhook vers votre case system. La promesse de la page marketing, rendue exécutable.

événements d'autorisation → streaming:velocity → rule-based:triage → llm:judge → webhook (case system)

Prérequis

  • Le démarrage rapide terminé (Pulse local en marche).
  • Un provider LLM pour l'étape 4 — ANTHROPIC_API_KEY ou Ollama local. Sans provider, arrêtez-vous après l'étape 3 : la moitié déterministe du pipeline est déjà un détecteur fonctionnel.
  • Une URL de webhook pour recevoir les cas (une URL webhook.site convient pour l'exercice).

1 · Générez les quatre stages

pulse new fraud --source webhook \
--stage streaming:velocity --stage rule-based:triage --stage llm:judge \
--sink webhook

2 · Le stage velocity — des features par carte dans une fenêtre glissante

stages:
- name: velocity
engine: streaming
operators:
- { type: keyBy, field: card_id }
- type: window
spec: "sliding(5m,1m)"
aggregations:
tx_count: "count()"
spend: "sum(amount)"
hi_amount: "countWhere(amount > 500)"

Chaque carte a sa propre fenêtre ; chaque agrégation est validée au deploy.

3 · Le stage triage — les cas évidents ne coûtent jamais un token

- name: triage
engine: rule-based
rules:
- { condition: "tx_count > 20 || spend > 10000", action: flag }

Seules les fenêtres qui cassent les seuils de vélocité passent — le LLM ne verra jamais le trafic normal.

4 · Le stage judge — raisonner sur le reste

- name: judge
engine: llm
systemPrompt: |
Tu reçois des features de vélocité par carte qui ont
franchi les seuils de fraude. Évalue la vraisemblance
(low|medium|high), justifie en une phrase, et
recommande : allow, review ou block.
temperature: 0.2

5 · Le sink — les cas sortent

pulse secret set CASE_WEBHOOK https://webhook.site/<votre-id>
sink:
kind: webhook
url: ${secret:CASE_WEBHOOK}

6 · Déployez et simulez une carte qui chauffe

pulse secret set PULSE_WEBHOOK_SECRET dev-secret # la source webhook générée l'exige
pulse deploy .
for i in $(seq 1 25); do
pulse events publish --topic fraud.in --value '{"card_id":"c-77","amount":'"$((RANDOM % 900 + 100))"'}'
done

7 · Observez chaque altitude de la décision

pulse events tail --topic fraud.velocity.out # les features s'accumulent par carte
pulse events tail --topic fraud.triage.out # le moment où les seuils cassent
pulse events tail --topic fraud.judge.out # le verdict du modèle sur la fenêtre signalée

Et vérifiez votre récepteur webhook : le cas est arrivé avec les features de vélocité et la recommandation du LLM.

8 · Prouvez l'isolation

pulse events publish --topic fraud.in --value '{"card_id":"c-01","amount":25}'

c-01 construit sa propre fenêtre tranquille : jamais signalée, jamais jugée, jamais un token dépensé. Cette asymétrie — des règles en µs pour la masse, le jugement du modèle pour les rares — c'est l'économie de tout le design.

Ce qui vient de se passer

Vous avez composé les quatre altitudes de décision dans un seul fichier déclaratif et regardé un flux d'événements se trier lui-même : autorisations brutes → features par carte → signalements déterministes → verdicts raisonnés → un cas traité. Chaque étape intermédiaire est un topic durable que vous avez suivi — c'est aussi votre histoire d'audit : le raisonnement du pipeline est inspectable à chaque couture.

Dépannage

Rien n'atteint triage

La fenêtre doit vraiment casser un seuil : 25 événements en moins de 5 minutes sur un même card_id suffisent. Vérifiez d'abord fraud.velocity.out — si les features coulent mais aucun signalement, vos seuils sont plus hauts que la rafale simulée.

judge est unhealthy

Aucun provider LLM configuré. Exportez ANTHROPIC_API_KEY (ou pointez vers Ollama) et redémarrez — ou arrêtez-vous à l'étape 3 et livrez le détecteur déterministe ; il est déjà utile.

Ensuite