EN

TYPE D’ACTION · DÉPLACER DE L’ARGENT

Des paiements qui partent avant que quiconque vérifie le total.

Virements, transferts internes, remboursements, versements. Un agent qui peut appeler l’API de paiement déplace l’argent à la vitesse de l’API, et la règle qui aurait dû l’arrêter est souvent une phrase dans une politique.

Qui l’exécute aujourd’hui : Agents de trésorerie, scripts de versement, robots de remboursement, tâches de rapprochement.

Les règles qui l’encadrent d’habitude

  • Un plafond par paiement, souvent levé par une deuxième signature
  • Un plafond cumulé par jour, par compte ou par contrepartie
  • Un délai de carence après un bénéficiaire nouveau ou modifié
  • Une limite à la fréquence des changements de bénéficiaire

Des formes de règles typiques, pas une affirmation sur une organisation en particulier. Un pilote part des vôtres.

Où ce genre de règles casse

  1. Le plafond était conditionnel depuis le début.

    « Aucun paiement au-dessus de X sans deuxième signature » ne plafonne que les paiements non signés. Un paiement signé de n’importe quel montant passe, et personne ne le voit avant qu’on le demande à un solveur.

  2. Fractionnez, et chaque part est légale.

    Une règle par paiement ne voit pas de total. Plusieurs paiements sous le plafond déplacent plus que le plafond, une demande conforme à la fois.

Ce que fait la barrière

  1. 01

    Évalue chaque demande au regard de la politique avant son exécution. Ce qu’elle bloque ou refuse n’atteint jamais le système.

  2. 02

    Refuse quand une fenêtre ou une population dont dépend la règle manque ou ne concorde pas, au lieu de deviner.

  3. 03

    Scelle chaque décision, PROCEED, BLOCK ou REFUSE, pour qu’elle soit revérifiable sans nous.

Ce que vous pouvez vérifier aujourd’hui

PUBLIC

Un dossier de vérification scellé pour une règle de paiement d’exemple, vérifiable dans votre navigateur, et un labo où attaquer la même politique.

OUVRIR LE DOSSIER DE VÉRIFICATIONATTAQUER LA POLITIQUEDÉMARRER UN PILOTE