Un agent de paiement du Trésor ne peut préparer ou débloquer un paiement que lorsque la demande est authentique, que chaque partie et itinéraire concernés ont un contexte actuel, que l'autorité déléguée est valide, que les sanctions et les contrôles de paiement renvoient un résultat exécutable et que tout vérificateur requis approuve la même instruction liée avant l'expiration. Une correspondance de sanctions potentielle, une contrepartie interdite, un compte invalide, un champ obligatoire incomplet, une violation d'autorité absolue ou un contrôle obligatoire indisponible arrête la libération.
Ce guide répond à une question limitée de mise en œuvre : comment gouverner une action d'agent qui prépare ou libère un paiement de trésorerie. Le guide régissant la lutte contre le blanchiment d'argent et les agents de paiement couvre le modèle opérationnel plus large de lutte contre la criminalité financière à l'échelle paneuropéenne. Cette page mappe une action de libération de paiement depuis l'entrée via la banque ou le rail de paiement et un Sealed Evidence Bundle. Il utilise allow, warn, require_approval et block comme résultats de politique. Les exemples sont synthétiques et ne comportent aucun seuil juridique. La portée et la fraîcheur de la source ont été examinées le 28 juillet 2026. Confirmez la loi, les programmes de sanctions, la liste des sources, les règles de paiement, les contrats et l'autorité interne qui s'appliquent à chaque entité juridique et voie.
Schéma de processus de bout en bout pour un déblocage de paiement de trésorerie
L'unité gouvernée est une instruction de paiement exacte. La séquence ci-dessous nomme chaque acteur, système, décision, approbation, étape d'exécution, résultat en aval et artefact de preuve. Des identifiants de corrélation et d'exécution stables rejoignent le chemin complet.
- 1. Le demandeur et le système source soumettent la demande de paiement. Les opérations de trésorerie reçoivent l'instruction via un canal approuvé. Le système d'admission enregistre le principal demandeur, l'identité du système source, l'authentification ou la signature du message, le résumé de la source, l'heure de la demande, la référence de la facture ou de l'obligation et l'artefact immuable de la demande de paiement.
- 2. L'admission valide l'authenticité et l'exhaustivité. Le contrôle d'admission confirme la source approuvée, le modèle, la signature ou l'authentification du message, les champs obligatoires et la clé en double. Une source non valide ou un champ obligatoire manquant renvoie un bloc et enregistre l'authenticité de la source et les artefacts de validation.
- 3. Le processus rassemble le contexte de paiement. Il lie le payeur, le bénéficiaire, le bénéficiaire, les comptes du payeur et du bénéficiaire, les banques et intermédiaires, les juridictions, la devise, le montant, l'objet, la date de valeur, la date limite, le rail de paiement et les résumés préalables pertinents à l'instruction de paiement.
- 4. L'infrastructure d'identité authentifie les acteurs. Le fournisseur d'identité du personnel authentifie le demandeur et tout réviseur. Le fournisseur d'identité de charge de travail authentifie le service et l'agent. Le service d'autorité résout l'objectif délégué, la portée du compte, l'accès aux outils, les limites de montant, l'environnement, l'expiration et la limite des données attribuée.
- 5. L'agent payeur du Trésor prépare la libération proposée. L'agent lit les champs approuvés, vérifie la demande, appelle les services de contrôle et de validation approuvés et propose une action « treasury.payment.release ». Il ne peut pas s'approuver, changer d'autorité, supprimer des preuves ou appeler le rail de paiement avant un résultat publiable.
- 6. Les systèmes de sanctions et de listes de surveillance contrôlent l'itinéraire. Le service de contrôle vérifie le payeur, le bénéficiaire, le bénéficiaire, les banques, les intermédiaires, les juridictions et les faits de propriété ou de contrôle par rapport aux sources de liste et aux enregistrements applicables de l'organisation, la version, le temps de récupération, le résumé, les entrées de requête, le résultat de la correspondance et l'état de l'arbitrage.
- 7. Les systèmes de contrôle des paiements évaluent l'instruction. Les contrôles déterministes couvrent les doublons, l'état de la contrepartie et du compte, la qualité des données, le montant et l'exposition globale, les anomalies, la vélocité, la coupure, la devise, la date de valeur et les restrictions de rail de paiement. Chaque résultat devient une contribution politique structurée et un artefact de preuve.
- 8. Le KLA Policy Engine évalue le contexte complet. La stratégie versionnée renvoie allow, warn, require_approval ou block, avec un ID de décision, des règles correspondantes, des codes de raison, un résumé de stratégie, un résumé d'entrées et une heure d'évaluation. Le résultat correspondant le plus fort contrôle l’exécution.
- 9. Decision Desk contient les demandes qui nécessitent une approbation. Un Decision Request présente le paiement exact, le résultat de la sélection, les contrôles, l'incertitude, les raisons politiques, l'identité du fabricant, les rôles de vérificateur requis, les limites d'autorité, l'expiration et le résumé des preuves. Les évaluateurs indépendants éligibles approuvent, rejettent, réaffectent ou font remonter la demande conformément aux règles du créateur-vérificateur et du multipartisme.
- 10. La porte de publication revalide l'instruction liée. Le processus vérifie le résumé de l'action, les champs de paiement, les versions de politique et de liste, les identités des réviseurs, le délai d'approbation, l'expiration, l'autorité, la date limite et l'état actuel de l'entreprise. Un contexte modifié ou obsolète crée une nouvelle évaluation et Decision Request.
- 11. La passerelle bancaire ou le rail de paiement exécute l'appel autorisé. Le service de libération envoie l'instruction liée avec une clé d'idempotence. La banque ou le chemin de fer reste l'exécuteur du paiement et les retours sont acceptés, rejetés, en attente, réglés, retournés ou inconnus avec sa propre référence.
- 12. Les opérations de trésorerie rapprochent le résultat en aval. Le processus enregistre le reçu du paiement ferroviaire, avant et après les résumés, l'état du règlement ou du retour, le résultat commercial, l'état de la nouvelle tentative et toute référence de rappel, de compensation, d'annulation ou d'incident.
- 13. Audit Trail et Lineage Explorer exposent l'enregistrement commandé. Les événements de demande, d'authenticité, d'autorité, de sélection, de contrôle de paiement, de politique, d'approbation, d'outil, de rail, de résultat, de révocation et de récupération restent regroupés sous un seul Lineage Record.
- 14. Evidence Room scelle les preuves. Un Sealed Evidence Bundle contient la population d'événements ordonnés, les artefacts de source et de filtrage, les décisions politiques et humaines, le reçu de paiement, le traitement de confidentialité, le manifeste, les hachages d'artefacts, les hachages d'enregistrement, les signatures et le résultat de la vérification indépendante.
Lier le contexte de paiement, l'autorité de l'agent, les outils et les données
Le contrôle et l'approbation des paiements dépendent de données précises sur les parties et les itinéraires. Préservez le payeur, le bénéficiaire, le bénéficiaire final, les identifiants de compte, les entités juridiques, les banques, les intermédiaires, les juridictions, la devise, le montant, l'objet, les factures, la date de valeur, la date limite, le rail de paiement et la provenance de la source. Tokenisez ou expurgez les identifiants exportés dans le cadre d’une politique de confidentialité documentée tout en préservant les jointures stables.
Conservez l'identité de l'agent, le principal demandeur, l'utilisateur délégué, l'identité du service et le propriétaire responsable attribuables séparément. Résolvez le mandat au niveau de la limite de publication : comptes payeurs autorisés, classes de paiement, outils, destinations, champs, objectif, devise, montant et limites globales, environnement, fenêtre horaire et limite de données. Une charge de travail authentifiée peut toujours manquer d’autorité pour ce paiement.
L'agent de paiement ne peut appeler que les outils approuvés d'admission, de sélection, de contrepartie, de grand livre de trésorerie, de politique, d'approbation et de passerelle de paiement. Chaque appel d'outil nécessite un ID et une version canonique de l'outil, une audience ou une destination, un résumé des arguments, une heure de demande et d'achèvement, un résumé des résultats et un enregistrement d'erreur ou d'effet en aval.
- Authenticité de la source : vérifiez l'identité du système source, l'authentification ou la signature du message, le modèle, l'ensemble de champs obligatoires, l'heure de la demande et le résumé de la source avant l'évaluation de la stratégie.
- Contexte de la partie et du compte : distinguez le payeur, le bénéficiaire, le bénéficiaire final, le compte débiteur, le compte créancier, les banques, les intermédiaires et les faits de propriété ou de contrôle.
- Juridiction et devise : enregistrez chaque juridiction qui régit les politiques juridiques, de sanctions, fiscales, de contrôle des changes, de données, de coupure ou ferroviaire, avec la devise et l'itinéraire applicables.
- Autorité déléguée : lie le mandat de l'agent à un objectif, une classe de paiement, une population de comptes, un ensemble d'outils, un ensemble de destinations, une tranche de montant, une exposition globale, un environnement et une expiration.
- Limite des données : expose uniquement les champs approuvés à l'agent et au service de contrôle. Préservez les données sensibles d'origine dans son système faisant autorité et exportez les références tokenisées lorsque la politique l'exige.
Actions autorisées et interdites
Définir l'autorité de l'agent sous forme d'opérations explicites. Rédiger, vérifier, proposer, approuver et publier entraînent des conséquences différentes. L’approbation d’un évaluateur ne peut pas élargir le droit sous-jacent de l’agent ni transformer une interdiction absolue en une action autorisée.
| Action | Autorité de l'agent | Contrôle requis | Preuve |
|---|---|---|---|
| Lire une demande de paiement approuvée | Autorisé dans la limite des données et l'objectif assignés | Source authentifiée, demande attribuée, liste d'autorisation des champs, mandat actuel | Demandeur, agent, ressource, objectif, champs, résumé de la source, décision de l'autorité |
| Valider les champs de partie, de compte, de montant, de devise et d'itinéraire | Autorisé avec des outils de validation en lecture seule | Contrôles versionnés et fermeture en cas d'échec règles relatives aux champs obligatoires | Résumé des entrées, version de validation, résultat, champs manquants ou conflictuels |
| Exécuter des vérifications de sanctions, de liste de surveillance, de doublons, d'anomalies, de vitesse et de coupure | Autorisé via les services approuvés | Versions actuelles de la source et des règles, entrées complètes, résultat enregistré | Service, version de liste ou de règle, requête résumé, résultat, heure, adjudication |
| Préparer une instruction de paiement | Autorisé dans le cadre de l'objectif et des comptes délégués | Identité distincte du préparateur et résumé d'action proposé immuable | Créateur, contexte de paiement, résumé d'action, heure de création |
| Soumettre une version de paiement liée | Autorisé sous condition après un résultat de politique exécutable | Autorité valide, contrôles en cours, approbations requises, capacité à usage unique, idempotence | Politique, approbations, liaison d'action, réception d'outil, effet en aval |
| Approuver sa propre proposition ou agir en tant que vérificateur | Interdit | Comparaison d'identité et application de rôles indépendants | Tentative bloquée, identité du fabricant, rôle requis, code de motif |
| Modification du bénéficiaire, du bénéficiaire, du compte, du montant, de la devise, de l'objet ou de l'itinéraire après approbation | Interdit en vertu de l'approbation existante | Comparaison résumée et réévaluation complète de tout changement important | Modification de l'enregistrement, approbation expirée ou annulée, nouveau résultat de la politique |
| Effacer une correspondance de sanctions potentielles ou modifier des preuves de sélection | Interdit sauf si un rôle d'arbitrage qualifié distinct est propriétaire de cette décision | Flux de travail d'arbitrage des sanctions et de source distincts | Faire correspondre les preuves, l'identité de l'arbitre, l'autorité, la justification, le résultat |
| Créer une autorité de révision, désactiver les contrôles, supprimer les preuves ou réutiliser l'approbation | Interdit | Opérations administratives refusées, décision à usage unique, chemin de preuve immuable | Tentative refusée, règle de politique, référence à la sécurité ou à l'incident |
| Libération via une banque, un chemin de fer, un compte, une juridiction ou informations d'identification | Interdit | Listes autorisées de destinations, d'audience, de comptes, de juridictions et d'informations d'identification | Appel bloqué, destination évaluée, codes de motif, référence d'informations d'identification |
Tableau de décision de seuil et d'approbation
Configurer les bandes à partir de l'analyse juridique de l'organisation, de l'évaluation des risques de sanctions et de la trésorerie mandat, risque de contrepartie, politique de liquidité, règles de paiement et données opérationnelles observées. Gardez chaque chèque visible indépendamment. Appliquez le résultat le plus fort dans cet ordre : block, require_approval, warn, allow.
Le tableau fournit une logique de contrôle testable et ne contient aucun seuil réglementaire universel. Les échantillons synthétiques utilisent EUR 125,000 et EUR 48,000 uniquement pour exercer des trajectoires politiques locales.
| Entrée de contrôle | autoriser | avertir | require_approval | bloquer |
|---|---|---|---|---|
| Montant et exposition globale | À l'intérieur de la bande de routine de l'agent et de toutes les limites par paiement, quotidiennes, de compte, d'entité et de devise | Près d'une bande d'exploitation locale ou inhabituelle par rapport au calendrier approuvé | Au-dessus de l'autorité du fabricant et dans les limites de l'autorité de contrôle nommée ; la règle multipartite s'applique lorsqu'elle est configurée | Au-dessus de l'autorité absolue, de la liquidité, de la contrepartie, du compte, de la devise ou de la limite légale |
| Sanctions et listes de surveillance | Toutes les vérifications requises effectuées avec les sources actuelles et un résultat clair | Signal de qualité des données à faible risque autorisé avec un suivi défini en vertu de la politique locale | Une politique locale achemine une correspondance potentielle résoluble vers un arbitre de sanctions qualifié avant toute décision de libération. | Interdiction confirmée, correspondance potentielle non résolue en vertu d'une politique de clôture en cas d'échec, source requise manquante, source périmée ou vérification obligatoire indisponible |
| Contrepartie, bénéficiaire et compte | Partie approuvée et compte avec propriétaire actuel, banque, juridiction et contexte d'objectif | Partie connue avec un changement non matériel limité sélectionné pour le suivi | Nouveau bénéficiaire, compte modifié, juridiction à risque élevé, changement de propriété ou condition de partie liée dans la politique approuvé | Partie interdite, compte fermé ou invalide, une banque ou un chemin de fer non approuvé, une juridiction interdite ou des informations sur la propriété requises pour le contrôle sont absentes |
| Qualité des données et authenticité de la source | Source approuvée, authentification valide, champs complets, identifiants cohérents, documents justificatifs actuels | Remplissez la demande avec un signal de normalisation ou de fraîcheur non matériel | Preuve non obligatoire contradictoire qu'un vérificateur autorisé peut être résolu avant la publication | Source invalide, signature échouée, champ obligatoire manquant, montant ou devise mal formé, identité de bénéficiaire conflictuelle ou instruction invérifiable |
| Anomalie | Le modèle correspond au calendrier de paiement approuvé, à la contrepartie, au montant, à l'heure, à la devise et à l'itinéraire | Déviation limitée au sein de l'autorité actuelle avec un suivi d'assurance défini | Nouveau modèle, séquence inhabituelle, nouvel itinéraire, demande en dehors des heures d'ouverture ou signal de modèle de matériau dans les limites approuvables | L'indicateur de fraude connu, l'état du modèle non contrôlé, la séquence interdite ou le service d'anomalie requis par la politique n'est pas disponible |
| Duplicata et idempotence | Aucune clé en double ou version équivalente antérieure ; une clé d'idempotence inutilisée | Duplicata possible en amont avec la preuve que la libération reste identifiée de manière unique | Une demande préalable ambiguë nécessite une résolution des opérations de trésorerie avant la libération | Duplicata confirmé, approbation réutilisée, clé d'idempotence réutilisée avec des arguments incohérents ou un effet réussi préalable |
| Vitesse et cutoff | À l'intérieur des limites de vitesse par agent, compte, contrepartie, entité et rail et avant la coupure | Près d'une vitesse locale ou d'une bande de coupure avec un temps de règlement suffisant | Un flux global élevé ou l'approche d'une coupure nécessitent un vérificateur nommé et un contexte de liquidité actuel | Dépassement de vitesse absolue, fenêtre fermée, date de valeur expirée, ou banque ou rail indisponible en vertu de la politique de fermeture en cas d'échec |
Matrice de responsabilité du fabricant-vérificateur
La préparation, la révision et la publication restent des tâches distinctes et testables. Le préparateur de paiement crée ou sponsorise l'instruction. Le vérificateur examine de manière indépendante les preuves liées. Le service de publication exécute uniquement l'instruction approuvée. Un arbitre des sanctions est responsable de la résolution des correspondances potentielles lorsque la politique locale le permet.
L'approbation multipartite nécessite que chaque rôle nommé décide sous l'autorité actuelle. Enregistrez la séquence, l'indépendance, les limites, le résumé des preuves, la décision, la raison et l'heure de chaque vérificateur. Une demande partiellement approuvée reste en attente.
| Activité | Préparateur de paiements | Vérificateur de trésorerie | Juge des sanctions | Service de libération | Propriétaire responsable |
|---|---|---|---|---|---|
| Authentifier la source et assembler le paiement | Responsable | Examiner les exceptions importantes | Consulté pour les champs de contrôle | Aucune action | Responsable de la procédure |
| Exécuter le contrôle et contrôles déterministes | Peut lancer | Examine les résultats | Responsable de l'évaluation des correspondances potentielles | Consomme les résultats finaux | Responsable des propriétaires assignés |
| Préparer la version proposée | Responsable en tant que créateur | Aucune modification de champ | Aucune modification de champ | Aucune action | Responsable du mandat |
| Approuver le montant ou l'exception de trésorerie | Inéligible pour sa propre demande | Responsable au sein de l'autorité actuelle | Consulté lorsque le contexte de sélection change | Aucune action | Responsable de la politique d'approbation |
| Résoudre une éventuelle correspondance de sanctions | Fournit des faits sources | Reçoit le résultat | Responsable sous une autorité distincte | Aucune action tant qu'elle n'est pas résolue | Responsable du programme de sanctions |
| Libérer l'instruction liée | Aucune libération directe lorsque le vérificateur est requis | Décision déjà enregistrée | Décision déjà enregistrée | Responsable d'un appel idempotent | Responsable du processus de paiement |
| Rapprocher les résultats bancaires ou ferroviaires | Responsable du suivi des opérations | Examiner les exceptions matérielles | Consulté pour l'état de suspension ou de libération des sanctions | Réception des dossiers | Responsable de l'état final |
| Révoquer, contenir et récupérer | Prend en charge la réconciliation | Prend en charge la décision | Possède les actions de réponse aux sanctions | Arrête les appels et réessaye | Responsable de l'incident et du redémarrage |
Définir l'expiration de l'approbation, la réaffectation et l'escalade
L'expiration est une limite d'autorisation. Définissez-le en fonction de la fraîcheur de la liste des sanctions, de la volatilité du contexte de paiement, du seuil, de la sensibilité au taux de change et à la liquidité, de la disponibilité des réviseurs et de la fenêtre de conservation sûre. La demande reste conservée jusqu'à ce que chaque vérificateur requis prenne une décision.
La réaffectation préserve le cessionnaire d'origine, la raison, les preuves, l'expiration et l'historique. Le remplaçant doit détenir une autorité égale ou supérieure pour la classe de paiement et le montant actuel. La réaffectation ne réinitialise jamais automatiquement l’expiration.
Escalader avant l'expiration vers le rôle défini par la stratégie. Une éventuelle correspondance de sanctions suit la voie de l’escalade des sanctions. Une panne bancaire ou ferroviaire suit les opérations de paiement et l’escalade de la résilience. Une demande expirée enregistre « expiré », n'effectue aucun appel à l'outil de version, actualise le contexte de filtrage et de paiement, évalue à nouveau la politique et crée un nouveau Decision Request.
| Condition | Action de file d'attente | État d'exécution | Preuve |
|---|---|---|---|
| Un seul vérificateur requis | Attribuez un vérificateur éligible avec autorité pour la classe de paiement et montant | Détenu jusqu'à l'approbation ; arrêté en cas de rejet ou d'expiration | Aperçu des rôles, comparaison des créateurs, décision, raison, heure, résumé des preuves |
| Approbation multipartite requise | Attribuez chaque rôle requis et conservez la séquence configurée | Conservé jusqu'à ce que toutes les approbations soient à jour et complètes | Un enregistrement par vérificateur, ordre, autorité, indépendance, expiration |
| Destinataire indisponible | Réaffecter à un vérificateur éligible et conserver l'affectation originale | Conservé jusqu'à l'expiration initiale | Destinataire précédent, nouveau destinataire, acteur, motif, heure |
| Expiration imminente | Escalader vers l'autorité égale ou supérieure configurée | En attente | Acteur de remontée, itinéraire, motif, heure, fenêtre restante |
| Expiré ou matériellement modifié | Fermez le Decision Request et réévaluez le contexte actuel | Arrêté ; une nouvelle demande est requise | Raison d'expiration ou de modification, aucun appel d'outil, entrées actualisées, nouvel ID de décision |
Enregistrez le résultat de la banque ou du rail de paiement
KLA enregistre la décision gouvernée et l'appel de libération instrumenté. La passerelle bancaire connectée ou le rail de paiement exécute le paiement et fait autorité pour l'acceptation, le rejet, le règlement, le retour et le rappel.
Utilisez une clé d'idempotence pour une instruction liée. Enregistrez le résumé des arguments, la destination, l'heure de la demande, la référence bancaire ou ferroviaire, l'état et le code de la réponse, les résumés avant et après, l'état du règlement ou du retour et la source de rapprochement. Une réponse API réussie peut toujours laisser le résultat commercial en attente ou inconnu.
Rapprochez le paiement avec une source bancaire ou ferroviaire obtenue de manière indépendante. Gardez les résultats en attente et inconnus ouverts. Acheminement d'un rejet, d'un délai d'attente, d'un effet partiel, d'un retour ou d'une nouvelle tentative incohérente vers les opérations définies ou le chemin de l'incident. Capturez chaque changement d’état ultérieur sous les mêmes identifiants de corrélation et d’exécution.
Mappez la séquence d'événements au schéma d'événement d'audit public
Le Schéma du journal d’audit de l’agent IA représente une action gouvernée depuis la demande jusqu'à la politique, l'approbation, l'exécution, le résultat, les preuves, la gestion de la confidentialité et la vérification de l'intégrité. Les détails de contrôle et de validation spécifiques au paiement restent des artefacts référencés par résumé à partir de l'enveloppe commune.
| Étape de séquence | Champ de schéma public | Enregistrement de paiement du Trésor |
|---|---|---|
| Enveloppe et corrélation | schema_version, audit_event.event_id, event_type, times, sequence, correlation | Identificateurs d'événement, de corrélation, d'exécution, de trace et de durée stables pour une instruction de paiement |
| Organisation et conservation | audit_event.scope | Référence d'organisation pseudonyme, environnement, région, classe de rétention, conservation légale |
| Demande, créateur, agent et propriétaire | audit_event.actors | Demandeur, utilisateur délégué, identité de service, agent, propriétaire responsable et fournisseurs d'identité |
| Versions de version | audit_event.components | ID d'agent, modèle, modèle d'invite et orchestrateur, versions et résumés de configuration |
| Proposition de paiement liée | audit_event.requested_action | Action, objectif, ressource de paiement tokenisée, limite de données, environnement, montant, devise, heure demandée |
| Contrôles de vérification et de paiement | audit_event.policy plus evidence.artifacts[] | La décision politique et les raisons font référence aux artefacts pour l'authenticité de la source, les listes de sanctions, le filtrage, les doublons, les anomalies, la vitesse, la coupure, la contrepartie et la qualité des données |
| Décision du fabricant-vérificateur | audit_event.approval | Decision Request, statut, heures, expiration, requis rôle, résumé des preuves, réviseur, décision, raison, justification, réaffectation ou exception |
| Appel de libération et effet ferroviaire | audit_event.tool_calls[] | Outil et version, action, destination bancaire ou ferroviaire, résumé des arguments, clé d'idempotence, résultat, effet en aval et références |
| Affaires et résultat de la récupération | audit_event.execution | Statut et heures d'exécution, résultat commercial atteint ou non résolu, annulation, rappel, retour, compensation ou référence d'incident |
| Enregistrement et artefacts ordonnés | audit_event.lineage et audit_event.evidence | Lineage Record ID, ID d'événement ordonnés, référence de manifeste, ID d'artefact, types et résumés de contenu |
| Gestion de la confidentialité | audit_event.privacy | Statut de classification, de tokenisation ou de rédaction, pointeurs JSON, méthodes et politique d'accès |
| Vérification de l'intégrité | intégrité | RFC 8785 canonicalisation, Hachage SHA-256 record, hachage du prédécesseur lorsqu'il est utilisé, signature Ed25519, vérificateur, heure, statut et codes d'échec |
Exemple d'exécution réussie et aseptisé
Cet exemple synthétique propose un déblocage de paiement de trésorerie EUR 125,000. Le chiffre est illustratif. Les sanctions et le contrôle des listes de surveillance sont clairs. Le montant traverse une bande de vérificateur-créateur locale, donc la politique renvoie require_approval. Un officier supérieur du trésor synthétique approuve la même instruction avant son expiration. L'outil de publication utilise une clé d'idempotence, la passerelle bancaire synthétique renvoie un récépissé d'acceptation et des rapports de vérification d'intégrité valides. Téléchargez l'échantillon JSON approuvé.
{
"schema_version": "1.0.0",
"audit_event": {
"event_id": "evt_synthetic_treasury_approved_20260728",
"event_type": "agent.action.completed",
"occurred_at": "2026-07-28T09:15:08.481Z",
"recorded_at": "2026-07-28T09:15:08.612Z",
"sequence": 18,
"correlation": {
"correlation_id": "corr_synthetic_treasury_approved_20260728",
"execution_id": "run_synthetic_treasury_approved_20260728",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"span_id": "00f067aa0ba902b7"
},
"scope": {
"organization_ref": "orgref_synthetic_eu_treasury_01",
"environment": "production-eu",
"region": "eu-west",
"retention_class": "regulated-payment-7y",
"legal_hold": false
},
"actors": {
"requester": {
"id": "usr_synthetic_treasury_maker_017",
"type": "user",
"display_name": "Synthetic treasury payment preparer",
"identity_provider": "workforce-iam"
},
"delegated_user": {
"id": "usr_synthetic_treasury_maker_017",
"type": "user",
"identity_provider": "workforce-iam"
},
"service_identity": {
"id": "svc_synthetic_treasury_agent_prod",
"type": "service",
"identity_provider": "workload-identity"
},
"agent": {
"id": "agent_synthetic_treasury_release",
"type": "agent",
"display_name": "Synthetic treasury payment-release agent"
},
"accountable_owner": {
"id": "role_synthetic_head_treasury_operations",
"type": "organization",
"display_name": "Synthetic head of treasury operations"
}
},
"components": {
"agent": {
"id": "treasury-payment-release-agent",
"version": "release-2026.07.28.1",
"configuration_digest": "sha256:65b95530f15bb617be582f2cd23a9bc4e9f4144623a43975266a6f7ce1510a2f"
},
"model": {
"id": "treasury-payment-context-model",
"version": "2026-07-10",
"configuration_digest": "sha256:8721063842a566d2d48c8ffc912b370e13846d0c9a2665f72a62e153c791d14d"
},
"prompt_template": {
"id": "treasury-release-system-prompt",
"version": "5.3.0",
"configuration_digest": "sha256:dc675cfacd5001e356062d0c82bb2cf4ddfa8417929e0d7cfdc1a7bba9f6c300"
},
"orchestrator": {
"id": "treasury-payment-release-process",
"version": "14",
"configuration_digest": "sha256:4499ee0f6418cfde2095492fd15833425502d6c387f8c1c11e81c37a4a4b4f4c"
}
},
"requested_action": {
"action": "treasury.payment.release",
"purpose": "release-approved-treasury-payment",
"resource": {
"type": "payment_instruction",
"id": "payment_synthetic_20260728_0042"
},
"data_boundary_ref": "boundary_eu_treasury_restricted",
"environment": "production-eu",
"amount": {
"value": "125000.00",
"currency": "EUR"
},
"requested_at": "2026-07-28T09:14:29.122Z"
},
"policy": {
"decision_id": "dec_synthetic_treasury_approved_20260728",
"policy_id": "treasury-payment-release-policy",
"policy_version": "7.2.0",
"policy_digest": "sha256:dfb0b86f9e69ed9613e6c347632ff1bf0813eb570439e01a18cd7e56c686091b",
"inputs_digest": "sha256:f3b9e01da2e24bea435b44b4c312a6d05de54075bf992bd6bb0ed79a22c07bc0",
"decision": "require_approval",
"evaluated_at": "2026-07-28T09:14:29.188Z",
"matched_rule_ids": [
"sanctions-screening-clear",
"approved-beneficiary-and-account",
"maker-checker-above-local-band"
],
"reason_codes": [
"screening_clear",
"amount_requires_senior_treasury_checker"
]
},
"approval": {
"request_id": "dr_synthetic_treasury_approved_20260728",
"status": "decided",
"requested_at": "2026-07-28T09:14:29.214Z",
"expires_at": "2026-07-28T09:44:29.214Z",
"required_role": "senior_treasury_officer",
"presented_evidence_digest": "sha256:fe7d8a9a4b28878e66443038d1896ea748a00b748cbe7fdc3341479b891816fe",
"reviewer": {
"id": "usr_synthetic_senior_treasury_031",
"type": "user",
"display_name": "Synthetic senior treasury officer",
"identity_provider": "workforce-iam"
},
"decision": "approved",
"reason_code": "screening_and_payment_context_verified",
"rationale_reference": "decision-note-synthetic-tokenized-031",
"decided_at": "2026-07-28T09:15:07.902Z"
},
"tool_calls": [
{
"call_id": "call_synthetic_payment_rail_20260728",
"tool_id": "bank-gateway.payment-release",
"tool_version": "2026-07-20",
"action": "release_payment",
"destination": "synthetic-bank-rail-eu",
"requested_at": "2026-07-28T09:15:07.944Z",
"arguments_digest": "sha256:5e7c5f9b53ac522ecdc5f476176053e61d72a78b9475386f046c4a6bf04f2a48",
"idempotency_key": "run_synthetic_treasury_approved_20260728:release-payment",
"status": "succeeded",
"completed_at": "2026-07-28T09:15:08.433Z",
"result_digest": "sha256:4a2f28f803051c238f66e218eec02e65691556c4b4128d482d1f8dd90a081e77",
"downstream_effects": [
{
"system": "synthetic-bank-rail-eu",
"effect_type": "payment_instruction_accepted",
"effect_reference": "rail-receipt-synthetic-20260728-0042",
"before_state_digest": "sha256:a5f3c6a11b62647f2cc95e50befb5b8e7e4ad9fe4f374691ddd6610f16297109",
"after_state_digest": "sha256:0932e223fcb9c36ea2cee608b9c2135f5dba43cd73ea1d6d593b7e6091ef5135"
}
]
}
],
"execution": {
"status": "succeeded",
"started_at": "2026-07-28T09:15:07.920Z",
"completed_at": "2026-07-28T09:15:08.481Z",
"business_outcome": {
"status": "achieved",
"summary": "The synthetic bank gateway accepted the approved payment instruction and returned a rail receipt.",
"reference": "outcome_synthetic_payment_accepted_0042"
},
"rollback": {
"status": "not_required",
"reference": "rollback-policy-synthetic-treasury-release"
}
},
"lineage": {
"lineage_record_id": "lin_synthetic_treasury_approved_20260728",
"ordered_event_ids": [
"evt_synthetic_payment_intake_0042",
"evt_synthetic_screening_clear_0042",
"evt_synthetic_policy_approval_required_0042",
"evt_synthetic_checker_approved_0042",
"evt_synthetic_rail_accepted_0042",
"evt_synthetic_treasury_approved_20260728"
]
},
"evidence": {
"manifest_ref": "bundle_manifest_synthetic_treasury_approved_20260728",
"artifacts": [
{
"artifact_id": "artifact_synthetic_source_authenticity_0042",
"artifact_type": "payment-source-authenticity",
"content_digest": "sha256:6c793181b83d28123a27328a2a5d65ce8dbcbb56f923649d7b43a22a9303c76d"
},
{
"artifact_id": "artifact_synthetic_sanctions_clear_0042",
"artifact_type": "sanctions-screening-result",
"content_digest": "sha256:a17aaf56c5bd7c85dc8e3d49c74ea01c79749668be8e93b3b2bf57c3908f27f3"
},
{
"artifact_id": "artifact_synthetic_approval_0042",
"artifact_type": "approval-decision",
"content_digest": "sha256:0859f92f8b7ec439bc004baad8b4fc93851c14bf0de8a3511619882e2d1db43b"
},
{
"artifact_id": "artifact_synthetic_rail_receipt_0042",
"artifact_type": "payment-rail-receipt",
"content_digest": "sha256:f27fede2220bcd326aee3bcff314c4dccfa3e5d5cb8b9287d06d654345ae29cd"
}
]
},
"privacy": {
"classification": "restricted",
"redaction_status": "tokenized",
"redactions": [
{
"json_pointer": "/actors/requester/id",
"method": "tokenized"
},
{
"json_pointer": "/requested_action/resource/id",
"method": "tokenized"
}
],
"access_policy_ref": "evidence-access-synthetic-regulated-treasury"
}
},
"integrity": {
"canonicalization": "RFC8785-JCS",
"hash_algorithm": "SHA-256",
"record_hash": "sha256:6f1d65f09f7bd8eea22bc06c76d58b9a983ab9066232f025245c5c5bee5f937d",
"signature": {
"algorithm": "Ed25519",
"key_id": "synthetic-treasury-sample-key-2026-01",
"public_key_spki": "MCowBQYDK2VwAyEAUENkPpZZtnjq0OZHXSf2GV7zpmIvHrd6L8LrONvUn8o=",
"value": "Ue+Naudajb+Tmv/Qm+k8c2p+SfVC/RKb9Xp6uWd9jyeZTVJnFrFxLXYJXAp2UZ4SpwAsNnAbYSCnuh90ghN8Cw=="
},
"verification": {
"status": "valid",
"verified_at": "2026-07-28T09:15:09.041Z",
"verifier": {
"id": "vendor-neutral-reference-verifier",
"version": "1.0.0"
},
"failure_codes": []
}
}
}Exécution négative des sanctions bloquées
Cet exemple synthétique enregistre une correspondance de sanctions potentielles et de liste de surveillance par rapport au contexte du bénéficiaire. La stratégie renvoie block avec les codes de motif « sanctions_watchlist_hit » et « beneficiary_requires_sanctions_adjudication ». L'événement ne comporte aucun appel d'outil, l'exécution reste « not_started » et le paiement reste inédit. Téléchargez l'exemple JSON de bloc de sanctions.
{
"schema_version": "1.0.0",
"audit_event": {
"event_id": "evt_synthetic_treasury_sanctions_block_20260728",
"event_type": "agent.action.denied",
"occurred_at": "2026-07-28T11:03:18.092Z",
"recorded_at": "2026-07-28T11:03:18.144Z",
"sequence": 5,
"correlation": {
"correlation_id": "corr_synthetic_treasury_sanctions_block_20260728",
"execution_id": "run_synthetic_treasury_sanctions_block_20260728",
"trace_id": "0af7651916cd43dd8448eb211c80319c",
"span_id": "b7ad6b7169203331"
},
"scope": {
"organization_ref": "orgref_synthetic_eu_treasury_01",
"environment": "production-eu",
"region": "eu-west",
"retention_class": "regulated-payment-denial-7y",
"legal_hold": false
},
"actors": {
"requester": {
"id": "usr_synthetic_treasury_maker_024",
"type": "user",
"display_name": "Synthetic treasury payment preparer",
"identity_provider": "workforce-iam"
},
"service_identity": {
"id": "svc_synthetic_treasury_agent_prod",
"type": "service",
"identity_provider": "workload-identity"
},
"agent": {
"id": "agent_synthetic_treasury_release",
"type": "agent",
"display_name": "Synthetic treasury payment-release agent"
},
"accountable_owner": {
"id": "role_synthetic_head_treasury_operations",
"type": "organization",
"display_name": "Synthetic head of treasury operations"
}
},
"components": {
"agent": {
"id": "treasury-payment-release-agent",
"version": "release-2026.07.28.1",
"configuration_digest": "sha256:65b95530f15bb617be582f2cd23a9bc4e9f4144623a43975266a6f7ce1510a2f"
},
"model": {
"id": "treasury-payment-context-model",
"version": "2026-07-10",
"configuration_digest": "sha256:8721063842a566d2d48c8ffc912b370e13846d0c9a2665f72a62e153c791d14d"
},
"prompt_template": {
"id": "treasury-release-system-prompt",
"version": "5.3.0",
"configuration_digest": "sha256:dc675cfacd5001e356062d0c82bb2cf4ddfa8417929e0d7cfdc1a7bba9f6c300"
},
"orchestrator": {
"id": "treasury-payment-release-process",
"version": "14",
"configuration_digest": "sha256:4499ee0f6418cfde2095492fd15833425502d6c387f8c1c11e81c37a4a4b4f4c"
}
},
"requested_action": {
"action": "treasury.payment.release",
"purpose": "release-approved-treasury-payment",
"resource": {
"type": "payment_instruction",
"id": "payment_synthetic_20260728_0099"
},
"data_boundary_ref": "boundary_eu_treasury_restricted",
"environment": "production-eu",
"amount": {
"value": "48000.00",
"currency": "EUR"
},
"requested_at": "2026-07-28T11:03:18.021Z"
},
"policy": {
"decision_id": "dec_synthetic_treasury_sanctions_block_20260728",
"policy_id": "treasury-payment-release-policy",
"policy_version": "7.2.0",
"policy_digest": "sha256:dfb0b86f9e69ed9613e6c347632ff1bf0813eb570439e01a18cd7e56c686091b",
"inputs_digest": "sha256:36cdde251024f5c6ba4a69127ee16b4fddbd3c2101995d9d8d0a135c54a9f16e",
"decision": "block",
"evaluated_at": "2026-07-28T11:03:18.081Z",
"matched_rule_ids": [
"sanctions-watchlist-potential-match",
"payment-release-fail-closed"
],
"reason_codes": [
"sanctions_watchlist_hit",
"beneficiary_requires_sanctions_adjudication"
]
},
"tool_calls": [],
"execution": {
"status": "not_started",
"business_outcome": {
"status": "not_achieved",
"summary": "The synthetic payment instruction remained unreleased because sanctions screening produced a potential match.",
"reference": "outcome_synthetic_sanctions_block_0099"
}
},
"lineage": {
"lineage_record_id": "lin_synthetic_treasury_sanctions_block_20260728",
"ordered_event_ids": [
"evt_synthetic_payment_intake_0099",
"evt_synthetic_sanctions_match_0099",
"evt_synthetic_policy_block_0099",
"evt_synthetic_treasury_sanctions_block_20260728"
]
},
"evidence": {
"manifest_ref": "bundle_manifest_synthetic_treasury_sanctions_block_20260728",
"artifacts": [
{
"artifact_id": "artifact_synthetic_source_authenticity_0099",
"artifact_type": "payment-source-authenticity",
"content_digest": "sha256:51621194f1179592adf5b28ed1273d74ea8a3e215563cad3134bc67c5b2e8484"
},
{
"artifact_id": "artifact_synthetic_sanctions_match_0099",
"artifact_type": "sanctions-screening-result",
"content_digest": "sha256:40bb1e4f2cfdad1809979b5768bab770c18cfef2c96fe74bd0458952a30a6858"
},
{
"artifact_id": "artifact_synthetic_policy_block_0099",
"artifact_type": "policy-decision",
"content_digest": "sha256:3dd5603753882085593a880d61c92e65e0ec758253c810b23e08dc7ba4cf2a32"
}
]
},
"privacy": {
"classification": "restricted",
"redaction_status": "tokenized",
"redactions": [
{
"json_pointer": "/actors/requester/id",
"method": "tokenized"
},
{
"json_pointer": "/requested_action/resource/id",
"method": "tokenized"
}
],
"access_policy_ref": "evidence-access-synthetic-regulated-treasury"
}
},
"integrity": {
"canonicalization": "RFC8785-JCS",
"hash_algorithm": "SHA-256",
"record_hash": "sha256:8d2eba7b69efc2cc5c78ffea6aa25abd93ffb4ceed8ba51801227bd4d27158c4",
"signature": {
"algorithm": "Ed25519",
"key_id": "synthetic-treasury-sample-key-2026-01",
"public_key_spki": "MCowBQYDK2VwAyEAUENkPpZZtnjq0OZHXSf2GV7zpmIvHrd6L8LrONvUn8o=",
"value": "9ARCGoapZmSSOlMss+P7S9UCkYYg1P9almO1s66dfqoLSrd+nln/J8hFoxFCf3DKW9A5Fg4TrFCRkKeljSDdBw=="
},
"verification": {
"status": "valid",
"verified_at": "2026-07-28T11:03:18.311Z",
"verifier": {
"id": "vendor-neutral-reference-verifier",
"version": "1.0.0"
},
"failure_codes": []
}
}
}Modes de défaillance et récupération
Testez le chemin complet sous les demandes mal formées, les listes obsolètes, les changements d'identité, les échecs de file d'attente, les tentatives, les pannes ferroviaires, les effets partiels et la récupération d'incident. Maintenez le processus dans un état sûr défini jusqu'à ce que la réconciliation en aval et les preuves requises soient terminées.
| Mode d'échec | Contrôle immédiat | Chemin de récupération | Preuve |
|---|---|---|---|
| Demande de paiement non authentique, mal formée ou incomplète | Renvoyez le bloc avant le filtrage ou la libération | Corrigez l'instruction source et soumettez une nouvelle demande | Identité de la source, champ ou signature échoué, décision, nouvelle référence de demande |
| Liste des sanctions, service de filtrage ou données requises indisponibles | Appliquer le bloc de fermeture sur échec configuré | Restaurer ou remplacer la source approuvée, réexaminer chaque partie et chaque itinéraire, réévaluer la politique | Statut de dépendance, version de la source, panne, filtrage actualisé, nouvelle décision |
| Correspondance des sanctions potentielles ou confirmées | Conserver le paiement non libéré et révoquer toute capacité de libération en attente | Acheminer les correspondances potentielles vers le processus de sélection qualifié ; suivre la procédure applicable de blocage, de rejet, de rapport ou de libération | Faire correspondre les entrées, la liste et le programme, l'arbitre, la base juridique, la disposition, le régulateur ou la référence d'incident le cas échéant |
| Demande en double ou clé d'idempotence réutilisée | Bloquer la réutilisation incohérente et interroger la banque ou le rail pour le résultat précédent | Réconcilier l'instruction originale ; créer une nouvelle instruction unique uniquement selon la procédure approuvée | Clés en double, résumés d'arguments, reçu préalable, décision de rapprochement |
| Réviseur indisponible ou conflit trouvé | Mettre la demande en attente | Réaffecter ou transmettre à un vérificateur éligible avant l'expiration initiale | Résultat du conflit, affectations, motif, instantanés d'autorité, heures |
| L'approbation expire ou le contexte de paiement change | Invalider l'autorisation de libération et effectuer aucun appel d'outil | Actualiser la source, la sélection, le compte, le montant, la limite, la politique et le contexte d'identité ; émettre un nouveau Decision Request | Expiration ou modification, approbation clôturée, entrées actualisées, nouvelle décision |
| La banque ou le chemin de fer rejette l'instruction | Enregistrez l'effet en aval rejeté et arrêtez les tentatives automatiques qui modifient les arguments | Corrigez la cause via une nouvelle instruction gouvernée ou clôturez le paiement | Référence ferroviaire, code, reçu, propriétaire décision, demande de remplacement |
| Le délai d'attente laisse l'état en aval inconnu | Empêcher un deuxième effet secondaire avec le même contrat d'idempotence | Interroger la banque ou le chemin de fer faisant autorité, rapprocher l'état accepté ou absent, faire remonter le statut non résolu | Délai d'attente, clé d'idempotence, résultat de l'enquête, état final, incident si nécessaire |
| Effet en aval partiel ou incorrect | Contenir les tentatives, révoquer l'autorité de libération, ouvrir un incident | Utiliser le chemin d'annulation, de rappel, de retour, de compensation ou de rapprochement manuel applicable | Effets engagés, résidu, incident, actions de récupération, résultat commercial final |
| Agent, identifiant, politique ou détection de compromission | Désactiver l'agent, révoquer les informations d'identification, refuser les appels d'outil, geler les files d'attente affectées | Étendre la population, réconcilier les effets en aval, restaurer les versions et les sources fiables, tester les contrôles, approuver le redémarrage | Résultats de la révocation, exécutions affectées, enquête, correction, test, décision de redémarrage |
| Les preuves requises ne peuvent pas être écrites ou scellées | Suspendre ou bloquer l'action en vertu du contrat de preuves | Restaurer les services de preuves, rapprocher chaque demande concernée, sceller les enregistrements complets avant la libération ou fermer en cas d'échec de contrôle | Échec d'écriture, population affectée, rapprochement, paquet terminé ou exception |
Conserver et exporter preuve de libération du paiement
Conserver l'ensemble de la population sous un calendrier de juridiction, de conservation légale, de confidentialité et d'enregistrement approuvé par l'organisation. Le manifeste de l'ensemble de preuves téléchargeable répertorie les événements et les artefacts commandés pour une version de paiement. Il relie également les deux échantillons, le schéma public et les étapes de vérification hors ligne pour un enregistrement individuel et le sceau du manifeste au niveau du lot.
Un Sealed Evidence Bundle doit contenir une preuve d'authenticité de la source, le contexte de paiement, les enregistrements d'autorité et de version, la source et le résultat du contrôle, chaque résultat de contrôle de paiement, les enregistrements de politique et d'approbation, le reçu exact de l'appel d'outil, le résultat bancaire ou ferroviaire, le rapprochement, les incidents ou la récupération, la lignée ordonnée, le traitement de confidentialité, les résumés d'artefacts, les hachages d'enregistrement, les signatures et les résultats de vérification.
Un examinateur peut valider le schéma JSON, recalculer les hachages d'enregistrements et d'artefacts, vérifier les signatures, reconstruire l'ordre, tester que l'approbation a précédé la libération, confirmer qu'une action bloquée n'a atteint aucun outil, comparer les clés d'idempotence avec les effets en aval et rapprocher le reçu du rail de paiement avec une source obtenue de manière indépendante.
Liste de contrôle de mise en œuvre
Utilisez la liste de contrôle de libération des agents de paiement du Trésor pour terminer la conception du contrôle pour une action. Il couvre l'encaissement des paiements et l'authenticité de la source ; payeur, bénéficiaire, bénéficiaire, comptes, juridictions, devise et montant ; identité et autorité déléguée; accès aux outils et Data Boundaries ; sources de dépistage ; règles de duplication, d'anomalie, de vitesse, de coupure et de seuil ; séparation des tâches ; actions autorisées et interdites ; fabricant-vérificateur et approbation multipartite ; expiration, réaffectation et escalade ; les résultats en aval ; rejet, annulation, incident et révocation ; conservation et exportation des preuves ; et l'approbation finale.
- Instruction de portée 1. Nommez la classe de paiement, les entités juridiques, les comptes, les devises, les juridictions, le chemin de fer, l'objectif, l'agent, le demandeur, le propriétaire, les outils et le contrat de preuve.
- Approuvez les règles de source et de contexte. Définissez les canaux authentiques, les champs obligatoires, les sources des parties et des comptes, la fraîcheur des données, les clés en double et le traitement de la confidentialité.
- Approuver les sources de filtrage. Enregistrez le champ d'application juridique applicable, les listes ou les données des fournisseurs, les règles de mise à jour et de synthèse, les entités filtrées, la politique de correspondance potentielle et le comportement en cas de panne.
- Publiez les tranches de décision. Donnez à chaque montant, contrepartie, qualité des données, anomalie, doublon, vitesse, seuil, devise et condition d'itinéraire un résultat explicite et un code de raison.
- Test de séparation. Prouvez que le créateur ne peut pas approuver ou libérer sa demande en attente, que chaque vérificateur détient l'autorité actuelle et que le contexte modifié invalide l'approbation.
- Testez les chemins positifs et négatifs. Validez les cas autorisés, avertis, approuvés, rejetés, expirés, bloqués, en double, panne, rejet de rail, résultat inconnu, effet partiel, révocation et récupération.
- Vérifiez les preuves hors ligne. Validez le schéma, les hachages, les signatures, l'ordre des événements, le calendrier d'approbation, les réceptions des outils, l'état en aval et les métadonnées de conservation.
- Approchez et examinez. Obtenez les approbations de trésorerie, de conformité aux sanctions, de criminalité financière, d'IAM, d'opérations de paiement, techniques, de risque et d'assurance avec une date de prochain examen.
Comment KLA met en œuvre le chemin de contrôle des paiements de trésorerie
Le KLA Control Plane a fourni des fonctionnalités de politique, d'approbation, de traçabilité, d'audit et de preuve pour les actions des agents instrumentés. Le KLA Policy Engine évalue le déblocage de trésorerie proposé et son identité actuelle, son autorité, sa sélection, son montant, sa contrepartie, la qualité des données, son anomalie, sa duplication, sa vélocité, sa limite, sa devise, son itinéraire et le contexte des preuves. Il renvoie allow, warn, require_approval ou block. Un résultat require_approval contient l'appel lié et crée un Decision Request pour Decision Desk. Un bloc empêche l'appel de paiement gouverné d'atteindre la passerelle bancaire ou le rail de paiement.
Pour les Decision Request du plan de contrôle, Decision Desk vérifie l'autorisation de décision, le rôle de réviseur requis, l'état en attente, l'identité du demandeur et du fabricant, ainsi que l'heure d'échéance. Il empêche les demandeurs et les créateurs enregistrés de décider de leur propre demande et rejette, approuve ou rejette les actions après le délai imparti. Un vérificateur éligible peut faire remonter une demande en retard. L'organisation doit fournir les identités actuelles des fabricants, les rôles requis, les délais et compléter les preuves de paiement et de sélection pour chaque parcours de production.
Lineage Explorer et Audit Trail exposent les enregistrements de stratégie, de décision humaine, d'outil, d'exécution et d'effet en aval. Evidence Room peut regrouper les enregistrements sélectionnés dans un Sealed Evidence Bundle avec des hachages d'artefacts, des signatures et une racine Merkle qui prend en charge les contrôles d'intégrité hors ligne.
La banque ou le système de paiement ferroviaire exécute le paiement et est propriétaire de son état de règlement. L'autorité chargée de la liste des sanctions ou le fournisseur de contrôle fournit les données de la liste et le service de mise en correspondance. Les fournisseurs d'IAM et d'identité de charge de travail authentifient les personnes, les services et les charges de travail des agents. KLA fournit la politique instrumentée, Decision Desk, le lignage, l'audit et le chemin de contrôle des preuves autour de l'action. L'organisation possède toujours l'analyse juridique et des sanctions, la qualité des listes et des contrôles, la classification des paiements, l'exhaustivité des données, les seuils, la compétence et le personnel des réviseurs, l'administration des identités et des droits, la connectivité bancaire et ferroviaire, les règles de liquidité et de coupure, la conservation, l'instrumentation complète, la réponse aux incidents, la récupération et le rapprochement.
Références techniques
Utilisez ces contrats publics pour inspecter la demande de paiement, le résultat de la politique, l'approbation, l'événement d'audit, le manifeste de preuves et l'enregistrement d'exécution joint.
Sources primaires et fraîcheur
Examen des sources terminé 28 juillet 2026. Les programmes de sanctions, les désignations, les réglementations, les normes de paiement, les règles de paiement et les politiques institutionnelles changent. Vérifiez à nouveau la source en direct, le programme applicable, l'analyse juridique locale et le règlement bancaire ou ferroviaire avant d'utiliser une décision de contrôle.
Pour la juridiction des États-Unis, le Service de liste des sanctions de l'OFAC fournit les données actuelles de la liste SDN et non-SDN. Le Framework pour OFAC Compliance Commitments de l'OFAC recommande un programme de conformité aux sanctions basé sur les risques, construit autour de l'engagement de la direction, de l'évaluation des risques, des contrôles internes, des tests et de l'audit, ainsi que de la formation pour les organisations soumises à la juridiction américaine et aux transactions étrangères pertinentes. Les règles applicables du programme OFAC déterminent si une organisation bloque, rejette, signale ou peut traiter une transaction.
Pour le Périmètre de l'Union européenne, la [aperçu des sanctions et liste consolidée des sanctions financières] de la Commission européenne (https://finance.ec.europa.eu/eu-and-world/sanctions-restrictive-measures/overview-sanctions-and-related-resources_en) reflète les actes juridiques adoptés par l'UE et est mise à jour si nécessaire. Le Règlement (UE) 2023/1113 s'applique dans le cadre de son champ d'application déclaré en matière de transfert de fonds et de crypto-actifs lorsqu'un fournisseur couvert est établi dans l'Union ; il traite des informations sur le payeur, le bénéficiaire, le compte ou l'identifiant de la transaction, la vérification, les informations manquantes, les contrôles des mesures restrictives et la conservation. Le règlement fournit des exigences juridiques pour les fournisseurs couverts. Chaque organisation doit définir son rôle juridique et son itinéraire de paiement. Sources : source source
Pour les mesures des Nations Unies, la Liste consolidée du Conseil de sécurité de l'ONU regroupe les personnes et entités répertoriées. Les États Membres mettent en œuvre les mesures attachées à chaque régime de sanctions applicable du Conseil de sécurité. L’organisation doit déterminer la mise en œuvre et les mesures nationales pertinentes pour sa juridiction et sa transaction.
Au niveau des normes internationales, la Recommandation 2025 FATF de juin 16 update aborde les responsabilités dans la chaîne de paiement, les informations standardisées sur les paiements transfrontaliers et les outils de protection contre la fraude et les erreurs ; Le GAFI a déclaré que les modifications révisées entreront en vigueur d'ici la fin du 2030. Les juridictions mettent en œuvre les normes du GAFI et chaque organisation fixe des seuils de paiement d'entreprise en fonction de son contexte juridique, contractuel, de risque et d'autorité applicable.
En tant que guides du secteur, les Wolfsberg Payment Transparency Standards traitent des paiements transfrontaliers et nationaux applicables, des prestataires de services de paiement participants, des informations sur les parties du message de paiement et de la capacité des parties de la chaîne à surveiller et à filtrer efficacement. Les Principes de Wolfsberg en matière d'IA et d'apprentissage automatique attribuent la responsabilité des utilisations liées à la criminalité financière à l'institution financière et traitent de l'objectif légitime, de l'utilisation proportionnée, de la conception et de l'expertise technique, de la responsabilité et de la surveillance, ainsi que de l'ouverture et de la transparence.
Pour les entités financières couvertes de l'UE, DORA, règlement (UE) 2022/2554 exige un cadre documenté de gestion des risques liés aux TIC, une gouvernance, une résilience, des incidents, des tests et des contrôles tiers dans son champ d'application. Pour un système d’IA qui entre dans le champ d’application à haut risque de la loi de l’UE sur l’IA, l’article 14 nécessite une surveillance humaine efficace, proportionnelle au risque, à l’autonomie et au contexte, y compris des capacités de surveillance, d’interprétation, de contournement, d’inversion, d’intervention et d’interruption sûre. La classification du système et le rôle juridique déterminent si l'article 14 applies.
Le modèle à quatre résultats, les tranches de montant synthétiques, la conception maker-checker, le mappage d'événements, les échantillons, la liste de contrôle et le manifeste de bundle contenus dans ce guide sont des modèles de mise en œuvre. Ils ne comportent aucun seuil universel en matière juridique, de sanctions, de comptabilité, de liquidité ou de paiement.
Foire aux questions
Un agent IA peut-il débloquer un paiement du Trésor ?
Une organisation peut autoriser un agent de paiement à soumettre une quittance uniquement dans le cadre d'un mandat explicite, après que les contrôles requis de source, d'identité, de sanctions, de contrepartie, de montant, de qualité des données, d'anomalie, de duplication, de vitesse, de coupure, de devise et d'itinéraire aient renvoyé un résultat exécutable. Les approbations humaines requises doivent couvrir la même instruction actuelle.
Quelles parties le contrôle des sanctions devrait-il couvrir ?
Filtrez les parties et l'itinéraire requis par la politique juridique et institutionnelle applicable. La conception du contrôle enregistre généralement le payeur, le bénéficiaire, le bénéficiaire final, les banques, les intermédiaires, les juridictions et les faits pertinents en matière de propriété ou de contrôle, ainsi qu'une liste des sources et des versions.
Comment la séparation fabricant-vérificateur devrait-elle fonctionner pour un agent de paiement ?
Enregistrez le préparateur de paiement en tant que créateur, acheminez la demande liée vers des vérificateurs éligibles indépendants, interdisez au créateur et à l'agent de décider de leur propre demande, séparez la modification des champs de l'approbation et laissez le service de publication s'exécuter uniquement une fois que chaque décision requise est en cours.
Quand un paiement du Trésor doit-il nécessiter une approbation ?
Exiger l'approbation pour les conditions qui dépassent l'autorité du fabricant et restent dans les limites de l'autorité d'un vérificateur éligible, telles que le montant configuré ou les tranches globales, un nouveau bénéficiaire, un compte modifié, un itinéraire à risque élevé, une anomalie, l'approche du seuil ou toute autre exception importante. Les interdictions légales et les violations de l'autorité absolue restent bloquées.
Que se passe-t-il lorsqu'un écran de sanctions renvoie une correspondance potentielle ?
Conservez le paiement non débloqué conformément à la règle de clôture en cas d'échec de l'organisation et acheminez le rapprochement vers un processus d'évaluation des sanctions qualifié lorsque la politique locale permet une décision. Préservez la source, la version de la liste, les entrées de requête, faites correspondre les preuves, l'autorité, la décision, la justification et l'action juridique ou opérationnelle qui en résulte.
Que se passe-t-il lorsque l'approbation du paiement expire ?
L'expiration invalide l'autorisation de libération. Enregistrez le Decision Request expiré sans aucun appel à l'outil de publication, actualisez le contexte de sélection et de paiement, évaluez la politique actuelle et créez une nouvelle demande lorsque le paiement reste éligible.
En quoi les contrôles d'idempotence et les contrôles en double diffèrent-ils ?
Les contrôles en double comparent les instructions commerciales, les factures, les parties, les comptes, les montants, les dates et les effets antérieurs. Une clé d'idempotence restreint les tentatives d'un appel d'outil lié. Utilisez les deux contrôles et réconciliez les résultats ambigus avec la banque ou le rail de paiement faisant autorité.
Qu'est-ce qui prouve que l'approbation a précédé le déblocage du paiement ?
Utilisez les ID d'événement et les horodatages ordonnés pour la demande, la stratégie, l'approbation, l'appel d'outil et l'achèvement. Liez l'action et les preuves présentées avec des résumés, enregistrez l'autorité de révision et l'expiration, joignez le reçu ferroviaire et vérifiez les hachages d'événements et d'artefacts signés.
KLA fournit-elle des listes de sanctions ou exécute-t-elle des paiements ?
KLA régit une action instrumentée par le biais de politiques, Decision Desk, de lignées, d'audits et de contrôles de preuves. L'autorité de sanctions ou le fournisseur de contrôle sélectionné fournit la liste des données et du contrôle. La passerelle bancaire ou le rail de paiement exécute et règle le paiement. Les fournisseurs d'identité authentifient les personnes et les charges de travail.
Qu'est-ce qui appartient à un ensemble de preuves de paiement du Trésor ?
Inclut l'authenticité de la source, le contexte du paiement et de la partie, l'identité et l'autorité, les versions des composants, les sources et les résultats du filtrage, les résultats du contrôle des paiements, la politique, chaque décision humaine, la réception de l'outil, le résultat ferroviaire, le rapprochement, les incidents ou la récupération, la traçabilité ordonnée, le traitement de la confidentialité, la conservation, les résumés d'artefacts, les hachages d'enregistrement, les signatures et les résultats de vérification.
Points clés à retenir
Une libération de paiement du Trésor régie lie une instruction authentique, un contexte complet de partie et d'itinéraire, l'autorité actuelle de l'agent, les sanctions et les résultats du contrôle des paiements, des décisions humaines indépendantes, un appel bancaire ou ferroviaire idempotent, le résultat en aval et des preuves vérifiables. Commencez par la liste de contrôle de libération des agents de paiement du Trésor, validez l'échantillon approuvé et l'échantillon de bloc de sanctions par rapport au schéma public, et utilisez le manifeste de l'ensemble de preuves pour un examen hors ligne.