1. Définir la décision d'acquisition
La question d’investissement est de savoir si la cible possède un système reproductible qui convertit l’intention déléguée en paiements autorisés, acceptés et collectés avec une perte limitée. L’acheteur doit éviter de valoriser une interface agent comme s’il s’agissait d’une activité de paiement. La valeur découle de la chaîne complète d'autorité, d'identité, d'informations d'identification, d'acceptation du commerçant, de traitement, de contrôle de la fraude, de preuves de litiges, de règlement et de résultats pour les clients.
Le périmètre de diligence doit inclure chaque entité et service qui influence la transaction. Un agent commercial peut assembler un panier, une surface de confiance peut recueillir le consentement, un fournisseur d'informations d'identification peut libérer un jeton, un commerçant peut accepter la commande et un processeur, un réseau, un émetteur et un acquéreur peuvent autoriser et régler le paiement. Une défaillance à n’importe quelle interface peut réduire la conversion, augmenter la fraude, créer des responsabilités ou interrompre les liquidités.
Le conseil d'administration doit définir la décision précise avant le début de la diligence. Il doit indiquer quels produits, rails, juridictions, licences, types de clients, droits technologiques, relations réseau et actifs de données soutiennent le prix. Il convient également de définir quelles capacités futures restent contingentes. Une démonstration de protocole, un protocole d'accord ou un projet pilote ne peuvent pas apporter la même valeur que les transactions de production qui correspondent à la livraison par le commerçant, aux résultats des litiges et aux revenus collectés.
L'unité de valeur proposée est un paiement initié par un agent dont l'autorité, le paiement, les informations d'identification, le résultat du traitement, l'exécution et l'argent liquide peuvent être reconstitués. Les mesures du portefeuille doivent regrouper uniquement les transactions qui répondent aux mêmes normes de preuve.
2. Définir précisément un paiement initié par un agent
Un paiement initié par un agent est un transfert dans lequel un logiciel agissant sous autorité déléguée effectue une partie importante de la sélection du produit, de la formation du paiement, de la sélection de l'instrument de paiement, de l'authentification ou de l'exécution. La définition devrait distinguer l’assistance de l’autonomie. Une interface conversationnelle qui suggère un produit avant qu'un humain n'effectue le paiement crée un risque différent de celui d'un agent qui achète sans présence humaine contemporaine.
L'acheteur doit classer les flux par mode d'autorité, rail de paiement et canal d'exécution. L'autorité peut être spécifique à une caisse, ouverte dans le cadre d'un budget et d'un commerçant défini, récurrente, déclenchée par un événement ou révocable. Les rails peuvent inclure des cartes, des transferts de compte à compte, des portefeuilles, des paiements en temps réel ou des actifs numériques. L'exécution peut avoir lieu via un commerçant API, l'automatisation d'un navigateur, un protocole commercial ou un échange d'agent à agent.
La pile technologique doit être cartographiée depuis l’instruction jusqu’au règlement. Les modèles peuvent interpréter l’intention, comparer les produits ou choisir un mode de paiement. Les services déterministes doivent appliquer les limites de dépenses, les restrictions des commerçants, la portée des informations d'identification, la fraîcheur des informations occasionnelles, l'authentification et la politique. La spécification AP2 stipule que les responsabilités de vérification doivent s'exécuter dans un code déterministe même lorsqu'un agent participe au flux plus large.[1]
Le langage marketing ne doit pas définir le périmètre. L’équipe de diligence doit reproduire des transactions échantillonnées et identifier le point exact auquel l’intention humaine devient une instruction exécutoire par la machine.
3. Cartographier les participants, les rôles et les dépendances
Le commerce agent ajoute des rôles à une chaîne de paiement déjà distribuée. AP2 décrit les rôles d'agent d'achat, de fournisseur d'informations d'identification, de commerçant, de processeur de paiement du commerçant et de surface de confiance.[1] Les implémentations de réseau introduisent l'enregistrement des agents, la tokenisation et les contrôles de schéma.[3][4] Une cible peut remplir plusieurs rôles ou les déléguer à des fournisseurs.
L’acheteur doit créer une carte d’entité juridique et de responsabilité. Pour chaque rôle, il convient d'identifier le service, la partie contractante, la licence, l'activité réglementée, les données traitées, l'autorité de décision, le propriétaire du contrôle, les revenus, le coût, l'indemnisation, l'assurance et les conséquences de l'échec. Lorsqu’une entité remplit plusieurs rôles, la gouvernance devrait empêcher qu’une incitation commerciale ne l’emporte sur un contrôle indépendant.
La délégation nécessite une chaîne explicite. Une plateforme peut s'appuyer sur un fournisseur d'identité, un portefeuille, un service cloud, un fournisseur de modèles, un fournisseur de fraude, un service de jetons, un acquéreur et un réseau. L'acheteur doit vérifier si chaque délégation est contractuellement autorisée, techniquement observable, opérationnellement supportée et transférable en cas de changement de contrôle.
La concentration doit être mesurée par la dépendance économique et la substituabilité. Une plate-forme théoriquement multi-fournisseurs peut toujours dépendre d'un seul réseau, fournisseur d'informations d'identification ou intégrateur marchand pour la plupart des volumes. Le délai de remplacement, la certification, le consentement du client et la portabilité des données doivent figurer à la fois dans la planification de la valorisation et de l'intégration.
4. Construisez la pile d'autorité
La permission n'est pas un événement. Une pile d'autorité robuste connecte l'utilisateur, l'agent, l'instruction, le paiement, les informations d'identification, le commerçant, le montant, l'heure et l'exécution. Chaque niveau doit avoir un émetteur, un vérificateur, une portée, une expiration, un mécanisme de révocation et un enregistrement d'audit durable.
L’acheteur doit faire la distinction entre l’intention générale et l’autorité de transaction. Une instruction telle que « réserver un hôtel approprié sous USD 1,000 » n'établit pas le commerçant final, les dates, les conditions d'annulation, la devise ou la carte. Le système doit transformer l'instruction en contraintes, constituer une caisse et obtenir le niveau d'approbation requis par le risque, la loi et la conception du produit.
Les mandats ouverts soutiennent une autonomie limitée. Les mandats clôturés lient l'approbation à un paiement et à un montant spécifiques. AP2 utilise des mandats de paiement et de paiement avec des reçus signés pour créer des preuves entre les participants.[1][2] Les approches réseau mettent également l’accent sur les agents enregistrés, les informations d’identification tokenisées et l’intention vérifiable de l’utilisateur.[3][4]
| Couche | Question centrale | Preuve requise | Conséquence de l'échec |
|---|---|---|---|
| identité de l'utilisateur | qui délègue | authentification, preuve de compte et d'appareil | usurpation d'identité et litige |
| identité de l'agent | quel logiciel agit | enregistrement, certificat, clé et propriétaire | acceptation des robots malveillants |
| intention | quel résultat est autorisé | instruction signée, limites et expiration | achat excessif ou involontaire |
| vérifier | ce qui est acheté | panier signé par le marchand, prix et conditions | substitution ou manipulation de prix |
| informations d'identification | quel instrument peut payer | jeton de portée, liaison de périphérique et décision de l'émetteur | utilisation abusive des informations d'identification |
| exécution | ce qui s'est passé | réponse du processeur, nom occasionnel et horodatage | rejouer ou dupliquer le paiement |
| accomplissement | ce qui a été livré | preuves d'acceptation, de livraison et de remboursement | rétrofacturation et perte du commerçant |
Cadre proposé ; les exigences applicables dépendent du produit, du rail et de la juridiction.
Chaque transition nécessite un vérificateur nommé, un enregistrement durable et un chemin d'exception.
5. Reconstruire le consentement et les mandats
Le consentement doit être suffisamment spécifique pour guider l’exécution et suffisamment durable pour étayer un litige ultérieur. L'équipe de diligence doit inspecter la façon dont l'utilisateur voit l'instruction, le paiement, le montant, le commerçant, l'instrument, le calendrier et les conditions importantes. Il doit identifier ce qui est signé, par qui, en utilisant quelle clé, sur quelle surface de confiance et avec quels droits de révocation.
L'interface est importante car les résultats du modèle peuvent différer de la compréhension de l'utilisateur. Une requête en langage naturel peut être ambiguë. Le système doit faire apparaître des hypothèses qui modifient l'effet économique ou juridique, notamment les abonnements, les droits d'annulation, les devises, les pourboires, les délais de livraison et les conditions non remboursables. Les changements à haut risque ou hors politique devraient revenir à une étape d’approbation humaine.
Les mandats doivent être versionnés, délimités et liés. AP2 lie l'autorité de paiement à une caisse et fournit des reçus qui peuvent être vérifiés lors d'un litige.[1] L'acheteur doit tester la rotation des clés, l'expiration, l'utilisation occasionnelle, la prévention des rediffusions, la divulgation sélective, la révocation et la récupération des archives. Il doit également tester si un mandat peut être réutilisé entre les commerçants, les paniers, les montants ou les informations d'identification.
La cible doit conserver les preuves de la période de litige et de réglementation applicable. Un objet cryptographique a une valeur limitée lorsque les clés, schémas, logiciels de vérification ou enregistrements contextuels ne peuvent pas être reproduits après la transaction.
6. Séparer la reconnaissance de l'agent de l'identité de l'utilisateur
Les commerçants doivent distinguer les agents commerciaux approuvés des robots d'exploration, des robots malveillants et des automatisations non autorisées. Le protocole d'agent de confiance de Visa décrit les mécanismes signés pour la reconnaissance des agents, la reconnaissance des consommateurs et les conteneurs de paiement.[5][6] Les documents Agent Pay de Mastercard décrivent les agents enregistrés, les informations d'identification tokenisées et l'intention vérifiable.[3][4]
La reconnaissance de l'agent confirme le participant au logiciel et son cadre de confiance. Cela ne prouve pas qu'un utilisateur particulier a autorisé un achat particulier. L’identité de l’utilisateur, l’état du compte, l’appareil, l’authentification et les preuves de mandat restent distincts. L’acheteur doit rejeter les architectures qui regroupent ces questions en un seul drapeau « d’agent de confiance ».
L'échantillon de diligence doit tester les agents inconnus, les certificats expirés, les agents révoqués, la rotation des clés, la relecture, les en-têtes modifiés, le proxy, la substitution d'informations d'identification et les agents légitimes avec des instructions hors de portée. Les contrôles des commerçants doivent échouer en toute sécurité et enregistrer une raison pouvant être rapprochée des résultats de conversion et de fraude.
Les aspects économiques de l’enregistrement comptent également. La certification, l'intégration du réseau, la surveillance et le support peuvent créer une défendabilité ou un coût. L’acheteur doit vérifier si les enregistrements sont transférés en cas de changement de contrôle et si le rôle de la cible est remplaçable par un réseau commun ou un service cloud.
7. Lier le contexte de la transaction et empêcher la relecture
Une demande de paiement doit être liée au commerçant, à la caisse, au montant, à la devise, à la portée des informations d'identification et à la fenêtre de fraîcheur. Sans engagement, un attaquant peut relayer une approbation valide à un autre commerçant, modifier le panier ou réutiliser un objet signé. Les signatures de messages HTTP et les protocoles réseau fournissent des éléments techniques pour la vérification de l'intégrité et de l'origine des messages.[7][5]
L'acheteur doit reconstituer la façon dont les noms occasionnels, les horodatages, les restrictions d'audience, les cibles de requêtes, les résumés de contenu et les clés sont vérifiés. Il doit identifier quel participant rejette un objet non valide et si les systèmes en aval peuvent distinguer une défaillance cryptographique d'un refus ordinaire.
L’idempotence et le double contrôle nécessitent la même attention. Les agents peuvent réessayer après un délai d'attente, appeler plusieurs fournisseurs ou continuer après une réponse retardée. Le système doit empêcher les saisies multiples, les exécutions en double et les reçus incohérents. La réconciliation doit relier chaque instruction à un résultat économique ou à un renversement documenté.
Les tests d'échec doivent inclure la dérive d'horloge, l'interruption du réseau, l'exécution partielle, les changements de prix, les stocks expirés, la conversion de devises et les défis d'authentification. La cible doit faire preuve d’un retour en arrière déterministe et d’une communication client plutôt que de s’appuyer sur un modèle pour improviser une reprise.
8. Testez l’authentification et les contrôles de paiement
Une authentification forte du client, une authentification basée sur les risques, la tokenisation, la liaison des appareils et les mots de passe de paiement peuvent réduire les risques lorsqu'ils sont correctement intégrés. Leurs effets juridiques et systémiques dépendent du chemin de fer et de la juridiction. L'ABE et la BCE indiquent que l'authentification forte des clients reste efficace contre les types de fraude pour lesquels elle a été conçue, tandis que les fraudeurs manipulent de plus en plus les payeurs.[11]
L'acheteur doit examiner la séquence de décision pour les flux humains présents et humains non présents. Il doit enregistrer le moment où l'authentification a lieu, les données de transaction que l'utilisateur voit, les exemptions applicables et quel participant supporte le résultat. Un modèle de recommandation ne doit pas remplacer silencieusement une authentification obligatoire ou une décision politique.
Les preuves d'authentification doivent concilier les données d'autorisation, de compensation, de règlement et de litige. Les taux de réussite à eux seuls sont incomplets. Le conseil d'administration devrait constater la conversion, les faux refus, la fraude, l'abandon des défis, les coûts de support et la responsabilité par méthode et par cohorte.
| Contrôle | Test | Preuve | Pertinence de l'évaluation |
|---|---|---|---|
| inscription d'agent | agent valide, révoqué et inconnu | certificat et journal de décision | volume accepté adressable |
| mandat | montant, commerçant et limite d'expiration | objet signé et reçu | défendabilité du litige |
| portée des informations d'identification | tentative de réutilisation et de substitution | réponse du jeton et de l'émetteur | fraude et acceptation du réseau |
| authentification | flux présents et autonomes | preuve de contestation et d’exemption | transformation et responsabilité |
| rejouer la défense | dupliquer une demande occasionnelle et retardée | rejet déterministe | limitation des pertes |
| idempotence | délai d'attente et réessayer | capture et exécution uniques | résultat client et commerçant |
| révocation | retrait d'utilisateur, d'agent et d'identifiant | temps de propagation et déni | durée du risque extrême |
Catalogue de tests proposé ; le régime et les exigences légales prévalent.
9. Construire une taxonomie de la fraude agentique
Les paiements agents héritent des piratages de comptes classiques, du vol d’identifiants, de la fraude marchande et de l’ingénierie sociale. Ils ajoutent des échecs impliquant la manipulation d'instructions, des outils malveillants, une injection rapide, une usurpation d'identité d'agent, une falsification de mandat, une substitution de panier, une erreur de modèle et une délégation non autorisée. L'acheteur doit distinguer l'attaque, l'accident, la défaillance du contrôle et le litige commercial car la prévention et la responsabilité diffèrent.
La fraude peut intervenir avant le paiement. Une page de produit malveillante peut manipuler l'agent, un outil compromis peut modifier les détails de livraison ou un faux commerçant peut présenter un paiement plausible. La fraude peut également s'introduire après l'autorité par le biais d'une utilisation abusive des informations d'identification, d'une rediffusion, d'une exécution en double, d'une non-livraison ou d'un abus de remboursement.
La cible doit mapper chaque type de fraude aux contrôles préventifs, de détection et de récupération. Il doit montrer quels signaux étaient disponibles au moment de la décision, quelles mesures ont été prises, à qui appartient la perte et à quelle vitesse le système a appris. Les étiquettes de fraude doivent être examinées de manière indépendante, car la reclassification des pertes en litige client ou erreur du commerçant peut surestimer les performances du modèle.
L’adaptation des attaques devrait entrer dans l’évaluation. Un contrôle qui a bien fonctionné lors d'un petit projet pilote peut se détériorer lorsque le volume des transactions et l'attention des attaquants augmentent. Les tests de résistance devraient inclure des compromis entre fournisseurs communs et des abus coordonnés entre agents et commerçants.
Pertes en points de base tout à fait hypothétiques sur la valeur brute du paiement ; les montants démontrent uniquement le rapprochement.
10. Reconstruire la responsabilité par chemin de fer et par juridiction
La responsabilité suit les définitions juridiques, les règles du système, les contrats et les faits. La présence technique d'un mandat signé ne détermine pas à elle seule l'issue juridique. L'acheteur doit cartographier l'exposition du consommateur, de l'entreprise, du commerçant, de l'émetteur, de l'acquéreur, du processeur, du réseau, du portefeuille, du fournisseur d'informations d'identification et de la plate-forme d'agent pour chaque flux pris en charge.
Aux États-Unis, le règlement E établit les droits, les responsabilités et les règles de résolution des erreurs pour les transferts électroniques de fonds couverts. Sa définition du transfert non autorisé et ses règles sur la responsabilité du consommateur nécessitent une analyse factuelle de l'autorité réelle, des dispositifs d'accès et des avantages.[12][13][14] Un agent autorisé dans certaines limites crée une question différente de celle d'un fraudeur utilisant des informations d'identification volées ou d'un agent dépassant son mandat.
Dans l'Union européenne, la DSP2, la DSP3 en développement et le cadre de réglementation des services de paiement, les dispositions d'authentification forte des clients et d'attribution de fraude façonnent l'exposition des prestataires de paiement.[15][16] Le Royaume-Uni combine les règles relatives aux services de paiement avec des exigences en matière de remboursement et de résultats pour le consommateur.[17][18] D’autres juridictions appliquent leurs propres régimes de paiement au détail, de valeur stockée, de données et de consommation.[19][20]
L’acheteur doit créer un exposé de position juridique pour chaque produit matériel et chaque zone géographique. Il convient d’éviter de considérer « l’utilisateur a approuvé l’agent » comme une renonciation universelle. La protection des consommateurs, l'attribution de régimes, les normes en matière de négligence et les limites contractuelles peuvent restreindre cette position.
11. Construire des preuves de qualité contestable
Les litiges testent si la plateforme peut reproduire la transaction telle que vécue par chaque participant. L'ensemble de preuves doit inclure les instructions de l'utilisateur, le mandat, la présentation sur surface fiable, le paiement signé par le commerçant, la portée des informations d'identification, l'authentification, le statut de l'agent et de la clé, les messages du processeur, l'exécution, les communications, les remboursements et les reçus.
AP2 décrit la vérification des mandats et des reçus pour les litiges, y compris la vérification des hachages de caisse et de paiement.[1] L'acheteur doit gérer les litiges historiques et synthétiques tout au long du processus de récupération. Les preuves doivent rester disponibles après la rotation des clés, le changement de schéma, la sortie du fournisseur et le départ de l'employé.
L'opération de litige doit enregistrer le code motif, le propriétaire, le délai, le montant, le crédit provisoire, les preuves soumises, le résultat, le recouvrement et la cause première. Le taux de réussite des rétrofacturations doit être segmenté par type de transaction et par exhaustivité des preuves. Un taux de réussite élevé peut encore dissimuler de mauvais résultats pour les clients ou un retard de paiement.
Le privilège juridique, la conservation et la confidentialité nécessitent une conception. La salle des preuves doit préserver les faits nécessaires sans exposer de données personnelles ou de secrets sans rapport. L'accès, l'exportation et la suppression doivent être contrôlés et vérifiables.
12. Reconstruire l'économie de l'unité complète
L’économie des paiements agents devrait commencer par la valeur réglée et les revenus collectés, puis déduire les dépenses de réseau et de traitement, la fraude, les litiges, les remboursements, les incitations, l’authentification, les coûts d’enregistrement des agents, le support client, la conformité, l’infrastructure et les partages des partenaires. La valeur brute du paiement n’établit pas la valeur de l’entreprise.
Le cas hypothétique traite USD 4.0 billion de valeur de paiement brute annuelle à un taux d'acceptation brut de 42 points de base. Il suppose 14 points de base de coût de traitement et de réseau, 9 points de base de fraude et de litiges après recouvrement, 4 points de base d'incitations, 3 points de base de coût d'agent et d'authentification et 2 points de base de coût de support direct et de conformité. Ces hypothèses produisent 10 points de base, ou USD 4.0 million, de contribution avant la technologie centrale, les ventes, les taxes et le coût en capital. Ce ne sont que des hypothèses méthodologiques.
Les aspects économiques doivent être segmentés par commerçant, fournisseur d’agents, chemin de fer, région, type d’informations d’identification, chemin d’authentification et cohorte. Un nouveau flux autonome peut augmenter la conversion tout en produisant des coûts de litige et de support plus élevés. L'acheteur doit comparer les populations appariées et reconnaître le temps nécessaire pour que la fraude et les rétrofacturations arrivent à maturité.
| Article | Points de base | USD millions |
|---|---|---|
| valeur brute du paiement | 10,000 | 4,000.0 |
| revenu brut | 42 | 16.8 |
| traitement et réseau | (14) | (5.6) |
| fraude et litiges | (9) | (3.6) |
| incitations | (4) | (1.6) |
| agent et authentification | (3) | (1.2) |
| support direct et conformité | (2) | (0.8) |
| contribution avant coût central | 10 | 4.0 |
Montants en USD millions et points de base entièrement hypothétiques; le tableau ne constitue pas une référence de marché.
Montants en USD millions entièrement hypothétiques; les coûts centraux, la fiscalité et les exigences de capital restent en dehors de la contribution présentée.
13. Mesurer la conversion et les facteurs économiques du faux déclin
Les commerçants peuvent bloquer les automatisations inconnues pour protéger leurs stocks, leurs systèmes et leurs clients. La reconnaissance des agents de confiance peut récupérer une demande légitime, tandis que des contrôles mal calibrés peuvent admettre une fraude ou rejeter des clients importants. L'acheteur doit mesurer les deux côtés de la décision.
La conversion doit être décomposée depuis la visite de l'agent jusqu'à la disponibilité du produit, le paiement, la libération des informations d'identification, l'authentification, l'autorisation, l'exécution et le règlement. Chaque point de perte doit avoir un code motif. Un taux de paiement plus élevé peut être compensé par des annulations, des commandes en double, des remboursements ou une contribution inférieure.
Les faux déclins nécessitent des contrefactuels vérifiés. L’examen manuel, le paiement ultérieur réussi, les commentaires des émetteurs et les cohortes appariées peuvent fournir des preuves. L'analyse doit distinguer le blocage du commerçant, l'échec de la vérification de l'agent, le refus d'informations d'identification, l'abandon de l'authentification et le refus de l'émetteur.
Les prévisions commerciales devraient évaluer séparément l’adoption par les commerçants et contrôler la qualité. Un protocole peut être disponible alors que l’intégration des commerçants, la reconnaissance du réseau ou la confiance des consommateurs restent limitées. Seules les améliorations de conversion mises en œuvre et prouvées doivent entrer en valeur prouvée.
14. Concilier fraude, rétrofacturations, remboursements et réserves
Les rapports de perte doivent concilier les tentatives de fraude, les fraudes évitées, les fraudes autorisées, les fraudes non autorisées, les litiges avec les commerçants, les non-livraisons, les remboursements, les rétrofacturations, les recouvrements et les radiations. Les définitions doivent être stables au fil des périodes et correspondre aux enregistrements du réseau, du processeur, du commerçant et du grand livre.
Le timing des réserves est important. La fraude peut apparaître rapidement tandis que les litiges et les rétrofacturations arrivent plus tard. La croissance peut donc améliorer les revenus courants avant que la cohorte complète des pertes ne se développe. L'acheteur doit créer des millésimes de transaction par mois d'autorisation et les suivre jusqu'au statut final du litige.
L'attribution contractuelle doit être conforme à la pratique observée. Un sous-traitant peut avoir des droits à indemnisation difficiles à recouvrer. Une réserve marchande peut être insuffisante ou piégée. Les amendes liées au réseau, les programmes de surveillance et les coûts de remédiation doivent être séparés des pertes de transaction.
| Événement | Etiquette opérationnelle | Propriétaire de trésorerie | Preuves nécessaires |
|---|---|---|---|
| identifiant volé | paiement non autorisé | émetteur ou fournisseur soumis à des règles | faits d'accès, d'authentification et de fraude |
| l'agent dépasse la limite | violation de l'autorité | spécifique aux faits | mandat, révocation et présentation |
| caisse modifiée | falsification de transactions | propriétaire du contrôle des participants | panier signé et hachages |
| exécution en double | erreur de traitement | service provoquant une duplication | journaux d'idempotence et de capture |
| non-livraison | litige marchand | commerçant soumis au régime | épanouissement et communication |
| mauvaise sélection de modèle | panne de service | plateforme d'agent soumise à contrat | instruction, classement et divulgation |
| ingénierie sociale | payeur manipulé | spécifique à la juridiction | communications et authentification |
Réconciliation proposée ; les faits et règles spécifiques à la transaction déterminent la répartition finale.
15. Tester les droits, la confidentialité et la finalité des données
Les paiements agents combinent l'identité, les préférences, les recherches de produits, la localisation, les informations d'identification et l'historique des transactions. L'acheteur doit mapper chaque élément de données sur la source, la base juridique, la finalité, le destinataire, la conservation, l'utilisation du modèle, le transfert et la suppression. Le consentement à l’achat n’autorise pas automatiquement le profilage ou la formation de modèles sans rapport.
La divulgation sélective peut réduire l’exposition. Les protocoles ne peuvent divulguer que les contraintes requises par un vérificateur, tandis que les jetons peuvent éviter de partager les informations d'identification principales. L'acheteur doit tester si l'architecture de production suit ce principe ou copie les instructions complètes et les informations d'identification entre les fournisseurs.
Les droits sur les données doivent survivre à la transaction. Les contrats nécessitent des dispositions en matière d'accès, d'audit, de portabilité, de sécurité, d'avis d'incident, de sous-traitance et de sortie. Une cible peut dépendre de données comportementales qu’un partenaire peut retirer ou qu’il ne peut légalement transférer après un changement de contrôle.
L'évaluation doit inclure les mesures correctives et la perte de revenus lorsque la personnalisation actuelle dépend d'une utilisation de données non prise en charge. L’ingénierie de confidentialité et la suppression fiable sont des capacités opérationnelles et non des documents de politique.
16. Appliquer des contrôles en matière de criminalité financière et de sanctions
L'automatisation ne supprime pas l'obligation de comprendre les clients, les commerçants, les transactions et les contreparties. Les orientations du Groupe d’action financière sur l’identité numérique soutiennent une utilisation de l’identité numérique basée sur les risques tout en mettant l’accent sur la gouvernance et l’assurance.[21] Le FinCEN, l'OFAC et les autorités nationales fournissent des exigences et des orientations relatives au blanchiment d'argent, aux sanctions et aux activités suspectes.[22][23]
L'acheteur doit identifier quelle entité effectue l'intégration, la sélection, la surveillance, l'enquête, le reporting et la tenue des dossiers. L’identité des agents et des commerçants peut modifier les signaux disponibles, tandis qu’une exécution autonome rapide peut réduire le temps d’intervention.
Les contrôles doivent couvrir la propriété de l'agent-fournisseur, la catégorie du commerçant, le bénéficiaire, la géographie, l'appareil, les informations d'identification, le produit, la vélocité et le comportement associé. Les alertes modèles doivent alimenter un processus de gestion des dossiers régi par la responsabilité humaine. Les contrôles des sanctions nécessitent des mises à jour des listes en temps opportun, un blocage et une escalade des paiements.
Les flux transfrontaliers et les flux d’actifs numériques nécessitent une analyse distincte. L’équipe chargée des transactions doit éviter d’étendre les conclusions du contrôle national des cartes aux transferts en temps réel ou au règlement par blockchain sans preuves spécifiques au rail.
17. Évaluer la technologie, la résilience et les tiers
La plate-forme doit continuer à faire valoir son autorité en cas de défaillance du modèle, du réseau et du fournisseur. L’architecture doit séparer l’interprétation probabiliste de la politique déterministe et de l’exécution des paiements. Les contrôles critiques nécessitent des entrées explicites, une gestion des versions, des tests, une surveillance, une restauration et la propriété des incidents.
L'acheteur doit tester la perte de région cloud, la panne de service clé, la défaillance du fournisseur d'identité, l'indisponibilité du modèle, l'expiration du délai du réseau, la politique corrompue, la révocation retardée, l'outil compromis et le changement de commerçant API. La récupération doit préserver l’état de la transaction et empêcher les exécutions en double.
Les services tiers doivent entrer dans un registre complet lié aux contrats, données, clés, contrôles, niveaux de service, concentration et sortie. Les principes de résilience opérationnelle et de tiers du Comité de Bâle fournissent des perspectives utiles, le cas échéant.[24][25] Les cadres du NIST AI et de cybersécurité fournissent des structures de contrôle complémentaires.[26][27]
| Capacité | Des preuves solides | Faible preuve | Réponse à la transaction |
|---|---|---|---|
| application des politiques | service et tests déterministes | instruction rapide uniquement | condition d'assainissement |
| clés et signatures | cycle de vie et rotation gérés | secrets partagés non gérés | fermeture du portail |
| État et idempotence | état de transaction durable | réessayer sans contrôle | réserve pour pertes |
| changement de modèle | approbation versionnée et restauration | mise à jour silencieuse de la production | attente d'intégration |
| continuité du fournisseur | alternative testée et sortie | fournisseur unique et opaque | déduction de valeur |
| réponse aux incidents | un manuel de jeu multipartite répété | escalade informelle | programme financé |
| conservation des preuves | reproductible après changement | journaux transitoires | déduction pour litige |
Matrice proposée ; la matérialité détermine la profondeur du test.
18. Valoriser la plateforme par couche de preuves
La valeur doit être divisée en valeur d’exploitation prouvée, en expansion prouvée et en valeur d’option conditionnelle. La valeur prouvée provient de transactions de production avec une autorité reproductible, de cohortes stables de fraude et de litiges, d'un réseau et d'un fonctionnement marchand acceptés, de droits transférables et de contributions collectées.
La valeur de l'expansion dépend de marchands, d'agents, de rails, de zones géographiques ou de cas d'utilisation autonomes supplémentaires. Il doit être pondéré en fonction de la probabilité en utilisant des preuves d'intégration, de certification, de réglementation, de client et de contrôle. L’option stratégique peut rester en dehors du prix de base ou entrer dans une contrepartie conditionnelle.
L'évaluation hypothétique commence par USD 70 million de valeur autonome. Il ajoute USD 14 million pour une amélioration évidente de la conversion des commerçants et USD 10 million pour la distribution des acheteurs. Il déduit USD 9 million pour les cohortes de fraude immatures, USD 8 million pour l'incertitude de responsabilité, USD 6 million pour la remédiation technologique et USD 5 million pour l'intégration. La valeur nette illustrative qui en résulte est USD 66 million. Chaque montant constitue une hypothèse de gestion et non une opinion d'évaluation.
| Couche | Valeur brute | Poids de la preuve | Valeur incluse |
|---|---|---|---|
| valeur d'exploitation autonome | 70 | 100% | 70 |
| conversion de commerçant | 14 | 100% | 14 |
| répartition des acheteurs | 20 | 50% | 10 |
| cohortes de fraude immatures | (9) | 100% | (9) |
| incertitude de responsabilité | (8) | 100% | (8) |
| remédiation technologique | (6) | 100% | (6) |
| intégration | (5) | 100% | (5) |
| valeur illustrative des capitaux propres | 66 |
Montants en USD millions et pondérations des éléments probants entièrement hypothétiques.
Montants en USD millions entièrement hypothétiques; le pont est méthodologique et ne constitue pas une opinion de valorisation.
19. Appliquer une réduction de responsabilité de manière transparente
Une réduction de responsabilité devrait quantifier l’incertitude selon laquelle les résultats actuels de l’autorité, de la fraude et des litiges ne persisteront pas après une mise à l’échelle ou un changement de contrôle. Il doit être lié à des scénarios identifiés plutôt qu'à un pourcentage générique. Les facteurs pertinents incluent des cohortes de transactions non aguerries, des mandats ambigus, des exemptions d'authentification non prises en charge, la concentration des commerçants, des lacunes contractuelles, une faible conservation des preuves et un périmètre réglementaire incertain.
Le cas central hypothétique utilise les aspects économiques de la section 12. L’inconvénient suppose que les coûts de fraude et de litige augmentent de 9 à 18 points de base, que les coûts d’agent et d’authentification augmentent de 3 à 5 points de base et que les revenus bruts diminuent de 42 à 38 points de base en raison de la pression sur les prix. Le cas grave suppose 24 points de base de fraude et de litiges et une réduction temporaire de 20 pour cent de la valeur transformée. Ce sont des hypothèses de gestion et non des probabilités.
Le conseil d'administration devrait identifier la première date à laquelle l'apport, la liquidité, une condition de réseau ou une réserve minimale échouent. Les actions de gestion nécessitent un montant, un propriétaire, un délai de livraison et un effet client. Les actions possibles incluent la restriction de l'autonomie, l'augmentation de l'authentification, la suspension d'un agent ou d'un commerçant, la modification des limites, l'ajout de réserves ou l'obtention d'une indemnisation.
Des millions annuels tout à fait hypothétiques de USD dans les cas de fraude, de litige et de revenus.
20. Traduire les preuves en protections des transactions
Le contrat d'achat doit convertir l'incertitude identifiée en engagements d'allocation, de conditions, de prix et d'exploitation. Les représentations doivent aborder les licences, le statut du système, les enregistrements d'autorité, les droits sur les données, la sécurité, les mesures de fraude, les litiges, les réserves, les commerçants, les clés, les modèles, les fournisseurs et les incidents. Les définitions doivent correspondre aux données de diligence.
Les conditions peuvent inclure le consentement du réseau ou des autorités réglementaires, le contrôle des clés et des certificats, le transfert de contrats critiques, la correction d'un manque d'autorité important, le financement de réserve et la fourniture de preuves reproductibles. Les clauses doivent régir les modifications matérielles du modèle, de la politique, des informations d'identification et du fournisseur entre la signature et la clôture.
Les indemnisations, le séquestre, la rétention et l'assurance doivent correspondre à l'exposition exécutoire. La considération différée peut dépendre des cohortes de fraudeurs chevronnés, de la fidélisation des commerçants, des résultats des litiges et de la contribution vérifiée. L'acheteur doit éviter les jalons basés uniquement sur la valeur brute du paiement ou sur le trafic des agents.
| Lacune en matière de preuves | Réponse aux prix | Protection | Communiquer des preuves |
|---|---|---|---|
| cohorte de fraude inexpérimentée | report de valeur | rétention ou complément de prix | perte nette à maturité et contribution |
| autorité ambiguë | déduction de réparation | condition et indemnité | mandat vérifié et test de contestation |
| approbation du réseau en attente | valeur d'expansion contingente | condition de consentement | approbation écrite et test de production |
| droit sur les données non transmissibles | exclure la valeur dépendante | représentation et alliance | droit transférable exécuté |
| faible conservation des preuves | réparation financée | dépôt et jalon | échantillon historique reproductible |
| concentration des fournisseurs | déduction de continuité | convention de transition | alternative testée et sortie |
| exposition à un incident connu | déduction spécifique | indemnité et réserve | fermeture et risque résiduel quantifié |
Cadre proposé ; des conseillers qualifiés devraient rédiger des conditions exécutoires.
21. Concevoir l'intégration autour de la continuité des paiements
L'intégration peut modifier simultanément les agents, les clés, les informations d'identification, les politiques, les commerçants, les processeurs, les données et la communication avec les clients. Le premier jour doit préserver les entités juridiques, les licences, le statut du système, l'acheminement des paiements, le règlement, les réserves, les délais de litige, la surveillance de la fraude, la révocation et la réponse aux incidents.
La propriété du contrôle doit être explicite. L'acheteur doit établir un seul enregistrement de décision pour les modifications importantes apportées à l'autorité, à l'authentification, aux informations d'identification, aux règles et modèles de fraude. Le fonctionnement parallèle peut être approprié lorsqu'un échec pourrait créer un paiement en double, un préjudice pour le client ou une violation du système.
La communication marchande et réseau nécessite du séquençage. Le changement de marque, les changements de domaine, la rotation des certificats, la migration du processeur et la novation de contrat peuvent modifier les signaux de confiance. Le plan d'intégration doit identifier les modifications qui nécessitent une approbation, une recertification, un avis client ou un consentement renouvelé.
La synergie doit suivre la continuité. La distribution, les ventes croisées et les infrastructures partagées peuvent créer de la valeur une fois que l'autorité, la fraude, les preuves et le règlement restent stables dans le cadre du modèle opérationnel combiné.
22. Exécuter un programme de 180 jours
Les trente premiers jours devraient établir le contrôle. Confirmez l'argent liquide, le règlement, les réserves, les licences, l'état du réseau, les contrats des commerçants, les enregistrements des agents, les clés, l'inventaire des modèles, les files d'attente pour fraude, les litiges, les incidents et les fournisseurs critiques. Gelez les modifications non documentées et conservez les preuves de transaction.
Les jours trente et un à quatre-vingt-dix devraient reproduire des transactions échantillonnées, tester les mandats, concilier fraude et litiges, valider l'économie de l'unité, exercer la révocation, tester l'idempotence et compléter une analyse juridique spécifique au rôle. Les lacunes matérielles doivent figurer dans les plans de remédiation financés avec les propriétaires et les délais.
Les jours quatre-vingt-onze à cent quatre-vingts devraient terminer les intégrations approuvées, obtenir les consentements, alterner les clés si nécessaire, automatiser les preuves, clôturer les découvertes hautement prioritaires, saisonner les cohortes de transactions et lancer les initiatives de valeur qui atteignent leurs portes. Le conseil d’administration doit examiner ensemble les résultats concernant les clients, le contrôle, la trésorerie et la responsabilité.
Protocole de reconstruction de transaction
L'équipe doit sélectionner des échantillons parmi les agents, les commerçants, les rails, les zones géographiques, les chemins d'authentification, les paiements réussis, les refus, les remboursements et les litiges. Pour chaque élément, il doit reconstruire les instructions de l'utilisateur, la surface de consentement, le mandat, le paiement, les informations d'identification, l'autorisation, l'exécution, le règlement et l'argent liquide. Des identifiants stables et des heures d'événements doivent connecter chaque enregistrement.
La reconstruction doit utiliser des extraits de sources immuables avec une lignée documentée, des totaux de contrôle et un traitement en double. L'équipe doit comparer la transaction présentée à l'utilisateur avec la transaction exécutée. Toute incapacité à reproduire la portée, le montant, le commerçant ou l'instrument doit être classée par cause profonde et responsabilité potentielle.
Protocole d’autorité et de révocation
L'équipe doit tester les mandats spécifiques et ouverts, les plafonds de dépenses, les restrictions des commerçants, les fenêtres horaires, l'autorité récurrente, les limites des instruments et l'approbation des exceptions. Il doit tenter une réutilisation en dehors du champ d'application et confirmer le rejet déterministe.
Les tests de révocation doivent couvrir l'utilisateur, l'agent, les informations d'identification, l'appareil et le commerçant. Le tableau doit voir le temps de propagation entre les caches, les fournisseurs et les réseaux. Une révocation techniquement valide qui intervient après l'exécution peut toujours entraîner un risque financier et client.
Protocole de fraude et de litige
Les cohortes de fraude doivent concilier les tentatives, les blocages, les autorisations, les pertes, les recouvrements et la classification finale. Les litiges doivent concilier motif, preuves, délai, crédit provisoire, résultat et espèces. Les mêmes définitions doivent apparaître dans les tableaux de bord opérationnels, les contrats et la valorisation.
L'équipe doit rejouer les litiges clos et évaluer l'exhaustivité des preuves sans s'appuyer sur les employés qui les ont traités à l'origine. Il devrait estimer le coût et l'effet de perte des enregistrements manquants, des classifications non étayées et des cohortes immatures.
Protocole d’économie et de responsabilité
La contribution doit être reconstruite par chemin de fer, agent, commerçant et cohorte. Les revenus doivent être rapprochés du règlement et du reçu bancaire. Le traitement, le réseau, l'authentification, la fraude, les litiges, les incitations, le support, la conformité et les partages des partenaires doivent être visibles.
L’analyse juridique doit faire correspondre chaque défaillance importante à la loi applicable, aux règles du système et au contrat. Le modèle opérationnel doit comporter la même allocation. Une perte imputée à un commerçant dans le prévisionnel ne peut rester une obligation sans réserve de la plateforme dans le cadre du contrôle juridique.
Protocole de gouvernance des scénarios
Le modèle doit distinguer les conditions externes des choix de gestion. Les taux d'attaque, le comportement des commerçants, les règles du réseau et les changements réglementaires peuvent être externes. Les limites des agents, l'authentification, la tarification, les réserves, la portée du produit et la configuration du fournisseur restent en partie contrôlables.
Les tests de résistance inversés doivent identifier la combinaison qui entraîne une contribution négative, un déficit de réserve, une violation du réseau, un problème de licence ou un résultat inacceptable pour le client. Le résultat doit guider le prix, la rétention, l’indemnisation, le financement de réserve et la séquence d’intégration.
Protocole d'acceptation du commerçant et du réseau
L'équipe doit faire la distinction entre la compatibilité des protocoles et l'acceptation commerciale. Pour chaque commerçant, acquéreur, réseau et fournisseur d'informations d'identification, il doit enregistrer l'état de la production, la certification technique, le contrat, la limite de volume, la zone géographique prise en charge, le mode de paiement, le processus de litige et l'exigence de changement de contrôle. La participation annoncée, la connectivité sandbox et un pilote signé doivent rester distincts du volume de production accepté.
Les tests des commerçants doivent comparer le trafic reconnu par les agents et le trafic conventionnel en termes de disponibilité, de finalisation du paiement, d'authentification, d'autorisation, d'exécution, d'annulation, de remboursement et de litige. L’analyse doit identifier les domaines dans lesquels les commerçants continuent de classer les agents légitimes comme des robots et les domaines dans lesquels les chemins spécifiques aux agents affaiblissent les contrôles de fraude ou d’inventaire ordinaires. Les modifications de contrôle doivent avoir nommé les propriétaires et les critères d'annulation.
Les preuves du réseau et du processeur doivent confirmer la manière dont les indicateurs d'agent, les jetons, les mandats et les résultats d'authentification entrent dans les messages d'autorisation et de contestation. L'équipe doit identifier les champs perdus entre les systèmes ou réduits à des journaux propriétaires. Un contrôle précieux doit produire des preuves qui parviennent à l'acteur responsable de la décision et restent disponibles pendant un litige.
Protocole de fourniture de clé, d'identifiant et de logiciel
L'équipe doit inventorier les clés de signature, les clés de chiffrement, les certificats, les services de jetons, les coffres-forts d'informations d'identification, les progiciels, les points de terminaison modèles et les outils privilégiés. Chaque élément doit avoir un propriétaire, un environnement, une règle d'accès, un calendrier de rotation, un processus de révocation, une carte des dépendances et un historique des incidents. Les clés de production doivent rester séparées du développement et des tests.
La planification du changement de contrôle doit aborder la propriété légale et la garde opérationnelle. Les clés peuvent nécessiter une rotation, les certificats peuvent devoir être réémis et les enregistrements réseau peuvent nécessiter une approbation. L'acheteur doit éviter la migration simultanée de l'identité, de la politique, des informations d'identification et du traitement, à moins que des preuves ne démontrent que la restauration et la réconciliation restent fiables.
Les tests de fourniture de logiciels doivent couvrir les versions signées, la provenance des dépendances, la gestion des vulnérabilités, l'accès aux builds, l'analyse des secrets et les correctifs d'urgence. Un outil ou un package d'agent compromis peut modifier les instructions avant que les contrôles de paiement conventionnels ne voient la demande. L'environnement de contrôle doit détecter les modifications non autorisées et les connecter aux transactions concernées.
Protocole de propriété continu
L'entreprise combinée devrait désigner un responsable responsable du système de contrôle des paiements agentiques de bout en bout, soutenu par des propriétaires nommés pour les produits, les paiements, la fraude, la sécurité, les données, les aspects juridiques, la conformité, les finances et les opérations client. Les comités ne devraient pas occulter les droits de décision individuels.
Les rapports du conseil d'administration doivent relier l'adoption des agents, le trafic reconnu, la réussite du mandat, l'authentification, la conversion, la fraude, les litiges, les résultats des clients, les réserves, les contributions et les incidents. Les mesures doivent utiliser des définitions stables et se rapprocher des systèmes sources et des liquidités. Les changements importants au modèle ou aux politiques doivent inclure les avantages attendus, l’effet de contrôle, l’approbation, la surveillance et le retour en arrière.
Le modèle opérationnel doit définir quand un agent, un commerçant, un identifiant, un mode de paiement ou une zone géographique est restreint ou suspendu. Les seuils nécessitent une escalade basée sur les conséquences et une action rapide. Les leçons tirées des litiges et des incidents devraient mettre à jour la conception des produits, les contrôles, les protections des transactions et les hypothèses d’évaluation pour les acquisitions futures.
Le timing doit suivre les contraintes des transactions, du réseau, de la réglementation et des clients.
23. Décision et conclusion
Une plateforme de paiement agent mérite d'être valorisée en tant que système de preuves reproductibles qui transforme l'intention déléguée en transactions autorisées, acceptées et collectées. L'identité des agents, les mandats, la tokenisation, l'authentification et les modèles de fraude prennent en charge ce système. Leur valeur économique dépend d'une application déterministe, d'un enregistrement des litiges, d'une responsabilité limitée, de l'acceptation du commerçant et d'une contribution stable.
L'acheteur doit reconstruire les transactions au fil du temps, cartographier chaque participant et chaque rôle juridique, tester les limites de l'autorité, mesurer ensemble la conversion et la perte, et réconcilier les étiquettes opérationnelles avec la trésorerie et la responsabilité. Les protocoles émergents peuvent améliorer l’interopérabilité et les preuves, tandis que leur adoption et leur effet juridique doivent être vérifiés dans les produits et juridictions réels de la cible.
La réduction de responsabilité devrait quantifier les cohortes non aguerries, l’autorité incertaine, les lacunes contractuelles, les exemptions non justifiées, la faiblesse des preuves et le risque d’intégration. Les conditions de la transaction peuvent conserver une valeur conditionnelle grâce à des étapes liées à la perte à maturité, à la contribution vérifiée, au consentement et aux preuves de contrôle.
La décision d’acquisition qui en résulte est pratique. Une prime est justifiable lorsque la cible dispose d'enregistrements et de droits transférables, d'une autorité reproductible, d'informations d'identification limitées, d'un contrôle efficace de la fraude, de preuves de litige, de résultats clients conformes et de données économiques collectées. Une protection des prix, une portée plus étroite, des mesures correctives, un financement de réserve ou une valeur différée sont appropriés lorsque ces conditions restent incomplètes.
Sources
- Google Agentic Commerce, spécification du protocole de paiement des agents Lire la source principale
- Google Agentic Commerce, documentation sur le protocole de paiement des agents Lire la source principale
- Mastercard, paiement d'agent Mastercard Lire la source principale
- Mastercard, cadre de jetons agent Lire la source principale
- Visa, spécifications du protocole d'agent de confiance Lire la source principale
- Visa, protocole d'agent de confiance pour démarrer Lire la source principale
- Groupe de travail sur l'ingénierie Internet, Signatures de messages HTTP RFC 9421 Lire la source principale
- FIDO Alliance, spécifications FIDO Alliance Lire la source principale
- EMVCo, tokenisation des paiements EMV Lire la source principale
- EMVCo, EMV 3-D sécurisé Lire la source principale
- Autorité bancaire européenne, rapport conjoint de l'ABE et de la BCE sur la fraude aux paiements Lire la source principale
- Bureau de la protection financière des consommateurs, Règlement E Lire la source principale
- Bureau de protection financière des consommateurs, responsabilité en cas de transferts non autorisés Lire la source principale
- Bureau de la protection financière des consommateurs, FAQ sur les transferts électroniques de fonds Lire la source principale
- Commission européenne, Services de paiement Lire la source principale
- Autorité bancaire européenne, Services de paiement et monnaie électronique Lire la source principale
- Autorité de conduite financière, réglementation sur les services de paiement Lire la source principale
- Régulateur des systèmes de paiement, remboursement des escroqueries APP Lire la source principale
- Banque centrale de la UAE, réglementation des services de paiement de détail et des systèmes de cartes Lire la source principale
- Autorité monétaire de Singapour, Loi sur les services de paiement Lire la source principale
- Groupe d'action financière, orientations sur l'identité numérique Lire la source principale
- Réseau de lutte contre la criminalité financière, réglementation anti-blanchiment d'argent Lire la source principale
- Bureau du contrôle des avoirs étrangers, directives sur le respect des sanctions Lire la source principale
- Comité de Bâle sur le contrôle bancaire, Principes pour la résilience opérationnelle Lire la source principale
- Comité de Bâle sur le contrôle bancaire, Principes pour le risque de tiers Lire la source principale
- Institut national des normes et technologies, AI Cadre de gestion des risques Lire la source principale
- Institut national des normes et technologies, Cybersecurity Framework 2.0 Lire la source principale
- Conseil des normes de sécurité PCI, PCI DSS Lire la source principale
- Conseil des normes de sécurité PCI, orientations en matière de tokenisation Lire la source principale
- Organisation internationale de normalisation, ISO 20022 Lire la source principale
- Organisation internationale de normalisation, ISO CEI 42001 Lire la source principale
- OpenID Foundation, Gestion des identités pour les agents AI Lire la source principale
- Fondation OpenID, autorisation AuthZEN API Lire la source principale
- Consortium World Wide Web, modèle de données d'informations d'identification vérifiables Lire la source principale
- Consortium World Wide Web, Authentification Web Lire la source principale
- Union européenne, Loi sur l'intelligence artificielle Lire la source principale
- Comité européen de la protection des données, Prise de décision automatisée et orientations en matière de profilage Lire la source principale
- Bureau du commissaire à l'information du Royaume-Uni, AI et directives sur la protection des données Lire la source principale
- Commission fédérale du commerce, règle de sauvegarde Lire la source principale
- Banque des règlements internationaux, réglementant AI dans le secteur financier Lire la source principale
- Conseil de stabilité financière, Intelligence artificielle et stabilité financière Lire la source principale
- Conseil des gouverneurs de la Réserve fédérale, modèle de gestion des risques SR 11-7 Lire la source principale
- Banque d'Angleterre, Modèle de principes de gestion des risques pour les banques Lire la source principale
- Autorité de conduite financière, devoir du consommateur Lire la source principale
- Bureau de protection financière des consommateurs, Règle sur les droits en matière de données financières personnelles Lire la source principale
- Banque centrale européenne, Attentes en matière de surveillance de la cyber-résilience Lire la source principale
- Comité des paiements et des infrastructures de marché, Réduire le risque de fraude aux paiements de gros Lire la source principale
- Conseil des normes internationales d’évaluation, Normes internationales d’évaluation Lire la source principale
- Fondation des normes internationales d’information financière, IFRS 3 Regroupements d’entreprises Lire la source principale
- Fondation des normes internationales d’information financière, IAS 38 Immobilisations incorporelles Lire la source principale
