La conformité comme logiciel

Quatre maillons, chacun une structure de données plutôt qu’un paragraphe.

La plupart des fonctions conformité possèdent le premier et le dernier, mal. L'obligation vit dans un document de politique, la preuve dans un dossier de captures d'écran, et les deux maillons du milieu sont tenus par des personnes. Cet arrangement coûte cher, est lent, et produit une preuve dont la qualité dépend de qui était de service.

Construire les deux maillons du milieu, c'est tout l'exercice, et c'est du développement ordinaire.

Une règle qui change sans version est une règle qui a effacé sa propre histoire. Quand un superviseur demande pourquoi une transaction de mars n'a pas été signalée, la réponse doit être la règle telle qu'elle était en mars, pas telle qu'elle est aujourd'hui.

Chaque enregistrement de règle porte donc un identifiant, une version, une date d'entrée en vigueur, une date de fin et une référence à l'obligation qu'il met en oeuvre. Les exécutions de contrôle stockent la version utilisée. Retraiter l'historique est permis, mais cela produit un nouveau résultat lié à l'ancien plutôt qu'un remplacement.

De toutes les décisions de ce domaine, c'est celle qui rapporte le plus et coûte le moins, à condition d'être prise au départ.

Un contrôle qui ne trouve rien ne dit presque rien, parce qu'il est indiscernable d'un contrôle qui s'est mal exécuté. Ce qui porte de l'information, c'est l'exception : un cas qui a échoué à la règle, avec assez de contexte pour qu'un humain décide.

Concevez l'objet exception avant la règle. Il lui faut le sujet, la règle et la version qui l'ont levée, les valeurs en cause, une décision prise par une personne nommée, un motif à cette décision, et l'horodatage. Les décisions doivent former un ensemble fermé, parce que « revu et accepté » écrit de quarante façons ne s'analyse pas.

Une fois les exceptions structurées, les questions utiles deviennent des requêtes. Combien en levons-nous pour mille transactions, comment ce taux a-t-il bougé depuis le changement de règle, combien de temps attendent-elles avant décision, quel relecteur les traite le plus vite et est-ce que cela corrèle avec quelque chose d'inquiétant.

La question derrière la plupart des constats n'est pas de savoir si un contrôle fonctionne, mais s'il s'est exécuté sur tout ce sur quoi il devait s'exécuter. Un contrôle qui a examiné quatre-vingt-quatorze pour cent de la population et ne rapporte aucune exception ne rapporte rien.

Stockez la définition de la population avec chaque exécution : la requête, le compte, les bornes. Un trou devient alors visible comme un trou plutôt que comme un silence. Rapprocher la population du contrôle de la population d'exploitation est en soi un contrôle, et c'est celui qui attrape les défaillances que personne n'avait prévues, comme un nouveau prestataire de paiement dont les transactions n'ont jamais été incluses parce que la requête filtrait sur une liste d'identifiants écrite dix-huit mois plus tôt.

L'automatisation retire ici la recopie, la recherche et le calcul, pas le jugement. Ce qu'elle achète, c'est du jugement appliqué aux cas qui en demandent, avec le contexte déjà rassemblé.

La mesure d'un bon système de conformité, c'est ce que voit l'analyste quand il ouvre un cas. S'il doit aller dans trois autres systèmes pour le comprendre, le système a automatisé la moitié facile et laissé la moitié coûteuse intacte.

Une inspection cesse d'être un événement qui consomme un trimestre et devient une requête. La demande « montrez-nous comment vous avez surveillé cette obligation ces deux dernières années » se satisfait en exportant les exécutions de contrôle, les versions de règles et les décisions, parce que les trois existent comme données.

Le second changement est plus discret et compte davantage. Quand la preuve est un sous-produit de l'exploitation plutôt qu'une tâche séparée, personne n'a plus à choisir entre faire le travail et le documenter, et la documentation cesse d'être une fiction écrite après coup.