Cadre d’intégration & conformité

L’offre Retail de HilmarCorp consiste en la publication, via API, d’un signal d’exposition à destination du client, selon un format standardisé. Le signal est destiné à être utilisé par le client pour piloter son exécution sur les instruments disponibles sur la plateforme sélectionnée, notamment des contrats perpétuels. Le service s’adresse à des utilisateurs capables d’évaluer les risques et de mettre en œuvre les contrôles nécessaires. Le présent document décrit exclusivement ce périmètre Retail. L’offre institutionnelle de HilmarCorp est une offre distincte, opérée selon des modalités et une documentation dédiées.

Le client demeure pleinement responsable de la décision d’utiliser ou non le signal, de son interprétation, de l’exécution des opérations, de la détention des actifs et du respect de ses propres obligations réglementaires, fiscales ou contractuelles. HilmarCorp ne prend aucune part à la conservation, à l’exécution ou à la gestion des actifs du client.

Aucun mandat, délégation ou transfert de responsabilité n’est opéré au bénéfice de HilmarCorp. Le connecteur local fourni à titre de référence s’exécute exclusivement sur l’infrastructure du client, sans transmission de secrets, d’identifiants ou d’accès à HilmarCorp.

Le flux opérationnel prévoit que le client interroge l’API HilmarCorp afin de récupérer le signal d’exposition. Le connecteur local, fourni à titre de référence, permet une intégration technique, mais sa configuration, son adaptation et sa maintenance relèvent exclusivement du client. L’exécution des ordres, la gestion des actifs et la tenue des journaux d’opérations sont opérées directement par le client, via son propre compte sur les plateformes d’échange sélectionnées.

Lorsque l’exécution est réalisée sur des instruments dérivés (dont contrats perpétuels), le connecteur local n’a pas vocation à définir, à lui seul, les paramètres de marge et de levier de la plateforme ; il appartient au client de les configurer, de les contrôler et de s’assurer de leur adéquation.

Les secrets d’accès aux plateformes d’échange (clés API, droits d’accès) ne transitent jamais par HilmarCorp et doivent être stockés et gérés par le client, selon des modalités appropriées (coffre de secrets, variables d’environnement, etc.). Il appartient au client de limiter les permissions aux stricts besoins opérationnels et de mettre en place une gouvernance adaptée.

Le client doit mettre en œuvre des dispositifs de gestion des risques adaptés, comprenant la définition de limites, l’activation d’un dispositif d’arrêt d’urgence (kill switch), ainsi qu’une supervision continue du fonctionnement du connecteur et des flux d’exécution. La responsabilité de la surveillance, du contrôle et de la conformité demeure intégralement du ressort du client.

La publication consiste en la mise à disposition d’un signal d’exposition, entendu comme une information technique sur la cible d’exposition nette du portefeuille, exprimée en fraction du capital notionnel alloué par le client. Par construction, la valeur du signal est bornée dans l’intervalle [-1, 1] et n’encode aucun paramètre de levier. Les paramètres de marge, de levier, de liquidation et, plus généralement, les modalités d’exécution relèvent exclusivement des choix du client et des règles de la plateforme utilisée. Chaque publication est horodatée en UTC et assortie d’une fenêtre de validité documentée. En cas de non-publication, le comportement attendu côté client (maintien, neutralisation, repli) est défini par le client et documenté. Ce signal ne constitue pas une instruction d’exécution, ni une recommandation personnalisée. Les paramètres de lecture et d’interprétation (bornes, neutralisation, calendrier, seuils) sont précisés dans le Data Contract applicable à la version du service.

Le contrat de données encadre la structure, le format, le versioning et la gouvernance des publications : chaque signal comporte un identifiant unique, des métadonnées de version. Toute évolution substantielle du schéma suit une procédure formalisée, incluant préavis, documentation et, le cas échéant, plan de migration.

L’intégrité des messages repose sur une empreinte cryptographique (manifest/hash) et, selon les modalités d’intégration, peut inclure un mécanisme d’authentification de la source (signature, mTLS, ou équivalent). Ces modalités sont précisées dans la documentation technique et doivent être vérifiées par le client.

L’accès à l’API est soumis à une authentification par identifiants dédiés, sous le principe du moindre privilège. Les autorisations sont limitées au périmètre strictement nécessaire et font l’objet de procédures de rotation et de révocation. Les communications sont chiffrées en transit (TLS).

Les accès et événements opérationnels sont journalisés à des fins d’exploitation et de traçabilité. Les mesures de sécurité comprennent le contrôle d’accès, la segmentation, l’allowlisting, et, le cas échéant, l’usage de mTLS. Aucun accès aux comptes de trading ou aux secrets du client n’est possible côté HilmarCorp.

Le connecteur local est conçu pour limiter l’exposition des secrets, en privilégiant la lecture depuis un coffre sécurisé, l’absence de journalisation des clés et la restriction des permissions aux stricts besoins. Il revient au client de configurer les droits d’accès et de mettre en place les protections complémentaires (restrictions IP, authentification renforcée) sur les plateformes d’échange.

La gestion des vulnérabilités repose sur une démarche proportionnée, incluant le suivi des dépendances, l’application des correctifs et l’adoption de pratiques de développement visant à réduire la surface d’attaque. Des synthèses ou résultats de contrôles techniques peuvent être transmis sur demande, sans garantie d’exhaustivité.

L’exploitation du service ne nécessite pas la transmission de données de trading du client ni l’accès à ses comptes sur plateformes d’échange. L’API délivre une cible d’exposition et des métadonnées purement techniques. HilmarCorp ne collecte ni ne détient les clés d’accès aux plateformes d’échange et ne conserve aucun actif pour le compte du client. Les seules données collectées concernent la gestion de l’abonnement (données de compte, de facturation) et les journaux techniques nécessaires à la fourniture du service.

Les durées de conservation, les règles de suppression et les modalités de purge des données sont définies et communiquées. Sur demande ou à l’issue de la relation contractuelle, les données de compte et les journaux sont supprimés conformément à la politique applicable, avec traçabilité lorsque cela s’impose. Si des données personnelles sont traitées à titre accessoire (support, contacts, logs techniques), les mesures de sécurité et les responsabilités sont précisées dans un accord de traitement (DPA) si requis par la réglementation.

Le dispositif est structuré selon une approche opérationnelle formalisée : supervision de la disponibilité de l’API, de la latence, des erreurs et des anomalies de schéma, avec alertes selon des seuils préétablis. Les procédures de reprise sont documentées et reposent sur l’idempotence côté client, la gestion contrôlée des tentatives de reconnexion et la prise en compte de l’absence temporaire de publication.

Il appartient au client de définir et de maintenir une politique de repli adaptée (par exemple maintien de la dernière valeur valide, neutralisation de l’exposition, ou autre règle de continuité choisie), ainsi que les modalités de supervision et de journalisation locales. HilmarCorp peut, en cas d’incident significatif, communiquer des informations relatives à la nature, à l’impact et à la résolution de l’incident, dans le respect des obligations contractuelles et réglementaires applicables.

La gestion des incidents s’appuie sur une classification interne, un runbook d’escalade et des procédures de résolution documentées. Lorsque pertinent, un compte rendu post-incident et un suivi des mesures correctives sont transmis. Ce dispositif vise à être compatible avec les exigences de gouvernance rencontrées dans le secteur financier, sans préjudice des obligations propres du client.

La documentation du produit a pour objet de permettre une compréhension précise des caractéristiques du service : conventions relatives au signal, hypothèses d’interprétation, limites et risques associés. Les éléments de performance historique éventuellement communiqués sont présentés avec leurs hypothèses (données, frais, slippage, contraintes, périodes), leurs limites (risque de sur-ajustement, biais de sélection, conditions de marché non reproductibles) et une mention explicite de l’absence de garantie de performance future. L’information est fournie dans une perspective de transparence et de maîtrise des risques.

Le protocole de robustesse comprend des validations hors échantillon, des tests de sensibilité (frais, frictions, délais), des analyses de stabilité de régime et des contrôles de dégradation. La liste des tests et des rapports fournis est définie par version, dans une logique de traçabilité et de reproductibilité.

La présente section décrit le cadre méthodologique appliqué à toute communication de résultats historiques. Elle n’a pas pour objet de valoriser des performances, mais de préciser un standard de preuve : traçabilité des hypothèses, reproductibilité des calculs et comparabilité des résultats. Les résultats (s’ils sont publiés) sont présentés avec leurs hypothèses, limites et paramètres.

Le cœur du dispositif repose sur une règle simple : l’évaluation hors-échantillon (OOS) est conduite sur un segment temporel strictement postérieur à l’apprentissage et à la sélection du modèle. La sélection admissible du modèle s’effectue sur validation uniquement, sans recours au test. Les transformations appliquées à l’observation en OOS répliquent celles de l’entraînement, sans introduire de conventions ad hoc.

Évaluation OOS. L’évaluation consiste en un rollout complet de la politique sur le segment test, avec export systématique d’une trace pas-à-pas (horodatage, exposition, equity, drawdown, coûts si disponibles, événements techniques). La philosophie est opérationnelle : une métrique agrégée doit pouvoir être reconstituée à partir d’événements élémentaires, sans interprétation manuelle.

La comparaison est conduite contre des références alignées temporellement. Un Buy & Hold est reconstruit sur les mêmes timestamps, et une variante vol-target peut être produite afin de comparer des profils à volatilité comparable, sans changer la nature du benchmark. Les hypothèses (frais, frictions, calendrier, conventions de calcul) sont explicitées dans le rapport.

Robustesse. La robustesse est traitée comme une propriété méthodologique : la conclusion ne doit pas dépendre d’une seule période, d’une seule seed ou d’une hypothèse unique de frictions. Le protocole vise donc à produire des distributions de métriques (médianes et quantiles), plutôt qu’un « meilleur run ».

Concrètement, la robustesse combine un walk-forward temporel (répétition sur plusieurs fenêtres), des exécutions multi-seeds (variabilité stochastique), une estimation d’incertitude par rééchantillonnage par blocs (dépendance temporelle), et des stress tests opérationnels (sensibilité aux coûts et extraction de fenêtres « pire cas »). Lorsque plusieurs essais sont réalisés, leur nombre est documenté et la lecture des résultats est formulée sur des résumés robustes (quantiles), afin de limiter les biais de sélection.

Dans le cadre de l’offre Retail, HilmarCorp intervient exclusivement en qualité de fournisseur de technologie, en publiant une information technique et une documentation d’intégration standardisée. Le service proposé ne comprend ni conservation d’actifs, ni exécution d’ordres, ni transmission d’ordres, ni gestion de portefeuille, ni réception d’instructions, ni tenue de comptes ou de positions. Le service ne procède à aucune évaluation d’adéquation ou de convenance, ni à aucune personnalisation du signal transmis.

Lorsque le client utilise des instruments dérivés, y compris des contrats perpétuels, ces instruments peuvent comporter un effet de levier et un risque de perte rapide, notamment en cas d’appels de marge ou de liquidation. Le client demeure seul responsable de vérifier son éligibilité, les restrictions applicables (réglementaires et plateforme) et la conformité de l’utilisation du service au regard du cadre juridique pertinent.

Un contrat perpétuel est un instrument dérivé sans échéance, généralement adossé à un mécanisme de financement, et pouvant être négocié sur marge.

Les contrats perpétuels peuvent impliquer des paiements de financement (funding) susceptibles d’affecter la performance et le risque.

Selon les règles de la plateforme et les conditions de marché, les pertes peuvent être rapides et, dans certains cas, excéder le collatéral initialement alloué.

La qualification juridique du service dépend des modalités concrètes d’utilisation et du contexte de la juridiction concernée. Le client demeure seul responsable de la conformité de ses opérations, du respect de la réglementation applicable (y compris fiscale, LCB/FT, restrictions propres aux plateformes d’échange), de la supervision de l’exécution, de la gestion de la conservation et de la mise en place des contrôles internes appropriés.

Il appartient au client de vérifier l’adéquation des instruments utilisés, la conformité de l’utilisation du service à son propre cadre, aux règles de la plateforme d’échange, et aux obligations légales et réglementaires applicables. HilmarCorp n’intervient pas dans la sélection des instruments, l’exécution, le choix des plateformes ou l’implémentation des contrôles du client. Le client est invité à solliciter ses propres conseils.

L’intégration standard implique la création de l’accès API, la récupération du Data Contract à jour, l’installation du connecteur local de référence, la configuration des paramètres critiques (seuils, limites, calendrier, comportement en cas de non-publication), la gestion des secrets d’accès dans un coffre sécurisé, la réalisation d’une recette contrôlée (mode simulation ou dry-run), puis le passage en exécution effective sous supervision renforcée. Il est conseillé d’appliquer des limites prudentes lors des phases initiales et de procéder à des ajustements progressifs selon l’expérience opérationnelle.

Le périmètre d’accompagnement se limite aux questions d’intégration technique (format, versioning, idempotence, gestion des erreurs). HilmarCorp n’intervient jamais sur le compte d’échange du client, ni dans la prise de décision, ni dans la gestion du risque. L’ensemble des décisions d’exécution, de gestion et de contrôle incombe exclusivement au client.

Avis important. Les actifs numériques présentent un risque significatif de perte en capital. Aucun rendement, résultat ou performance n’est garanti. Les informations fournies dans cette documentation sont de nature générale et technique ; elles ne constituent ni une recommandation personnalisée, ni un conseil en investissement, ni une sollicitation à l’exécution d’opérations. L’utilisation du signal sur des instruments à effet de levier (dont contrats perpétuels) peut amplifier les pertes et exposer à une liquidation ; le client est invité à s’assurer que ces instruments correspondent à sa situation et à son cadre de conformité. Selon les règles de la plateforme et les conditions de marché, les pertes peuvent être rapides et, dans certains cas, excéder le collatéral initialement alloué.

Non-reliance. Ce document ne saurait être interprété comme une documentation contractuelle, une garantie d’exécution, ni un engagement de disponibilité. Le client ne saurait s’y fier comme substitut à ses propres diligences, contrôles internes ou à un avis professionnel indépendant. Il est expressément recommandé de solliciter ses propres conseils juridiques, fiscaux et réglementaires avant toute utilisation du service.

Responsabilités. Le client demeure seul responsable de l’interprétation du signal, de la décision, des contrôles, de l’exécution, de la conservation des actifs, ainsi que du respect de la réglementation applicable et des conditions d’utilisation des plateformes d’échange. HilmarCorp ne reçoit ni ne stocke de clés d’accès aux plateformes, n’accède à aucun compte de trading et n’exécute pas d’ordres.