Oxelbarrow remplace le timing de saisie manuelle par un modèle basé sur des règles qui ajuste la taille de la position en fonction de la volatilité mesurée, plutôt qu'en fonction du sentiment ou de la réaction globale.
Le day trading récompense la cohérence, mais la cohérence est difficile à maintenir sur des centaines de décisions discrétionnaires. La fatigue, le biais de récence et la réaction aux mouvements de prix à court terme s'accumulent tranquillement, et l'écart par rapport à une stratégie déclarée s'élargit à chaque séance.
Oxelbarrow a été conçu pour supprimer cette dérive en codant les critères d’entrée dans un ensemble de règles fixes et vérifiables – un ensemble de règles qui s’exécute de la même manière lors de la centième session que lors de la première session.
Le modèle ne tente pas de prédire la direction. Il tente de dimensionner et de chronométrer les entrées de manière à ce que le capital soit déployé proportionnellement au risque mesuré, selon une structure conditionnelle définie : si la volatilité réalisée dépasse un seuil mobile, le modèle réduit la taille de la tranche ; s'il se contracte en dessous de ce seuil, le modèle l'augmente dans une fourchette plafonnée.
La plateforme est structurée autour de trois préoccupations opérationnelles : la rapidité avec laquelle les données sont traitées, la manière dont le risque est contenu lorsque les conditions changent et le comportement du système à mesure que le nombre d'instruments augmente.
Les flux de marché sont ingérés en continu avec une latence de traitement interne inférieure à la seconde, de sorte que les décisions de dimensionnement reflètent les conditions actuelles plutôt qu'un instantané obsolète de l'intervalle précédent.
Les plafonds stricts sur la taille des tranches, l’exposition des instruments et le déploiement quotidien se situent sous la couche prédictive, de sorte qu’une mauvaise lecture du modèle ne peut pas se traduire par une taille de position illimitée.
Les couches d'ingestion et de décision sont séparées, ce qui permet d'ajouter des instruments ou des sources de données supplémentaires sans retravailler la logique d'entrée de base.
Les données sur les prix, les volumes et les carnets de commandes sont extraites de sources connectées et normalisées dans un schéma cohérent avant tout calcul.
Les données de volatilité et de profondeur sont transmises via le modèle d'entrée pour produire une recommandation de tranche, horodatée et stockée pour un audit ultérieur, quel que soit le résultat.
La recommandation est vérifiée par rapport aux contraintes au niveau du compte, puis soumise sous forme de commande si, et seulement si, chaque contrainte est résolue.
Les connexions utilisent des clés API de lecture/échange que vous générez et révoquez à partir de votre propre compte de courtage. Oxelbarrow ne stocke jamais les informations de connexion brutes et les clés sont chiffrées au repos.
Le traitement interne, depuis la réception des données jusqu'à la recommandation de tranche, s'effectue en moins d'une seconde dans des conditions d'alimentation normales. Le délai de soumission des ordres dépend alors de la vitesse d'exécution du courtier connecté, qui échappe à notre contrôle.
Oui. La fenêtre de volatilité glissante, le pourcentage de tranche maximum et le plafond de déploiement quotidien sont configurables par instrument, dans les limites de sécurité publiées par la plateforme.
Non. Le modèle gère la taille et le calendrier du déploiement des capitaux par rapport à la volatilité mesurée ; il ne prévoit pas l’orientation des prix et n’offre aucune garantie de profit.
Si la couche d'ingestion perd un flux au-delà d'un délai d'attente configuré, les instructions de tranche en attente pour cet instrument sont conservées plutôt que exécutées sur des données incomplètes.
Note de sécurité : toutes les données du compte sont cryptées en transit à l'aide de TLS 1.2 ou supérieur. Les journaux d'accès sont conservés à des fins d'audit et peuvent être consultés sur demande via le tableau de bord de votre compte.
La configuration du compte et la liaison des clés API prennent généralement moins de quinze minutes une fois la documentation examinée.