01
Comment les contreparties entrent dans le système.
KOTA accepte un dossier de contrepartie depuis l'un ou l'autre côté de la relation. Les opérateurs peuvent s'inscrire eux-mêmes et déposer une candidature externe. Les banques peuvent ouvrir un dossier sur une contrepartie qu'elles connaissent déjà, inviter un opérateur à rejoindre la plateforme, ou exécuter une variante propre à un programme adaptée à leur contexte. Les cinq chemins convergent vers une même structure de dossier. L'origine ne conditionne pas ce qui suit : la rigueur de la compilation, de l'évaluation et du scoring s'applique de la même manière quelle que soit la voie d'arrivée de la contrepartie.
Inscription de l'opérateur sur le système
L'opérateur visite la page d'accueil de KOTA et complète une inscription en trois étapes : informations personnelles, informations sur l'organisation (raison sociale, position dans la chaîne d'approvisionnement, pays d'immatriculation, forme juridique) et une courte évaluation de préparation. À la soumission, l'opérateur obtient un accès immédiat, sans attente d'approbation manuelle, sans documents requis à ce stade.
Les données d'inscription alimentent directement le profil structuré de l'opérateur. L'Évaluation de Préparation est un court questionnaire validé en pilote qui indique où se situe l'opérateur par rapport aux attentes bancaires avant qu'une candidature formelle ne commence, faisant remonter un contexte utile pour l'examinateur à venir sans conditionner l'accès.
À partir de ce moment, l'opérateur dispose d'un espace de travail qu'il possède : un profil qu'il peut enrichir, un tableau de bord pour suivre chacun de ses engagements de contrepartie, et le socle de tout ce qui suit sur la plateforme.
Candidature externe
Un opérateur inscrit ouvre le formulaire de candidature de niveau 1 auprès de la banque de son choix. Le formulaire est celui de la banque, mais la mise en page s'adapte au type d'acteur de l'opérateur : une coopérative soumet des documents de coopérative ; un négociant agréé soumet des documents de négociant ; un mineur artisanal suit le parcours d'identification individuelle. Les documents requis se présentent sous forme de liste structurée, avec le suivi d'avancement ligne par ligne.
Le même workflow couvre les deux réponses possibles à la question « l'organisation est-elle déjà cliente de la banque ? » captée à l'inscription. Les nouveaux candidats passent en évaluation de niveau 2 après approbation ; les clients existants déclarés voient leur relation confirmée et passent directement au monitoring de niveau 2. La banque vérifie la soumission dans les deux cas. La réponse ne change que ce qui se produit après approbation.
À la première soumission, un canal de partage s'ouvre entre l'opérateur et la banque. Les deux parties voient l'état de la candidature, les documents partagés, et le rôle affecté à la revue. Après soumission, l'opérateur débloque immédiatement les modules complets de constitution de profil de la plateforme (Auto-évaluation et Diligence Raisonnable), de sorte que les candidats motivés peuvent renforcer leur dossier dès le premier jour plutôt que d'attendre la décision de la banque.
Inscription à l'initiative de la banque
Les banques peuvent également ouvrir un dossier de contrepartie de leur côté. L'écran d'inscription expose deux points d'entrée. Le premier crée un dossier pour un nouveau candidat que la banque souhaite intégrer, un parcours en trois étapes qui s'achève par le passage en niveau 2 après approbation de l'examinateur. Le second crée un dossier pour une contrepartie que la banque a déjà examinée en dehors de la plateforme, un parcours en deux étapes qui saute l'intervention de l'examinateur et place le dossier directement en évaluation.
Cette distinction existe parce que les deux situations comportent des sémantiques de revue différentes. Un nouveau candidat n'a pas encore été examiné, le parcours d'examinateur standard s'applique donc. Un client existant a déjà été examiné, parfois depuis des années ; KOTA est l'endroit où son dossier réside désormais, et non l'endroit où sa vérification initiale est rejouée. Les deux parcours reposent sur la même structure de formulaire, la même validation et les mêmes intrants de scoring.
À partir de là, les deux parcours convergent avec ceux initiés par l'opérateur. La compilation, l'évaluation et les workflows de cycle de vie qui suivent se comportent de manière identique. Le seul endroit où l'origine compte est la piste d'audit.
Invitation client
Lorsqu'une banque détient un dossier interne sur une contrepartie dépourvue d'accès numérique, elle peut inviter l'opérateur à rejoindre KOTA à tout moment dès lors que le dossier a atteint le niveau 2. L'invitation crée un compte pour l'opérateur et lui accorde des droits d'édition sur les données que la banque a déjà compilées.
Côté opérateur, l'invitation arrive sous la forme d'un courriel contenant un lien d'inscription. En l'acceptant, l'opérateur hérite du cliché de la banque comme son propre point de départ (partiellement compilé, prêt à être vérifié, étendu et partagé avec la contrepartie suivante). La garde est transférée proprement : la banque conserve sa copie indépendante pour la suite de la relation, et l'opérateur démarre avec son propre profil de travail.
C'est l'expression au niveau plateforme de la manière dont les données circulent entre comptes dans KOTA. Le mécanisme est le même que celui qui sous-tend le partage de données entre toute paire de contreparties, simplement appliqué ici au moment de l'invitation.
Intégration coopérative
Pour les agrégateurs consolidant la production coopérative, KOTA propose une variante tenancière adaptée à l'intégration coopérative. Le jeu de formulaires est resserré sur ce dont les coopératives ont réellement besoin ; la dimension type d'acteur supprime les parcours individuels non pertinents ; les libellés de rôles et le modèle d'examen s'adaptent à la réalité opérationnelle de l'agrégateur.
Ce qui reste constant, c'est la méthodologie. Le même socle de scoring, les mêmes règles de garde, le même profil structuré, gouvernés de manière centrale par Datastake et hérités par chaque partie adoptrice. Les variantes par locataire d'un même schéma sont de premier rang sur la plateforme, et non des personnalisations ajoutées après coup.
La coopérative reste propriétaire de son profil. L'agrégateur obtient un dossier ajusté à son programme. L'opérateur peut ensuite engager une banque sans reconstruire le dossier. Le dossier structuré voyage avec l'opérateur d'une contrepartie à l'autre. C'est le bénéfice cumulatif à long terme.
02
Constituer le profil structuré.
Une fois l'opérateur dans le système, la compilation est le travail patient qui consiste à transformer la réalité opérationnelle en dossier défendable. KOTA décompose ce travail en éléments qu'un opérateur peut achever, en langage clair, à son propre rythme. Chaque champ est expliqué en fonction du travail que l'opérateur accomplit sur le terrain, et non dans le langage d'un manuel juridique. Trois modules portent la charge de la compilation : le parcours d'héritage pour les opérateurs invités, l'Auto-évaluation pour le KYC et les Systèmes de Gestion, et la surface de reporting continu Diligence Raisonnable.
Héritage à l'inscription sur invitation
Quand un opérateur rejoint KOTA sur invitation d'une banque, les données que la banque avait déjà compilées alimentent le compte nouvellement créé de l'opérateur comme sa propre copie. L'événement est ponctuel, ce n'est pas un lien vif. La garde passe à l'opérateur à la soumission ; la banque conserve sa copie indépendante pour la suite de la relation.
C'est ainsi que le travail démarre côté opérateur sans avoir à tout saisir deux fois. La compilation diligente de la banque devient le profil de travail de l'opérateur dès la première session : champs pré-remplis, documents attachés, prêt à être vérifié et complété par l'opérateur avec les informations que lui seul peut fournir.
Le principe s'applique dans les deux sens. Chaque fois que des données circulent entre parties dans KOTA, ce mouvement est un événement de garde : une nouvelle copie est créée, ce n'est pas un lien. Chaque partie est propriétaire de sa copie à partir de ce moment, sans mises à jour vives renvoyées à la source. C'est ce qui permet à plusieurs contreparties d'engager le même opérateur sans partager une base de données unique, et ce qui permet à chaque partie d'exécuter sa propre analyse sur les données qu'elle détient.
Auto-évaluation de l'opérateur
L'Auto-évaluation est le module de conformité structuré que les opérateurs utilisent pour compiler les données que les banques évaluent. Elle s'articule autour de trois groupes de formulaires. Le KYCest le profil de conformité structuré, organisé selon les sections standard qu'attendent les banques pour la vérification d'identité, la structure de l'actionnariat et le contexte d'exploitation. Les informations déjà fournies à l'Inscription et au niveau 1 sont pré-remplies : rien n'est saisi deux fois. Les Informations complémentairesse placent aux côtés du KYC pour les captures spécifiques à un déploiement ou non standard (par exemple les déclarations FATCA pour le déploiement TMB), de sorte que le profil KYC standard reste cohérent d'un déploiement à l'autre.
Les Systèmes de Gestioncouvrent cinq sous-évaluations alignées sur l'étape 1 du Guide OCDE sur le devoir de diligence : Politique de Chaîne d'Approvisionnement, Systèmes de Gestion Internes, Intégrité de la Chaîne d'Approvisionnement, Engagement des Fournisseurs et Mécanisme de Grief. Chaque sous-évaluation dispose de son propre suivi de complétude et de sa barre de progression. Les indicateurs du module agrègent en un radar de préparation au risque visible à la fois par l'opérateur et par la banque examinatrice.
Chaque section est expliquée en langage clair, avec un accompagnement à chaque étape. L'opérateur sauvegarde sa progression et revient quand les documents sont à portée. La plateforme suit la complétude et signale ce qui manque encore, de sorte que l'opérateur sait toujours où il en est par rapport au standard, et que la banque examinatrice obtient un profil complet en contexte, défendable en revue et prêt à engager le marché.
Diligence Raisonnable et reporting continu
Là où le KYC capte quisont les partenaires commerciaux et les sites de l'opérateur, la Diligence Raisonnable offre un espace structuré pour compiler ce qui s'y produitdans la durée. Elle se débloque aux côtés de l'Auto-évaluation après la soumission de niveau 1 et reste disponible tout au long de la vie de l'opérateur sur la plateforme, non pas comme un événement d'intégration mais comme une surface de reporting continue.
Cinq sous-modules portent la charge. Partenaires Commerciaux étend l'identification de base captée dans le KYC en détail commercial pour chaque acheteur, fournisseur et intermédiaire. Sites d'Exploitation prolonge les données de localisation du KYC par les spécificités des mines, des unités de traitement et des entrepôts. Activités permet à l'opérateur d'enregistrer inspections, audits et événements opérationnels au fil de l'eau. Incidents capte les événements rapportés, les litiges et les moments de conformité d'une manière qui survit à la revue. Témoignages porte les attestations et références de tiers.
Chaque nouvelle entrée renforce le dossier de conformité de l'opérateur et le dossier d'engagement de la banque. L'information nouvelle alimente le profil de l'opérateur, devient visible dans l'analyse consolidée de la banque, et alimente le score recalculé en continu, de sorte que la relation ne se fige pas à l'intégration. L'information reste à jour à mesure que l'exploitation tourne.
03
Un scoring et des décisions que les banques peuvent défendre.
L'évaluation transforme un dossier compilé en décision de contrepartie que la banque peut défendre. Trois workflows régissent cette étape : comment la banque adopte les données opérateur comme sa propre copie, comment la revue de niveau 1 répartit la responsabilité entre trois rôles, et comment l'évaluation de niveau 2 dérive un résultat noté et classé à partir du profil structuré. La méthodologie Algorithmic Stakeholder Evaluation se trouve derrière le score : déterministe, rattachée aux preuves, et ajustable à la politique de la banque.
Adoption des données opérateur
Lorsqu'une banque reçoit la candidature d'un opérateur, elle peut adopter les données compilées de l'opérateur comme sa propre copie. L'événement de garde est ponctuel, ce n'est pas un lien vif. Les banques possèdent leurs copies de manière indépendante et conservent le contrôle total de ce qu'elles détiennent. Les mises à jour côté opérateur ne modifient pas silencieusement la vue qu'a la banque de l'opérateur.
C'est ce qui permet à plusieurs banques d'engager le même opérateur sans partager une base de données centrale. Le dossier de chaque banque est le sien, hébergé sous sa tenancy, gouverné par ses permissions, noté contre sa politique. La plateforme fournit le formulaire structuré et la méthodologie ; la banque fournit la décision.
Opérationnellement, l'adoption est exposée dans le flux de données lors de la complétion du formulaire de niveau 1. Là où le profil de l'opérateur porte déjà une valeur ou un document que requiert le formulaire, le champ se pré-remplit à partir de la soumission de l'opérateur ; l'Éditeur de la banque vérifie, ajuste là où c'est nécessaire, et adopte à la soumission.
Revue de niveau 1 par la banque
La candidature de niveau 1 atterrit avec trois rôles explicites. L'Éditeur alimente et prépare le dossier. Le Custodele soumet pour revue une fois prêt. L'Examinateurdécide : approuver, refuser ou retourner pour complément, avec un contrôle d'audit à chaque étape. Un même utilisateur peut détenir plusieurs rôles, ce qui est fréquent dans les équipes de petite taille.
Le routage des notifications suit l'origine de l'inscription. Les soumissions initiées en externe alertent l'opérateur et la pool d'examinateurs conjointement. Les dossiers de candidat initiés en interne alertent le Custode qui les a créés. Les dossiers de client existant initiés en interne sautent entièrement l'examinateur et produisent une notification unique à la soumission. La banque a déjà examiné la contrepartie, il n'y a donc pas de prétention à revoir.
Une revue de niveau 1 produit un résultat que la banque peut défendre : contrepartie identifiée, documentation structurée, complétude vérifiée et dossier prêt à passer en évaluation de niveau 2. En cas de refus, l'opérateur peut éditer et soumettre à nouveau ; en cas de retour pour complément, les éléments manquants sont signalés ligne par ligne, de sorte que l'opérateur sait exactement ce qui reste en suspens.
Évaluation de niveau 2 par la banque
Le niveau 2 se déroule à travers le Résumé Client : la vue consolidée qui rassemble les données d'Auto-évaluation, la documentation, les soumissions de Diligence Raisonnable, tout ce que la banque a compilé de son côté et toute information tierce. Depuis un seul écran, l'examinateur voit le dossier structuré, le score algorithmique et la chaîne de preuves qui le soutient.
Le score lui-même est produit par l'Algorithmic Stakeholder Evaluation, une innovation Datastake. Il est déterministe et transparent : chaque score remonte aux données sous-jacentes, et les mêmes intrants produisent toujours le même score, sans modélisation probabiliste ni boîte noire. Chaque composante porte un poids explicite rattaché à des preuves inspectables. La méthodologie est livrée prête à l'emploi et entièrement ajustable : les banques repondèrent les composantes, resserrent les seuils, intègrent leurs propres contrôles. La politique de crédit de la banque reste maîtresse de la décision ; le score est l'intrant qu'elle peut défendre sous contrôle réglementaire.
Sur la couche de notation, la banque applique sa propre échelle de A+ à E (ou son équivalent) au-dessus du score composite. La notation détermine quels services le client peut utiliser : comptes, durées de financement, fréquence de diligence raisonnable. Les niveaux de service relèvent de la politique de la banque ; KOTA fait remonter le score, la notation et les preuves qui les soutiennent, laissant à la banque le rattachement services-notation. Les examinateurs peuvent supplanter la notation calculée au cas par cas lorsque des considérations internes le justifient.
04
Maintenir le dossier à jour et portable.
L'intégration n'est pas un instant. Les workflows de cycle de vie gèrent les pans de la relation de contrepartie qui viennent après la première décision : les changements d'état pilotés par le risque qui reflètent la réalité opérationnelle, et la réutilisation des données structurées à travers les engagements de contrepartie élargis de l'opérateur. Ensemble, ils maintiennent la vue qu'a la banque de l'opérateur à jour, et l'investissement de compilation de l'opérateur portable.
Suspension d'un client
Le risque ne reste pas figé à l'intégration. Un examinateur peut suspendre un client actif à tout moment depuis le Résumé Client. La suspension met en pause le partage d'informations entre le client et la banque, verrouille la compilation de données continue de la banque sur ce client, et fait remonter un indicateur Suspendu visible dans toutes les listes et vues de revue où le client apparaît.
L'action est réservée au rôle d'examinateur. C'est un changement d'état d'ordre décisionnel, avec des conséquences d'audit, et non une simple édition de routine. La plateforme enregistre l'auteur, l'horodatage et la raison. Les dossiers passés et les décisions antérieures restent intacts ; la compilation historique n'est pas supprimée, seulement gelée.
La suspension est réversible. Lorsque la préoccupation sous-jacente se résout (sanctions levées, lacune documentaire comblée, incident signalé examiné), l'examinateur peut réintégrer le client, reprenant le flux de données et déverrouillant la compilation sans reconstruire le dossier de zéro.
Réutilisation des données à travers les services
Un opérateur ayant compilé un profil pour une contrepartie peut postuler auprès d'une seconde en une seule soumission. Les données structurées pré-remplissent la nouvelle candidature ; les champs de niveau 1 s'alimentent depuis le profil existant, les documents s'y attachent avec la provenance préservée, seuls les champs propres à la nouvelle contrepartie requièrent une attention fraîche. L'opérateur revoit, rafraîchit là où c'est nécessaire, et soumet, sans recompiler de zéro.
C'est l'effet de capitalisation côté opérateur qui rend l'usage soutenu de KOTA rentable. Le travail qu'un opérateur investit une fois rapporte sur chaque engagement de contrepartie suivant. À mesure que les exigences de deux contreparties divergent dans le temps, le ratio de pré-remplissage diminue, mais le principe demeure : le profil structuré est l'investissement cumulatif de l'opérateur, et KOTA le lui rend à chaque candidature.
Du côté de la banque, le mécanisme est invisible. Chaque banque reçoit sa propre copie des champs et documents pertinents, limitée au périmètre que l'opérateur a choisi de partager. Pas de base de données partagée, pas de lien vif entre contreparties, pas de visibilité inter-tenancy des données d'une banque par une autre. Chaque engagement reste souverain quand bien même le dossier de l'opérateur se capitalise.
05
Lire à travers les sources cloisonnées.
L'information du secteur a vécu en silos déconnectés pendant des décennies : dossiers bancaires, rapports d'audit, bases de programmes, registres publics, rapports de la société civile, compilations propres aux opérateurs. Les workflows de triangulation permettent aux banques de puiser dans ces sources et d'assembler des sujets d'intérêt en dehors du parcours formel de candidature, avec une provenance préservée à chaque étape.
Recherche de données
La Recherche de données est la surface bancaire pour enrichir un dossier Client à partir de sources externes : registres publics, services de vérification, rapports d'audit, rapports de la société civile, et autres applications de l'écosystème Datastake. Depuis un Résumé Client, le personnel de la banque déclenche une requête et adopte les résultats dans le dossier Client à ses propres conditions.
Les résultats apparaissent comme sources d'information complémentaires dans l'analyse consolidée du client, avec la provenance préservée. Chaque résultat adopté est journalisé avec sa source, l'horodatage de son adoption et le rôle de l'utilisateur qui l'a adopté, de sorte que ce qui est ajouté survit à un audit et reste traçable.
Les requêtes correspondent à des intentions structurées : trianguler la propriété effective ultime, valider la fiabilité des données, découvrir les liens commerciaux et de localisation entre contreparties connues, plutôt qu'une recherche en texte libre. La banque décide quelles sources interroger et quels résultats adopter.
Ajout d'un prospect
Certaines contreparties commencent comme des individus : un mineur artisanal, un négociant indépendant, une personne d'intérêt pour le monitoring continu. L'Ajout de Prospect crée un sujet individuel autonome rattaché au portefeuille de la banque sans exiger encore de candidature formelle. L'Éditeur ou le Custode de la banque alimente ce que l'on sait ; le dossier se loge dans la tenancy de la banque et alimente la triangulation à travers le portefeuille élargi.
Le prospect peut ensuite être développé en dossier opérateur complet, rattaché à une coopérative ou une entreprise existante, ou partagé avec une autre contrepartie à mesure que l'engagement mûrit.
Avec la Recherche de données, l'Ajout de Prospect boucle le travail d'information de la banque. La banque n'attend pas seulement que les opérateurs compilent et soumettent. Elle peut bâtir des sujets de sa propre initiative, les trianguler avec des sources externes, et les rattacher au réseau de contreparties plus large lorsque la bonne relation émerge.