Retour
    Cas d'usage · Banque

    Décidez sur la transaction pendant qu'elle est encore en vol.

    Paiements, fraude, risque et reporting partagent une propriété : la valeur d'une décision décroît en millisecondes. Un batch qui trouve la fraude à minuit l'a trouvée après le départ de l'argent.

    paiementsdétection de fraudescoring de risquereporting réglementaire
    Paiements

    Traitez le flux, pas la file d'attente

    Ingérez les événements d'autorisation et de règlement à mesure qu'ils arrivent. Déduplicquez les retries par clé, enrichissez avec l'état du compte, et routez chaque paiement à travers des stages de règles déterministes — les évidents passent en microsecondes, sans modèle dans le chemin.

    dedupenrichir · joinrègles · µsordre event-time
    Détection de fraude

    Des motifs sur une fenêtre, pas sur une ligne

    La fraude vit dans les séquences : pics de vélocité, montants fractionnés, bursts de nouveaux appareils. Des fenêtres glissantes avec countWhere / sumWhere / stddev scorent chaque compte en mouvement — et ne confient qu'aux cas ambigus un stage LLM pour un second regard raisonné.

    fenêtres glissanteschecks de vélocitéjoins flux-fluxllm sur les cas limites
    Scoring de risque

    Un score qui n'est jamais périmé

    L'agrégation stateful par clé maintient une exposition live par compte, contrepartie ou desk — mise à jour à chaque événement, interrogeable à tout instant. Les timers par clé déclenchent les actions dictées par votre politique : cool-downs, dépassements de seuil, flushs de fin de fenêtre.

    état par cléprocess + timersaggregate · reduceseuils
    Reporting réglementaire

    Des preuves, pas des tableurs

    Chaque décision laisse une trace : trace et trajectoire par événement, un flux d'audit auquel s'abonner, et un rejeu déterministe — rejouez les événements exacts derrière une décision signalée et montrez au régulateur précisément ce que le système a vu et pourquoi il a agi.

    flux d'audittime-travel par événementrejeu déterministeagrégats fenêtrés

    Pourquoi un moteur de streaming

    Les primitives dont la banque a besoin sont natives.

    Fenêtres event-time

    Les décisions suivent le moment où la transaction a eu lieu, pas celui où elle est arrivée. Les watermarks tiennent les événements en retard honnêtes ; les vrais retardataires atterrissent dans une dead-letter queue au lieu de fausser silencieusement vos chiffres.

    Esprit exactly-once

    Le séquencement côté producteur et les gardes d'idempotence dédupliquent les retries — un hoquet réseau ne devient pas un double débit, et le failover redémarre sans perte sur le chemin répliqué.

    Règles µs avant modèles

    La plupart des transactions se décident par règles et arithmétique en microsecondes. Le LLM ne voit que le résidu qui exige vraiment un jugement — la latence et la dépense restent bornées.

    Conçu pour un floor régulé

    Vos données ne quittent jamais votre périmètre.

    Auto-hébergé

    Le moteur tourne sur votre infrastructure — on-prem ou votre cloud. Les données de transaction ne transitent jamais par le SaaS d'un fournisseur.

    Durable par quorum

    Des clusters répliqués survivent à la perte d'un nœud sans perdre d'événement acquitté — la reprise est mesurée, testée, chaos-vérifiée.

    Audit d'abord

    Un flux d'audit auquel s'abonner, une trace W3C standard, et une trajectoire persistée pour chaque événement passé par une décision.

    Rejouable

    Le rejeu déterministe reproduit une décision passée bit-à-bit — la différence entre « on pense » et « on peut vous montrer ».

    À quoi ça ressemble

    Un pipeline anti-fraude tient dans un fichier.

    Scoring de vélocité en fenêtre glissante, règles pour les cas clairs, un LLM pour la zone grise, un case system à la fin.

    yaml
    1# pulse.yaml — card-fraud triage
    2source:
    3  kind: webhook        # auth events in
    4
    5stages:
    6  - name: velocity
    7    engine: streaming
    8    operators:
    9      - window: 5m sliding
    10        keyBy: card_id
    11        aggregations:
    12          tx_count:  count
    13          hi_amount: countWhere(amount > 500)
    14          spend:     sum(amount)
    15
    16  - name: triage
    17    engine: rule-based
    18    rules:
    19      - "tx_count > 20 || spend > 10000"
    20
    21  - name: judge
    22    engine: llm
    23    systemPrompt: |
    24      Given the velocity features, assess
    25      fraud likelihood and justify briefly.
    26
    27sink:
    28  kind: webhook        # case system / alerting
    29  url: ${secret:CASE_WEBHOOK}
    30
    1. 1

      Scaffold.

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

      Ajustez.

      Tailles de fenêtre, seuils et prompt sont de la config — le risque les possède sans passer par un cycle de redéploiement côté engineering.

    3. 3

      Déployez & observez.

      pulse deploy . && pulse events tail --topic fraud.judge.out

      Chaque score, en direct.

    4. 4

      Prouvez-le plus tard.

      Toute décision signalée peut être rejouée de façon déterministe contre les événements exacts qui l'ont produite.

    Attrapez-la avant le règlement, pas après.

    Voyez un pipeline anti-fraude scorer des événements live en quelques minutes — sans installation, sans inscription. Puis auto-hébergez sur votre propre floor.

    Essayer en live dans le playground

    Pulse est gratuit et auto-hébergé. HA multi-nœuds, géo-réplication et gouvernance sont inclus dans StreamFlow Enterprise.