Cadre d’intégration institutionnel & conformité

HilmarCorp délivre, à fréquence quotidienne, une cible d’exposition non binaire sur une poche crypto définie avec le client. Le service est conçu comme un overlay d’exposition : HilmarCorp opère le moteur (production de signaux, logique de rebalancement, contrôles de cohérence et de publication) et met à disposition les éléments nécessaires au suivi, à la traçabilité et à l’audit, sans intervenir sur la conservation des actifs ni sur l’exécution.

Le client conserve l’entière souveraineté opérationnelle. Il conserve la custody, l’OMS/EMS, l’exécution ainsi que l’ensemble de ses processus internes (limites, conformité, validations, supervision). Le client définit l’univers investissable, ses exigences de liquidité, ses lieux d’exécution et les contraintes propres à son dispositif. L’overlay est ensuite calibré pour opérer dans ce périmètre, selon des conventions de livraison et de traçabilité alignées avec les standards institutionnels.

Dans le cadre des pilotes, HilmarCorp intervient comme fournisseur de technologie intégré au dispositif du client. La décision finale, la supervision et la responsabilité d’exécution demeurent côté client, y compris au travers de mécanismes d’override, de limites, de validations et de contrôles internes.

Les modalités de livraison sont arrêtées lors du cadrage du pilote, en fonction de vos contraintes d’exploitation, d’archivage, de réconciliation et de contrôle. Selon l’architecture cible, la consommation peut être réalisée via API (pull), par livraison batch via espace d’échange (SFTP/S3 ou équivalent) ou par publication sur bus d’événements (Kafka ou équivalent).

Le contrat de données est versionné et conservateur : horodatage en UTC, schémas stables, règles de compatibilité documentées, idempotence et procédures de reprise explicitement définies. Chaque publication porte un identifiant unique, destiné à permettre la réconciliation entre livraison, ingestion, transformations internes et reporting. Toute évolution significative fait l’objet d’une gouvernance de changement convenue avec vos équipes (versioning, préavis, plan de migration, et, le cas échéant, mécanismes de rollback).

L’intégrité des publications repose sur des contrôles d’empreinte (manifest/hash) et, lorsque requis, sur des mécanismes permettant d’attester l’authenticité de la source. Selon le mode de livraison, les payloads peuvent ainsi être signés ou authentifiés (signature applicative, PGP, certificats client en mTLS ou mécanismes équivalents), de manière à permettre une vérification côté client de l’origine et de l’intégrité des données reçues.

Lorsque la chaîne d’échanges du client s’appuie sur une norme de place telle que penelop-XML, HilmarCorp peut, dans le cadre du pilote, proposer un mapping et un adaptateur d’export, incluant schéma cible, règles de validation et jeux d’essai pour recette, afin d’aligner le format de livraison sur les conventions SI en place.

Les conventions d’exposition sont figées au cadrage du pilote et formalisées dans une annexe « Data Contract ». Cette annexe précise notamment la sémantique du signal, les unités, les bornes, la granularité, les conventions multi-actifs, le calendrier de publication, ainsi que les hypothèses d’interprétation nécessaires à une transformation en ordres, transformation qui demeure sous la responsabilité exclusive du client.

Les échanges ne requièrent pas, par conception, de données clients nominatives : ils portent sur des signaux d’exposition et des métadonnées d’intégration. La classification des données (internal/confidential), la localisation d’hébergement (UE/EEE lorsque requis), la politique de rétention et les principes de minimisation sont définis au cadrage. Les durées de conservation, les règles de purge et les modalités de suppression sont également cadrées et documentées, avec traçabilité des opérations de suppression lorsque applicable.

Par conception, l’overlay ne requiert pas de données personnelles. Si, à titre exceptionnel, des données personnelles devaient être traitées (par exemple, des contacts opérationnels ou certains journaux techniques), les rôles respectifs (responsable de traitement / sous-traitant), la base légale, les mesures de sécurité, ainsi que, le cas échéant, un accord de traitement (DPA) sont formalisés conformément au RGPD.

{
  "publication_id": "pub_2026-01-31_00-00-00Z",
  "ts_utc": "2026-01-31T00:00:00Z",
  "universe_id": "client_universe_v1",
  "exposure_target": { "type": "portfolio_exposure", "value": 0.35 },
  "engine": { "engine_version": "0.1.0", "schema_version": "1", "environment": "pilot" },
  "integrity": { "manifest_sha256": "..." }
}

L’auditabilité est conçue comme une propriété du dispositif. Chaque publication est rattachée à un identifiant stable, à un schéma versionné et à une version moteur. Les empreintes (manifest/hash) permettent une vérification ex post de l’intégrité des payloads transmis et la détection de divergences entre livraison, ingestion et consommation.

Selon les exigences du client, les artefacts d’audit (publications, manifests, journaux) peuvent être conservés dans des conditions rendant toute altération détectable ex post, notamment via des mécanismes de scellement (hash chain) ou des stockages à propriétés d’immutabilité (WORM ou équivalent), sans préjuger du dispositif technique retenu.

La traçabilité est cadrée de bout en bout : publication, réception, transformations éventuelles, contrôles et exceptions. L’objectif est de permettre une reconstitution robuste des événements clés sur un horizon de rétention défini, au bénéfice du contrôle interne, des revues de gouvernance et, le cas échéant, de l’audit.

Le service est conçu selon le principe du moindre privilège. Les accès sont gérés par identifiants et clés dédiés, avec rotation/révocation, séparation des environnements et journalisation des actions. Les échanges sont chiffrés en transit (TLS) et le périmètre de données livré est minimisé et cadré.

Aucun secret n’est exposé côté front public. L’intégration côté client s’opère via variables d’environnement ou coffre de secrets, selon l’architecture cible. La posture réseau (segmentation, allowlisting, mTLS si requis) et les pratiques de gestion des clés (KMS/HSM ou équivalent), ainsi que le chiffrement au repos des artefacts pertinents, sont définis au cadrage et documentés dans le dossier de sécurité du pilote. Les politiques de conservation des logs (rétention, horodatage, intégrité) et, le cas échéant, l’archivage des artefacts d’audit sont alignés sur les exigences du client.

Le périmètre pilote s’inscrit dans un processus de sécurité applicative proportionné : suivi des correctifs, gestion des dépendances, revues d’accès périodiques et journalisation des opérations sensibles. Lorsque requis, des éléments d’assurance (questionnaires, synthèses de scans ou tests proportionnés) peuvent être partagés dans le cadre de la due diligence.

Les accès opérationnels et les droits de déploiement sont séparés et journalisés ; les interventions en environnement pilote et, le cas échéant, en environnement de production suivent un processus d’approbation et de traçabilité, permettant une revue a posteriori.

Le dispositif est conçu pour une exploitation réaliste : supervision de la complétude de livraison, de la latence, des erreurs et des anomalies de schéma, avec alerting selon des seuils définis au cadrage. Les procédures de reprise sont documentées dès le démarrage du pilote.

En API, la reprise s’appuie sur des requêtes idempotentes et des politiques de retry/backoff contrôlées. En batch, la republication est contrôlée au moyen des manifests et identifiants de publication. En streaming, les mécanismes de replay reposent sur la politique de rétention et les offsets, dans un cadre documenté.

Les engagements opérationnels du pilote sont formalisés dans un runbook : fenêtre de publication quotidienne (cut-off), tolérance de latence, règles de maintenance planifiée, canaux d’escalade, classification des incidents et responsabilités respectives. La notification d’incident (délais, destinataires, contenu minimal), définie au cadrage selon la criticité, s’accompagne, lorsque pertinent, d’un compte rendu post-incident et d’un suivi des actions correctives.

En cas de non-publication, d’anomalie de schéma ou de données incomplètes, le comportement attendu est défini à l’avance (maintien du dernier signal valide, neutralisation, ou politique de repli convenue). Un mécanisme de gel/override côté client est prévu afin de préserver la maîtrise opérationnelle en toutes circonstances.

La continuité d’activité fait l’objet d’un dispositif proportionné au périmètre du pilote : sauvegardes, procédures de restauration, points de contact et modalités de reprise, afin de garantir la continuité de publication ou l’activation d’un mode dégradé convenu.

Le client demeure responsable de son dispositif réglementaire et de conformité. HilmarCorp fournit une brique technique (livraison d’exposition et traçabilité) intégrée au dispositif du client, et adapte la documentation de due diligence au périmètre retenu.

Lorsque le périmètre porte sur des instruments de type dérivés, le référentiel mobilisé côté institutions se rattache généralement au cadre applicable aux instruments financiers (notamment MiFID II) et, selon le dispositif du client, aux obligations de reporting ou de clearing (par exemple, EMIR). La qualification juridique de la prestation ne repose pas sur des formules de style : elle dépend des modalités concrètes d’intégration, du niveau de personnalisation, de la gouvernance et de la capacité de contrôle/override détenue par le client. Dans le cadre des pilotes, HilmarCorp est opéré comme fournisseur de technologie ; la décision finale, la supervision et l’exécution restent côté client.

Les évolutions du schéma et du moteur sont gouvernées : versioning sémantique, revues, approbations, traçabilité des releases, compatibilité ascendante, plan de migration et mécanismes de retour arrière lorsque nécessaire. La séparation des rôles et les droits de déploiement sont cadrés, conformément aux standards attendus en environnement régulé.

Le pilote inclut une gouvernance “model risk” proportionnée : indicateurs de stabilité, contrôles d’anomalies et conditions de désactivation en cas de comportement non conforme. La capacité de gel/override côté client constitue un élément central du dispositif de maîtrise.

La documentation de due diligence couvre notamment la gestion des incidents, la continuité, la sécurité, le contrôle d’accès, la rétention, la protection des données, les sous-traitants, les modalités d’audit et l’allocation des responsabilités. Les documents détaillés (security pack, privacy, incident response, change management, third-party risk, runbook et engagements opérationnels du pilote) sont fournis une fois le périmètre cadré.

Lorsque la tarification inclut une composante variable, celle-ci est encadrée (plafonds, bornes, transparence) afin de limiter les incitations au churn. HilmarCorp n’intervient pas sur l’OMS/EMS, la sélection des lieux d’exécution ni l’exécution ; le client conserve ses contrôles, limites et validations. En pratique, une tarification fixe est privilégiée au stade pilote, avec une composante variable optionnelle, plafonnée et définie contractuellement.

La liste des prestataires et dépendances critiques (cloud, sources de données, observabilité) et les responsabilités associées sont communiquées au cadrage, ainsi que la politique de changement de sous-traitant et les modalités de notification.

Les modalités de confidentialité (NDA), les responsabilités, les droits d’audit sur le périmètre du pilote et la propriété intellectuelle sont définis contractuellement. Le client conserve la propriété de ses données et de ses décisions d’exécution ; HilmarCorp conserve la propriété de son moteur et de ses artefacts logiciels, sous réserve des engagements convenus pour l’exploitation du pilote.

Responsabilités et non-reliance. Les signaux d’exposition fournis dans le cadre du pilote constituent une information technique destinée à être intégrée au dispositif du client. Le client demeure seul responsable de l’interprétation, des contrôles, de la décision et de l’exécution. Les conditions de responsabilité, de limitation et de non-reliance sont définies contractuellement au cadrage du pilote.

Toute mention du client, de son nom, de son logo ou du pilote dans une communication externe est soumise à accord écrit préalable.

Un pilote institutionnel débute par un cadrage précis : univers et contraintes, calendrier, modalités d’exploitation (paper, advisory overlay, ou mise en œuvre progressive), points de contrôle, responsabilités et critères de succès. Le cadrage formalise les conventions de delivery et de supervision, la gouvernance des changements, les règles de validation des releases, les procédures d’escalade et les modalités d’audit. Le calendrier distingue la phase de cadrage/contractualisation et, le cas échéant, une phase d’exécution opérationnelle ultérieure, déclenchée après atteinte de jalons de stabilisation et de validation définis avec le client.

Les livrables sont orientés intégration et contrôle : conventions de delivery, schémas et mappings, annexe « Data Contract », runbook opérationnel, exigences de supervision et rapport de pilote. Les performances et les protocoles de robustesse (tests, stabilité, validation hors échantillon) sont communiqués lorsque le modèle est stabilisé, dans un cadre compatible avec la gouvernance et les exigences de conformité du client.