Bot d’arbitrage sur les marchés événementiels : gérer les opérations incomplètes

La réponse aux incidents d’un bot d’arbitrage sur les marchés événementiels commence par leur classification

Classez l’incident en fonction des faits connus, et non du message le plus facile à afficher. Un rejet avéré signifie que les données faisant autorité établissent que la requête en question n’a créé ni l’ordre ni l’exécution prévus. Une exécution partielle signifie qu’une certaine quantité est confirmée, tandis qu’une autre partie reste non exécutée ou indéterminée. Une soumission incertaine signifie que le système local ne dispose pas d’éléments suffisants pour déterminer ce que la plateforme a accepté.

Ajoutez une catégorie distincte pour les hypothèses invalidées. Une comparaison de règles peut se révéler erronée, une clarification contractuelle peut nécessiter un examen ou une hypothèse de financement peut ne plus tenir. Dans ces situations, répéter le plan d’exécution initial peut être inapproprié, même si l’interface de trading fonctionne correctement. Le système doit réexaminer la recommandation et l’autorisation, et non simplement corriger une erreur de transport.

Le dossier d’incident doit identifier le cas concerné, les identifiants des volets, le dernier état rapproché et l’incertitude actuelle. Il doit également consigner les nouvelles activités qui ont été désactivées. Un problème sur un compte peut nécessiter d’y suspendre toutes les instructions susceptibles d’accroître l’exposition, tandis qu’un problème circonscrit d’interprétation contractuelle peut ne concerner que les cas utilisant cette correspondance. Le périmètre doit être défini en fonction des éléments manquants et des dépendances communes.

L’article antérieur sur le bot d’arbitrage entre Kalshi et Polymarket apporte des éléments de contexte sur la coordination entre plateformes. En pratique, la désignation de l’incident doit aider à déterminer la prochaine étape de collecte d’éléments probants. Si elle ne distingue pas ce qui est confirmé de ce qui reste possible, elle est trop vague pour permettre la reprise.

Contenir le cas sans en effacer l’historique

Contenir l’incident signifie arrêter les nouvelles actions qui pourraient accroître l’exposition non résolue. Cela n’implique pas nécessairement de soumettre immédiatement une opération inverse. Commencez par désactiver les nouvelles autorisations d’opérations candidates dans le périmètre concerné et examinez les engagements existants. Conservez la recommandation initiale, les limites de prix et les autorisations. Ces données expliquent ce que le bot cherchait à faire et quelles hypothèses ne justifient plus son action suivante.

Les ordres en cours nécessitent une réponse réfléchie, adaptée au fonctionnement réel de la plateforme. Une demande d’annulation peut être appropriée, mais elle reste une demande tant que son résultat n’est pas établi. Maintenez la quantité qui pourrait encore être exécutée dans le modèle d’exposition. Ne libérez pas une réservation au seul motif que la stratégie locale ne juge plus l’ordre utile.

Consignez la chronologie de l’incident à partir d’observations faisant autorité, dans la mesure du possible. Incluez les heures de soumission, les réponses, les exécutions, les demandes d’annulation et les instantanés du compte. Lorsque les mises à jour arrivent en retard, utilisez les heures de réception en plus des heures indiquées par la source. La chronologie doit rendre l’incertitude visible, au lieu d’organiser les événements dans un ordre artificiellement net fondé uniquement sur le moment où le programme local les a traités.

Le confinement de l’incident doit aussi empêcher le nettoyage automatique de détruire les éléments nécessaires au diagnostic. Un processus de traitement redémarré ne doit pas remplacer les identifiants des cas non résolus par de nouveaux identifiants, ni marquer d’anciennes tâches comme terminées parce qu’elles dépassent une limite de temps. L’historique est nécessaire pour déterminer si une exécution ultérieure appartient à la tentative initiale et si une action de reprise proposée ferait double emploi avec une instruction déjà acceptée.

Un rejet avéré peut laisser un autre volet actif

Dans le premier cas fictif, le bot prévoit deux ordres de 300 unités. La première requête est rejetée et la seconde n’a pas encore été soumise. Si les données faisant autorité confirment l’absence totale d’exécution et d’ordre actif, le cas peut libérer sa réservation inutilisée et s’arrêter. L’occasion initiale doit néanmoins être réévaluée avant toute nouvelle tentative, car les prix, les frais ou les conditions du compte peuvent avoir changé.

Modifions maintenant la séquence : la première requête est rejetée alors que le second ordre a déjà été accepté. Le cas n’est pas vide. Le second volet accepté peut être en attente dans le carnet ou exécuté, et son statut doit être déterminé. Un rejet d’un côté n’annule pas automatiquement l’autre côté, sauf si un mécanisme vérifié de la plateforme prévoit explicitement ce comportement pour la transaction concernée ; il ne faut jamais le supposer entre des services distincts.

Interprétez le motif du rejet dans le contexte de l’interface actuelle. Un problème de taille minimale, un pas de prix invalide, un problème d’autorisation du compte et un mode de négociation restreint appellent des réponses différentes. Certains ne peuvent être corrigés qu’en modifiant l’instruction ; d’autres nécessitent de rétablir les conditions du compte ou d’attendre que la plateforme autorise l’activité prévue. Répéter aveuglément le même ordre invalide ne constitue pas une reprise.

La documentation du moteur d’appariement de Polymarket distingue les modes de redémarrage et de négociation restreinte. Cet exemple montre utilement pourquoi un service en ligne peut malgré tout rejeter une action particulière. Le bot doit examiner le mode réel et les comportements pris en charge, au lieu de considérer toute connexion réussie comme une autorisation de reprendre l’appariement ordinaire.

Une exécution partielle exige un nouvel état de l’exposition

Dans le deuxième cas fictif, le bot prévoit 200 unités Oui de A et 200 unités Non de B compatibles. A est entièrement exécuté à 0,48 $, pour un coût de 96 $. B n’est exécuté qu’à hauteur de 150 unités à 0,49 $, pour un coût de 73,50 $. Le compte a dépensé 169,50 $ avant frais. Il détient 150 paires complètes avec un rapport de un pour un et 50 unités A non appariées. Cet état de l’exposition remplace l’hypothèse initiale de 200 paires complètes.

La partie appariée coûte 145,50 $ avant frais et présente un versement modélisé de 150 $ selon les hypothèses ordinaires de l’exemple. Les 50 unités A non appariées coûtent 24 $ et peuvent rapporter 50 $ ou zéro. Leur exposition au résultat est bien supérieure au faible écart attendu de la combinaison complète. Indiquer uniquement le prix d’entrée combiné moyen masquerait la quantité incomplète qui importe désormais le plus.

Avant de choisir une réponse, déterminez si le reliquat de l’ordre B peut encore être exécuté. S’il est ouvert ou si son annulation reste incertaine, une nouvelle exécution de B peut réduire la quantité non appariée. Une action de reprise fondée sur le déficit antérieur de 50 unités pourrait alors entraîner une correction excessive. La procédure de gestion de l’incident nécessite un état suffisamment rapproché ou des règles qui tiennent explicitement compte de l’incertitude restante.

Le guide du bot d’arbitrage sur contrats événementiels porte sur les réservations appariées et les états d’exécution. La gestion des incidents ajoute une exigence pour l’opérateur : indiquer ce que le compte détient actuellement, ce qui peut encore changer et quelles décisions sont autorisées. Un écran de reprise doit rendre ces faits compréhensibles sans demander à l’opérateur de les déduire de plusieurs messages d’ordres sans lien entre eux.

Comparer les coûts des différentes options de reprise du bot d’arbitrage sur les marchés événementiels

Supposons que les 50 unités B restantes puissent maintenant être achetées à 0,58 $. Les acheter pour compléter la position coûte 29 $ supplémentaires, ce qui porte le coût d’achat à 198,50 $. Si l’on suppose que les frais totaux de cette option de complément s’élèvent à 4 $, le coût tout compris est de 202,50 $ pour un versement modélisé de 200 $. La reprise produirait une perte de 2,50 $ selon les hypothèses indiquées. Atteindre la cible initiale ne revient donc pas à préserver l’équilibre économique initial.

Envisageons une autre réponse autorisée, après confirmation que le reliquat de B n’est plus ouvert. Vendre les 50 unités A non appariées à un prix acheteur exécutable de 0,45 $ rapporte 22,50 $. Les 150 paires complètes restantes rapportent 150 $ selon le modèle. Les recettes totales sont de 172,50 $ pour un montant d’achat de 169,50 $, ce qui laisse 3 $ avant frais. Si les frais totaux de cette autre option de reprise s’élèvent à 4 $, le résultat est une perte de 1 $.

Ces chiffres représentent des options hypothétiques, et non des cotations de plateforme ou des estimations de frais. Ils montrent pourquoi la décision de reprise doit comparer les options dans leur intégralité. La seconde option présente la perte modélisée la plus faible dans cet exemple, mais les quantités réellement disponibles, les restrictions du compte et les ordres non résolus pourraient modifier la comparaison. Le bot doit choisir uniquement parmi les actions autorisées par ses règles de reprise actuelles.

Ces règles peuvent également permettre de conserver une position résiduelle encadrée en vue d’un examen humain. Dans ce cas, documentez l’exposition maximale, le responsable et l’heure de la prochaine décision. Laisser une position non appariée sans décision explicite quant à son traitement ne constitue pas une reprise achevée. L’incident peut être stabilisé sur le plan opérationnel alors qu’un risque financier subsiste, mais le dossier doit l’indiquer clairement.

Une soumission incertaine pose d’abord un problème de preuve

Dans le troisième cas fictif, une requête portant sur 100 unités expire avant que le bot ne reçoive de réponse. Le compte peut ne comporter aucun ordre, comporter un ordre en attente dans le carnet, une exécution partielle ou une exécution complète. L’expiration du délai local ne permet pas de distinguer ces états. Conservez l’identité de la tentative initiale et sa réservation pendant l’examen des données d’ordres, de transactions et de positions accessibles par les mécanismes pris en charge.

Évitez de déduire une absence d’exécution d’une seule notification manquante. Un flux privé peut avoir perdu une mise à jour alors qu’une requête sur le compte révélerait l’exécution. Inversement, un affichage transitoire ne suffit pas forcément à établir l’état final du compte. Utilisez les sources de vérité documentées de la plateforme et conservez les observations qui étayent la conclusion. Si les éléments restent contradictoires, le cas demeure incertain, même si l’opérateur préférerait un statut sans ambiguïté.

Une seconde requête dotée d’une nouvelle identité constitue un nouvel engagement potentiel, sauf si l’interface réelle fournit un mécanisme idempotent vérifié applicable à cette requête. Ne supposez pas qu’un sens et une quantité identiques en font une nouvelle tentative sans conséquence. Le premier ordre pourrait apparaître ultérieurement et amener le compte à détenir le double de la quantité prévue. La reprise doit résoudre l’ancienne tentative avant d’en autoriser une autre, indépendante.

Le guide antérieur du bot pour marchés de prédiction offre une vue plus large des responsabilités en matière d’observation et de gestion du compte. Lors d’un incident, la question centrale est précise : quels éléments prouvent si cette tentative particulière a modifié le compte ? La réponse détermine s’il faut libérer de la capacité, annuler un ordre actif ou intégrer les exécutions dans l’état actuel de l’exposition.

Un redémarrage doit reconstruire l’état à partir des engagements persistants

Un processus peut redémarrer pendant n’importe lequel de ces cas. Le nouveau processus doit charger les tentatives non résolues, les réservations et les responsables des cas avant d’accepter de nouvelles recommandations. Un état mémoire vierge n’implique pas que la plateforme n’a aucun ordre. Les comptes continuent d’exister pendant l’arrêt du programme local, et leurs positions peuvent avoir changé durant l’interruption.

Rapprochez les ordres ouverts et les exécutions récentes en utilisant la période et les identifiants requis. Dédupliquez les données déjà traitées avant le redémarrage. Si le journal local s’arrête avant une requête soumise, utilisez l’enregistrement persistant de la tentative et les éléments du compte pour examiner cette lacune. Le système ne doit pas supposer qu’une écriture locale incomplète signifie que l’action externe n’a jamais eu lieu.

Ne rétablissez les autorisations de trading qu’une fois les conditions de redémarrage remplies pour les comptes et les correspondances entre contrats concernés. Un service peut accepter les demandes d’annulation avant d’accepter le type de nouvel ordre dont la stratégie a besoin. Un flux public peut être à jour alors que les données privées restent retardées. La procédure de gestion de l’incident doit rétablir des capacités précises à partir d’éléments probants, au lieu de faire passer tout le système du rouge au vert d’un seul coup.

L’architecture du bot pour contrats événementiels décrit les périmètres d’état sous-jacents. Le protocole de reprise transforme ces périmètres en une séquence pratique pour l’opérateur : identifier les engagements non résolus, établir les quantités, confirmer les autorisations, puis envisager de nouvelles actions. Passer directement à la dernière étape peut reproduire l’incident avec une exposition accrue du compte.

Réexaminer l’hypothèse contractuelle lorsque le problème est sémantique

Tout incident ne commence pas par une erreur technique. Une personne chargée de l’examen peut découvrir qu’un contrat utilise une publication initiale tandis que l’autre utilise une révision, ou que les résultats exceptionnels diffèrent. Dans ce cas, les deux positions n’ont peut-être jamais présenté la relation entre versements supposée par le bot. Un historique d’exécution parfait ne corrige pas l’erreur sémantique.

Désactivez les nouveaux cas utilisant la correspondance concernée et identifiez les expositions existantes qui en dépendent. Recalculez leurs versements selon l’interprétation corrigée. Le résultat peut inclure des états dans lesquels les deux positions perdent ou gagnent toutes les deux. Il s’agit d’expositions directionnelles ou au risque de base, qui nécessitent leur propre décision de risque. Ne continuez pas à les qualifier d’arbitrage complet au seul motif que les quantités correspondent.

Conservez l’ancienne correspondance et la raison de son remplacement. Cela permet de déterminer, lors de l’examen, si l’erreur provenait d’une extraction incomplète des règles, d’une déduction non étayée ou d’une clarification ultérieure. Cela aide aussi à identifier les cas historiques évalués selon la même hypothèse. Corriger uniquement le cas actuel peut laisser la même relation erronée active ailleurs dans le système.

Le guide de l’automatisation des contrats événementiels explique comment soumettre les questions de règles inhabituelles à un examen dont la responsabilité est clairement attribuée. La gestion des incidents doit utiliser cette procédure au lieu de demander à un résumé automatisé d’inventer une interprétation définitive. Le bot peut recueillir des éléments et quantifier les résultats possibles pendant qu’une personne qualifiée résout la question contractuelle dans le cadre des règles de la plateforme concernée.

La clôture d’un incident du bot d’arbitrage sur les marchés événementiels exige des preuves

Clore un incident exige davantage qu’une réponse positive à un ordre de reprise. Confirmez les quantités finales exécutées, l’état des ordres ouverts, les frais et les positions restantes. Comparez le compte au traitement documenté : entièrement apparié, réduit, entièrement liquidé ou délibérément transféré à un autre responsable du risque. Chaque engagement restant doit avoir sa place dans le modèle du compte.

Pour l’option de réduction de l’exemple d’exécution partielle, la clôture doit indiquer 200 A achetés, 150 B achetés, 50 A vendus et aucun reliquat d’ordre non résolu. Le compte conserve 150 A et 150 B, l’hypothèse de compatibilité des versements restant valide. Les recettes de réduction de 22,50 $ et les frais réels doivent figurer dans le registre du cas. Si le versement final est encore en attente, distinguez la clôture de l’exécution de l’achèvement du règlement.

Un cas transféré à une stratégie directionnelle nécessite une transmission consignée. Indiquez la quantité, l’historique d’acquisition, l’interprétation actuelle des règles, la capacité de perte autorisée et le responsable désigné. La stratégie destinataire doit reconnaître la position dans ses propres registres. Sans cela, la file des incidents peut sembler vide alors que le portefeuille contient une exposition orpheline qu’aucun processus ne surveille.

L’article antérieur sur le bot d’arbitrage automatisé sur Polymarket apporte des éléments de contexte sur les processus achevés et incomplets. L’exigence opérationnelle est qu’une autre personne chargée de l’examen puisse reconstituer pourquoi l’incident a été clos et ce qui reste à surveiller. Un statut sans données justificatives est une affirmation, pas une preuve d’achèvement.

Une transmission à un humain exige une demande encadrée

Lorsque la reprise automatique ne peut pas se poursuivre, l’opérateur doit recevoir un dossier de décision concret. Incluez les positions confirmées, les ordres non résolus, les éléments déjà vérifiés et les options qui restent dans les limites actuelles. Précisez si la demande concerne l’interprétation du contrat, une capacité de perte supplémentaire ou l’autorisation d’une action de reprise précise. Une demande générale visant à corriger l’opération peut conduire différentes personnes à s’attribuer des pouvoirs différents.

La personne destinataire doit savoir quelles actions le bot a arrêtées et quelle surveillance se poursuit. Si l’annulation reste incertaine, indiquez-le de manière bien visible. Si une vente recommandée suppose qu’aucune unité complémentaire supplémentaire ne peut être exécutée, explicitez cette hypothèse. La décision de l’opérateur doit produire une nouvelle autorisation encadrée que le composant d’exécution peut suivre, plutôt qu’un message informel qui lève toutes les limites existantes.

Consignez l’heure de la transmission et le responsable désigné. Si une autre équipe prend le relais avant le règlement, conservez l’engagement restant et la condition du prochain examen. Cela évite qu’un cas ne soit délaissé entre la recherche, l’ingénierie et les opérations sur comptes simplement parce que chaque groupe croit qu’un autre l’a pris en charge. La responsabilité reste visible jusqu’à ce que l’exposition soit résolue ou délibérément attribuée à une stratégie en cours.

Examiner les incidents sans effacer les tentatives infructueuses

Incluez les pertes issues de la reprise, les opérations candidates rejetées et les cas non résolus dans l’évaluation du bot. Un rapport de performance qui ne comprend que les réussites entièrement appariées sélectionne le scénario d’exécution favorable et omet les coûts d’exploitation de la stratégie. Le jeu de données des incidents doit montrer la fréquence de chaque type de défaillance, l’exposition qu’il crée et le temps nécessaire pour établir un état fiable du compte.

Regroupez les incidents par cause plutôt que selon leur seul bénéfice final. Une expiration de délai peut se terminer avec un bénéfice par chance tout en révélant une pratique dangereuse de soumission en double. Une petite perte peut résulter d’une reprise correctement encadrée qui a évité une position non appariée plus importante. L’examen doit évaluer si les contrôles ont fonctionné comme prévu et si les hypothèses de la stratégie restent étayées, en plus du résultat financier.

Utilisez les incidents pour améliorer des contrôles précis. Des rejets répétés liés à la taille suggèrent une lacune de validation. Des tentatives répétées au statut inconnu peuvent nécessiter de meilleurs identifiants persistants ou une meilleure gestion des requêtes sur le compte. Des paires souvent incomplètes peuvent justifier une taille initiale plus faible ou une autre séquence d’exécution. Les incidents sémantiques nécessitent un meilleur examen des règles. Une instruction générale de réessayer plus vite a peu de chances de traiter toutes ces causes et peut en aggraver certaines.

La qualité de reprise du bot se démontre par des états d’exposition clairs, des actions encadrées et une clôture fondée sur des données rapprochées. Une paire prévue peut échouer sans devenir un problème de compte incontrôlé si le système conserve ce qui est connu et refuse d’inventer ce qui ne l’est pas. Cette discipline rend l’ensemble du processus de trading vérifiable, y compris les cas dans lesquels la marge initialement projetée ne s’est jamais concrétisée.