Sur un compte netting, deux robots et des interventions manuelles peuvent modifier une seule position par symbole. Son résultat ne constitue pas automatiquement le résultat de chaque EA. Il faut reconstituer les exécutions, puis déclarer une convention d’attribution. Deux conventions peuvent produire des résultats différents pour A et B tout en retrouvant le même total du compte. Cette analyse ne remplace ni le relevé de l’intermédiaire ni une règle fiscale.

Pourquoi le magic number ne sépare-t-il pas la position ?

Une position netting représente l’effet courant des transactions d’un symbole. Un ordre peut produire plusieurs exécutions, ou deals. Nommer deux programmes différemment ne crée pas deux portefeuilles indépendants. DEAL_MAGIC identifie le magic number de l’exécution ; DEAL_REASON renseigne son origine ou sa cause. Ce sont des propriétés différentes. Magic zéro ne suffit pas à prouver une intervention manuelle.

Une vente manuelle peut réduire une position construite par A et B. L’étiquette de la vente ne dit pas quelle ancienne quantité votre analyse considère comme clôturée. Il faut une règle explicite. Conservez une colonne pour l’origine de la demande et une autre pour le propriétaire analytique de la quantité. Sans cette séparation, un rapport peut attribuer un profit à un robot qui n’a pas initié la sortie.

Comment relier ordre, exécution et position ?

Stockez les numéros comme des identifiants, pas comme des quantités. DEAL_ORDER relie l’exécution à l’ordre, DEAL_POSITION_ID au cycle de position. POSITION_IDENTIFIER permet le rapprochement historique ; POSITION_TICKET peut changer après des opérations de service du serveur. HistorySelectByPosition sélectionne ordres et exécutions par identifiant de position : contrôlez la réussite et l’étendue de l’export.

Pour chaque exécution, relevez symbole, sens, quantité effectivement exécutée, prix, horodatage et coûts dans leur devise. Ne remplacez pas une quantité partiellement exécutée par celle demandée. Séparez opérations de solde et transactions de marché. Une fermeture visible sans entrée correspondante reste non résolue ; un commentaire ne justifie pas d’inventer son prix d’ouverture.

Comment deux méthodes donnent-elles deux résultats par EA ?

Deux achats, puis deux sorties manuelles

Modèle source fictif USD : EUR/USD vaut 100 000 EUR par lot. Aucun volume initial. Quatre exécutions intégrales et ordonnées coûtent chacune 1 USD ; financement et autres frais sont nuls. Les prix sont ceux d’exécution, achat à l’Ask supposé et vente au Bid : le spread est déjà incorporé. Le cycle porte POSITION_IDENTIFIER 5001.

  • Deal 7001, ordre 5001 : EA A achète 0,10 à 1,1000 ; position acheteuse 0,10.
  • Deal 7002, ordre 5002 : EA B achète 0,10 à 1,1020 ; total 0,20.
  • Deal 7003, ordre 5003 : sortie manuelle de 0,10 à 1,1010 ; reste 0,10.
  • Deal 7004, ordre 5004 : sortie manuelle de 0,10 à 1,1030 ; aucune position.

Le prix moyen partagé est 1,1010. La première réduction réalise zéro de prix et la seconde 20 USD. Le cycle clos donne 20 − 4 = 16 USD nets. Il s’agit de données fournies pour le modèle, pas d’un résultat observé en compte réel.

En FIFO analytique, la sortie 7003 est attribuée à A : 10 000 × (1,1010 − 1,1000) = 10 USD. La sortie 7004 va à B : 10 000 × (1,1030 − 1,1020) = 10 USD. Chaque robot reçoit ses deux commissions, donc A +8 USD et B +8 USD. En LIFO analytique, B reçoit −10 USD de prix, soit −12 nets ; A reçoit +30 USD de prix, soit +28 nets. Les deux sommes donnent 16 USD.

Même total, attributions différentes

Le total ne choisit pas la convention

Le total ne choisit pas la conventionFIFO et LIFO sont des conventions de notre analyse, pas deux modes comptables alternatifs du serveur ni des règles fiscales universelles.Le total ne choisit pas la conventionCompte : 20 USD de prix − 4 USD de frais = 16 USDFIFO analytique : A +8 ; B +8 → 16 USDLIFO analytique : A +28 ; B −12 → 16 USD
FIFO et LIFO sont des conventions de notre analyse, pas deux modes comptables alternatifs du serveur ni des règles fiscales universelles.

Faites défiler horizontalement ou agrandissez le schéma pour lire les détails.

Pourquoi le réalisé diffère-t-il après la première sortie ?

Après 7003, prenons le Bid de 1,1010. La position partagée a zéro réalisé et zéro latent de prix. FIFO affiche +10 USD réalisés pour A, mais B conserve −10 USD latents. Le total de prix reste zéro ; avec trois commissions, le résultat combiné est −3 USD. Comparer seulement le réalisé du tableur au réalisé serveur oublierait une moitié du rapprochement. Après 7004, tout est clos et l’attribution complète vaut 16 USD.

Ajout distinct en EUR : une méthode attribue +35 EUR réalisés à A et laisse −20 EUR latents à B, avec 5 EUR de frais communs imputés une seule fois. Le périmètre vaut +10 EUR, pas +30 EUR. Si une autre méthode répartit autrement les 15 EUR de résultat de prix, son total après frais doit toujours être 10 EUR au même instant. La devise EUR du compte ne choisit pas la méthode et ne transforme pas celle-ci en règle fiscale française.

Les historiques réels peuvent inclure inversions, corrections, exécutions partielles et frais postés séparément. Marquez toute lacune. Changer silencieusement de convention quand un robot paraît perdant rend la comparaison trompeuse, même si le total reste juste. Les limites de compte et de robots s’appliquent toujours à l’exposition partagée réelle.

Que préparer avant d’évaluer deux robots ?

  • Choisir un cycle clos d’un symbole et préserver l’export original.
  • Relier ordres, deals et identifiant, puis rapprocher volumes et coûts.
  • Déclarer la convention de quantité et de frais avant de calculer A et B.
  • Pour un cycle ouvert, comparer réalisé plus latent au même prix et conserver les incertitudes.

Résultat latent et réalisé : rapprocher les fonds sans compter deux fois permet de pratiquer ce dernier contrôle avant de juger un programme.