Paiements contextuels

Une extension téléchargeable et autonome qui illustre la couche d'ontologie contextuelle appliquée aux paiements ISO 20022 — contexte par source, transformations par propriété, contrats de données, ancres de normes et alias de concepts selon la direction. Il inclut ses propres données de démonstration.

L'exemple Paiements contextuels est une démonstration téléchargeable et interactive d'une ontologie contextuelle. Contrairement aux autres extensions d'exemple, elle inclut ses propres données de démonstration sous forme de sources de données déclaratives : un déploiement complet ne nécessite donc aucun import CSV. Une solution de repli CSV est néanmoins proposée pour les environnements de développement local où le réconciliateur de sources de données ne fonctionne pas.

Vous découvrez le sujet ? Lisez d'abord Ontologies contextuelles pour comprendre ce qu'est une ontologie contextuelle, quand elle est utile et quel problème elle résout. Cette page montre le résultat ; l'autre en explique la raison.

Le scénario

Vous gérez des opérations de paiement. Votre ontologie canonique contient un concept Payment et plusieurs concepts de parties (Counterparty, Beneficiary, Originator). Les données proviennent toutefois d'un système bancaire central sous la forme d'un relevé ISO 20022 pacs.008, dans lequel :

les montants sont exprimés en centimes entiers (1234556), et non en euros ;
les horodatages sont en UTC, et non dans le fuseau de comptabilisation ;
le terme « Counterparty » désigne une partie différente selon que le transfert est entrant ou sortant.

Une liaison simple aplatirait ces informations et les ferait disparaître. Cette extension enregistre au contraire le contexte de la source, normalise les valeurs avec des transformations déclarées, relie les concepts à ISO 20022, FIBO et LEI, puis enregistre des alias dépendant de la direction. Chaque Payment projeté reste ainsi fiable et explicable.

Ce que l'exemple démontre

L'extension modélise un concept canonique Payment alimenté par un relevé ISO 20022 pacs.008, de façon à conserver le sens de chaque valeur projetée. Chaque point correspond à un élément constitutif :

bindingContext — la liaison de paiement indique que le flux est un relevé ISO 20022 pacs.008 provenant de core_banking_x, comptabilisé en BE, avec une confiance de correspondance de 96 %, valide depuis le 2025-01-01.
transformMap — des transformations par propriété complètent la correspondance de colonnes : amount_minor, exprimé en unité mineure entière, est divisé par 100 pour produire amount en unité majeure ; settled_at_utc est normalisé vers Europe/Brussels. Les deux transformations sont marquées avec perte afin d'apparaître dans la provenance.
dataContract — paymentId, amount et currency doivent être projetés ; currency doit respecter ISO 4217 et amount doit être positif. Le contrat appartient à payments-platform-team.
anchors — des ancres de normes sur les types d'objets et les propriétés (ISO 20022 FIToFICstmrCdtTrf, IntrBkSttlmAmt, Ccy, FIBO LegalEntity, ISO 17442 LEI) rendent les concepts trouvables par identifiant externe.
aliases — la démonstration centrale de réconciliation : le même terme local Counterparty se résout vers un concept canonique différent selon le contexte.

Réconciliation, pas gagnant imposé. Le résolveur d'alias présente toutes les correspondances, classées par spécificité du contexte puis par confiance. Il ne réduit jamais silencieusement des sources divergentes à un enregistrement doré. Il en va de même pour les liaisons : la divergence reste visible dans l'enveloppe provenance.

Télécharger

L'extension est une archive .scrydon-extension.tar.gz téléchargeable ; elle n'est pas préinstallée avec la plateforme.

contextual-payments.scrydon-extension.tar.gz
— dernière version.
scrydon-pack-contextual-payments-1.0.3.scrydon-extension.tar.gz
— version figée.

L'archive contient trois types de contenu : l'ontologie et deux sources de données déclaratives (iso20022_pacs008_payments et core_banking_counterparties) qui chargent les lignes de démonstration. Il ne requiert ni API externe ni identifiants ; les sources émettent des lignes statiques intégrées selon une planification.

Installer

Charger l'extension

Téléchargez l'archive ci-dessus. Dans votre déploiement Scrydon, ouvrez Settings → Platform → Extensions → Sources, cliquez sur Upload an extension (one-off), déposez le fichier .tar.gz, cochez l'acceptation de l'extension non signée, puis cliquez sur Upload. L'extension apparaît dans le catalogue de l'organisation sous le nom Contextual Payments v1.0.3, avec trois contributions : une ontologie et deux sources de données.

L'activer pour un environnement d'espace de travail

Ouvrez la place de marché Ontology et activez Contextual Payments pour l'environnement d'espace de travail actif. Le réconciliateur de sources de données planifie les deux sources séparément pour cet environnement.

Attendre la première exécution

Les sources émettent leurs lignes lors de la première exécution planifiée. Celle-ci peut prendre jusqu'à une minute après l'installation. Deux tables gérées apparaissent ensuite sous Analytics → Tables : iso20022_pacs008_payments (6 lignes) et core_banking_counterparties (5 lignes).

Aucune table après une ou deux minutes ? Les sources intégrées n'écrivent des lignes que si le réconciliateur de sources de données et le planificateur Dapr fonctionnent, ce qui n'est souvent pas le cas dans un environnement local minimal. Si les tables n'apparaissent pas sous Analytics → Tables, importez les mêmes données manuellement :

Téléchargez les deux fichiers CSV :
- iso20022_pacs008_payments.csv
  (6 paiements) ;
- core_banking_counterparties.csv
  (5 contreparties).
Utilisez Analytics → Tables → upload pour chacun. Nommez exactement les tables iso20022_pacs008_payments et core_banking_counterparties : les liaisons utilisent ces noms logiques et restent not ready si les noms diffèrent.

Les colonnes CSV correspondent exactement à celles des liaisons. Dès que les tables existent, les liaisons se résolvent automatiquement et les ISSUES disparaissent de /graph.

Vous mettez à niveau une version antérieure ? Recharger l'extension ne suffit pas : vous devez aussi la réactiver pour l'environnement d'espace de travail. L'installation suit un modèle en deux étapes (ADR 2026-05-30-two-stage-extensions-install-vs-instantiate) :

Étape 1 — charger le .tar.gz dans Settings → Platform → Extensions → Sources installe ou met à jour l'ontologie et ses liaisons au niveau de l'organisation ;
Étape 2 — Marketplace → enable for this workspace-environment installe une copie distincte de l'ontologie et des liaisons pour l'environnement. C'est cette copie que le workbench et /graph affichent.

Un nouveau chargement ne réconcilie que la copie de l'organisation. Pour appliquer la version au workspace, adoptez-la explicitement. Une bannière Update apparaît dans Ontology Designer et un bouton Update to v<x> dans Marketplace.

L'action Update relance l'activation avec la dernière version et réconcilie en place identityColumns, columnMap, transformMap, bindingContext et source. Les mises à jour ne sont jamais silencieuses : un propriétaire du workspace décide de les adopter.

Les instances silver_table sont projetées à la lecture directement depuis la table source. Après la réconciliation, un rafraîchissement de /graph affiche donc immédiatement les valeurs corrigées.

Les premières versions utilisaient par erreur paymentId comme colonne d'identité au lieu de la colonne physique payment_id, ce qui pouvait afficher des identifiants null et l'erreur Table missing columns: paymentId. Ce défaut est corrigé depuis la version 1.0.2 ; la version 1.0.3 ajoute les types de liens du graphe. Chargez la dernière version, réactivez-la pour le workspace, puis actualisez la page.

Parcourir la démonstration

Les étapes suivantes supposent que les deux tables existent, soit après l'exécution planifiée, soit après l'import CSV. L'extension fournit déjà l'ontologie, le contexte, les transformations et les alias.

Observer la résolution automatique de la liaison

Ouvrez Ontology → Bindings et cliquez sur la ligne de liaison Payment (silver_table → iso20022_pacs008_payments) pour la développer. Puisque source.table correspond au nom de la table, la liaison se résout automatiquement. Son en-tête affiche le badge de contexte core_banking_x · 96%, son état est Ready, et les transformations sont déjà appliquées.

Un clic pour autoriser l'édition. Le bouton Pick table apparaît sur la ligne. La projection fonctionne déjà, mais la correspondance de colonnes reste en lecture seule tant que vous n'avez pas cliqué sur ce bouton. Sélectionnez iso20022_pacs008_payments pour résoudre l'identifiant physique de la table ; l'éditeur devient alors modifiable. Il s'agit d'une contrainte d'interface, pas d'une contrainte de données.

Le premier bloc est le formulaire Source context. Ses champs sont déjà remplis, car l'extension inclut le contexte de la liaison. Ils indiquent que ce flux est un transfert de crédit ISO 20022 sortant, issu du système bancaire belge, avec une confiance de 96 %.

Champ	Valeur	Signification
Source system	`core_banking_x`	Système en amont ayant produit les lignes
Standard	`ISO20022` · type `pacs.008`	Format du message
Jurisdiction	`BE`	Lieu de comptabilisation
Business process	`credit_transfer`	Événement métier représenté
Currency semantics	`minor_units`	Montants reçus en centimes entiers
Mapping confidence	`0.96`	Confiance de correspondance avec `Payment`
Valid from	`2025-01-01`	Date d'effet de la correspondance

Pourquoi est-ce important ? Une autre source pourrait produire des paiements pacs.009, des montants décimaux ou une autre juridiction. Le contexte permet aux analyses et à l'IA de distinguer ces valeurs et d'expliquer leur origine.

Examiner les transformations par propriété

Après avoir choisi la table, l'éditeur affiche une ligne par propriété et un menu Transform. Deux transformations sont préconfigurées :

amount ← amount_minor, transformation divide_by_100 : 1234556 devient 12345.56 ;
settlementTimestamp ← settled_at_utc, transformation timezone_normalize vers Europe/Brussels.

Les autres propriétés utilisent No transform (identity). Les deux transformations fournies sont marquées avec perte ; provenance.lossyProperties permet donc aux appelants d'identifier les valeurs dérivées.

Vous ne voyez pas les menus ? L'éditeur modifiable apparaît seulement après Pick table. Avant cela, l'interface montre une liste source → propriété en lecture seule.

Vérifier que le contexte accompagne les lectures

La confiance de 96 % et le contexte de source accompagnent chaque instance projetée dans une enveloppe provenance (confidence, bindingContext, lossyProperties) :

dans le graphe — le panneau de détail d'une instance affiche la section Provenance ;
dans le workbench Bindings — le badge core_banking_x · 96% sert de résumé par liaison ;
via l'API — POST /api/ontology/kernel/objects/query, exposé par objects.query dans le SDK d'ontologie, renvoie l'enveloppe de provenance ;
dans les tests — apps/api-ontology/src/kernel/source-backed/silver-table.test.ts vérifie les transformations contextuelles et la provenance, et les tests de requête d'objets source-backed vérifient le franchissement de la frontière de lecture gouvernée.

(Facultatif) Explorer le graphe

Ouvrez /graph. La première vue est le schéma : un nœud par type d'objet (Payment, Counterparty, Originator, Beneficiary) et l'en-tête 4 TYPES · 2 LINK TYPES.

Liens — Payment —Initiated by→ Originator et Payment —Sent to→ Beneficiary structurent le réseau. Counterparty n'a pas de lien dur : sa relation avec Originator ou Beneficiary est résolue par les alias contextuels.
Comptages — lorsque les tables existent, les nœuds indiquent Payment 6, Counterparty 5, Originator 6, Beneficiary 6. Avant cela, le total est inconnu.
ISSUES — signale une liaison dont la table source n'est pas résolue.
Instances — sélectionnez un type puis Expand instances pour afficher ses lignes.
Provenance — sélectionnez une instance pour voir la confiance, le contexte et les propriétés avec perte.

Résoudre un terme selon son contexte

Ouvrez Ontology → Aliases. Dans le panneau Test resolution, saisissez Counterparty, puis indiquez le contexte :

Contexte	Concept résolu	Raison
`standard = ISO20022`, `direction = outgoing`	Beneficiary	Dans un transfert sortant, la contrepartie est le bénéficiaire crédité.
`standard = ISO20022`, `direction = inbound`	Originator	Dans un transfert entrant, il s'agit du donneur d'ordre débiteur.
`sourceSystem = kyc_system`	Counterparty	Dans le référentiel KYC, il s'agit de l'entité juridique durable.

Un même terme peut ainsi désigner trois concepts canoniques. Les résultats affichent leur confiance et sont classés selon la spécificité du contexte.

(Facultatif) Suggérer une correspondance avec l'IA

Si une intégration LLM est configurée, développez une liaison, choisissez sa table, puis cliquez sur Suggest with AI. Le système profile les colonnes, demande au modèle de proposer une correspondance vers le type d'objet, puis affiche une liste à examiner. Apply N préremplit l'éditeur ; aucune publication n'a lieu sans validation humaine.

Pourquoi cet exemple est intéressant

Le sens plutôt que les colonnes — une requête de conformité sur les transferts sortants de plus de 10 000 € comptabilisés en Belgique peut expliquer la source, la direction et la sémantique du montant.
Ancré dans les normes — les ancres ISO 20022, FIBO et LEI rendent les concepts trouvables par identifiant externe sans imposer le vocabulaire local.
Autonome — les sources intégrées transforment l'extension en démonstration en un clic : installation, première exécution, puis projection contextuelle.

Pages associées

Ontologies contextuelles — le concept et ses cas d'usage.
Liaisons sensibles au contexte — le guide d'auteur et l'enveloppe provenance.
Créer des ontologies — le guide de base.
Fraude Intelligence — une ontologie typée appliquée aux données de criminalité financière.
Ontology → Extensions — distribution et installation des extensions.

Paiements contextuels

Sur cette page