Comprendre les codes de condition des transactions
Trois plateformes, trois plus-hauts quotidiens pour la même action. Les codes déterminent quels prints mettent à jour le plus-haut, le plus-bas, la clôture et le volume.
Les codes de condition de transaction expliquent pourquoi trois plateformes peuvent afficher trois plus-hauts quotidiens différents pour la même action, sans qu’aucune ne soit erronée. Chaque print du consolidated tape porte ces tags. Ils déterminent si un print peut mettre à jour le dernier cours, le plus-haut et le plus-bas du jour, l’ouverture officielle, la clôture officielle et le volume consolidé total. Une transaction peut être une exécution réelle à un prix réel tout en étant exclue de la quasi-totalité de ces champs.
Que sont les codes de condition de transaction ?
Un code de condition de transaction, également appelé sale condition, est un tag que la place de marché déclarante associe à un trade report avant sa diffusion sur le tape. Le prix et la taille indiquent ce qui a été négocié. La condition précise la nature du report : s’il est arrivé à temps, si son prix a été calculé à partir d’autres exécutions plutôt que convenu à cet instant, si la transaction a eu lieu en dehors des horaires habituels, ou si elle portait sur moins de 100 actions, soit un round lot.
Chaque code est associé à un ensemble de flags d’éligibilité. C’est la partie que presque personne ne voit. Chaque code est déclaré éligible ou non éligible pour le dernier cours, le plus-haut et le plus-bas, l’ouverture, la clôture et le volume consolidé. Ces flags évoluent indépendamment les uns des autres. De nombreux prints qui ne peuvent pas modifier le plus-haut ou le plus-bas sont néanmoins comptabilisés dans le volume. C’est pourquoi le nombre d’actions publié et les extrêmes de cours publiés d’une action sont calculés à partir d’ensembles de transactions qui se recoupent sans être identiques. Un second ensemble de flags fonctionne en parallèle : l’un régit le consolidated tape, l’autre la place de marché individuelle. En effet, la clôture officielle d’une Bourse est calculée uniquement à partir de ses propres prints.
Les codes de condition sont regroupés par familles. Une seule famille détermine ce qu’une transaction peut mettre à jour.
Le SQL exact derrière chaque chiffre
SELECT
replaceAll(type, '_', ' ') AS condition_family,
countDistinct(id) AS codes
FROM global_markets.stocks_condition_codes
WHERE asset_class = 'stocks'
GROUP BY condition_family
ORDER BY codes DESCLe dictionnaire des actions comprend 8 familles. La plus importante est la famille sale condition, avec 40 codes distincts. Les quote conditions décrivent le bid et l’offre, et non une transaction. Les familles d’indicateurs signalent des situations telles que l’application d’une short sale restriction. La famille sale condition est celle qui porte les flags d’éligibilité. C’est d’elle que proviennent tous les chiffres présentés ci-dessous.
Ce qui figure réellement sur le tape
Le panneau ci-dessous porte sur une session déterminée de juin 2026. Il regroupe chaque print sur AAPL, de l’ouverture du premarket à 4 h 00 jusqu’à la fin du post-market à 20 h 00, selon la sale condition associée à chaque print. La période est fixée dans le SQL. Ces chiffres décrivent donc cette journée, et aucune autre. Un print peut porter plusieurs codes à la fois, tandis que beaucoup n’en portent aucun. Les colonnes n’atteignent donc pas 100 % au total.
Le SQL exact derrière chaque chiffre
WITH
(SELECT count()
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 08:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 00:00:00', 'UTC')) AS day_prints,
(SELECT sum(size)
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 08:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 00:00:00', 'UTC')) AS day_shares
SELECT
multiIf(t.code = -1, 'Regular way (no code)',
c.code_name = '', concat('Unmapped code ', toString(t.code)),
c.code_name) AS condition_name,
round(100 * count() / day_prints, 2) AS pct_of_prints,
round(100 * sum(t.size) / day_shares, 2) AS pct_of_shares
FROM
(
SELECT
size,
arrayJoin(if(empty(conditions),
[toInt32(-1)],
arrayMap(x -> toInt32(x), conditions))) AS code
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 08:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 00:00:00', 'UTC')
) AS t
LEFT JOIN
(
SELECT toInt32(id) AS code_id, any(name) AS code_name
FROM global_markets.stocks_condition_codes
WHERE asset_class = 'stocks'
AND type = 'sale_condition'
GROUP BY code_id
) AS c ON c.code_id = t.code
GROUP BY condition_name
ORDER BY pct_of_prints DESC
LIMIT 12Le tag le plus fréquent ce jour-là était Odd Lot Trade. Il apparaissait sur 65.83% des prints de la session et représentait 6.37% des actions négociées. Comparez les deux colonnes ligne par ligne. Lorsque la part des prints dépasse largement la part du volume, le code signale de petites exécutions. Lorsque c’est l’inverse, il signale un petit nombre d’exécutions très importantes. Le nombre de prints et le nombre d’actions répondent à deux questions différentes. Le code de condition permet de les distinguer.
Pourquoi deux plateformes affichent-elles des plus-hauts quotidiens différents ?
Quatre types de prints sont chacun exclus d’un sous-ensemble différent de champs.
- Transactions déclarées en retard et hors séquence. Une transaction conclue à 10 h 14 et déclarée à 10 h 31 arrive sur le tape avec le tag out of sequence, ou avec un prix fondé sur une référence antérieure. Elle est comptabilisée dans le volume. Elle ne peut pas fixer le dernier cours ni relever le plus-haut du jour, même si son prix est supérieur à celui de toutes les autres transactions de la session. Les block trades négociés de gré à gré et les prints transmis par une trade reporting facility depuis des plateformes de dark pool trading entrent souvent dans cette catégorie.
- Transactions à prix dérivé. Une transaction au prix moyen ou un remplissage VWAP porte un prix calculé à partir de nombreuses autres exécutions, plutôt qu’un prix convenu à cet instant. Elle est exclue du dernier cours et des extrêmes, car le prix affiché n’a jamais existé comme quote en temps réel.
- Odd lot. Moins de 100 actions. Les odd lots ne sont pas éligibles pour le dernier cours ni pour le plus-haut et le plus-bas, mais sont intégralement comptabilisés dans le volume consolidé. Ils n’ont pas été déclarés sur le consolidated tape avant la fin de 2013. Toute comparaison de volume remontant au-delà de cette date compare donc deux définitions différentes du terme. Notre guide sur le volume quotidien moyen détaille ce point.
- Horaires étendus et form T. Les prints du premarket et du post-close portent un tag et sont exclus de l’ouverture, du plus-haut, du plus-bas et de la clôture de la session régulière. Ils restent toutefois comptabilisés dans le volume consolidé. Une plateforme qui les intègre dans ses graphiques affiche une amplitude quotidienne différente de celle qui les exclut. C’est ce qui explique que le trading after-hours et premarket apparaisse sur un graphique et pas sur un autre.
Voici la part de chaque catégorie dans une session pour cinq grandes valeurs, sur la même journée déterminée.
Le SQL exact derrière chaque chiffre
WITH
(SELECT groupArray(toInt32(id))
FROM global_markets.stocks_condition_codes
WHERE asset_class = 'stocks'
AND type = 'sale_condition'
AND name ILIKE '%odd lot%') AS odd_lot_codes,
(SELECT groupArray(toInt32(id))
FROM global_markets.stocks_condition_codes
WHERE asset_class = 'stocks'
AND type = 'sale_condition'
AND multiSearchAnyCaseInsensitive(name,
['form t', 'extended trading hours'])) AS extended_codes,
(SELECT groupArray(toInt32(id))
FROM global_markets.stocks_condition_codes
WHERE asset_class = 'stocks'
AND type = 'sale_condition'
AND multiSearchAnyCaseInsensitive(name,
['out of sequence', 'prior reference', 'derivatively priced',
'average price', 'price variation', 'seller'])
AND NOT multiSearchAnyCaseInsensitive(name,
['form t', 'extended trading hours'])) AS late_or_derived_codes
SELECT
ticker,
round(100 * countIf(hasAny(conditions, odd_lot_codes)) / count(), 2) AS odd_lot_pct,
round(100 * countIf(hasAny(conditions, late_or_derived_codes)) / count(), 2) AS late_or_derived_pct,
round(100 * countIf(hasAny(conditions, extended_codes)) / count(), 2) AS extended_hours_pct
FROM global_markets.stocks_trades
WHERE ticker IN ('AAPL', 'KO', 'MSFT', 'NVDA', 'SPY')
AND sip_timestamp >= toDateTime('2026-06-17 08:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 00:00:00', 'UTC')
GROUP BY ticker
ORDER BY odd_lot_pct DESCLes odd lot prints représentaient de 46.8% à 85.14% de l’ensemble des prints pour les cinq valeurs. Cette colonne suit étroitement le cours de l’action : à montant investi égal, un ordre permet d’acheter moins d’actions lorsque le cours est plus élevé. NVDA arrivait en tête, avec 2.4% de ses prints identifiés comme déclarés en retard ou à prix dérivé et 3.53% identifiés comme relevant des horaires étendus. Chaque print de ces trois catégories correspond à une transaction réelle à un prix réel. Aucun ne peut toutefois fixer le plus-haut ou le plus-bas.
Un print qui ne relève pas le plus-haut
Le panneau suivant reprend la même session AAPL déterminée. Il découpe la période régulière, de 9 h 30 à 16 h 00, en tranches de quinze minutes et trace deux plus-hauts pour chaque tranche. Une ligne retient le prix le plus élevé de tous les prints. L’autre retient le prix le plus élevé parmi les prints dont les conditions les rendent éligibles pour fixer le plus-haut.
Le SQL exact derrière chaque chiffre
WITH
(SELECT groupArray(toInt32(id))
FROM global_markets.stocks_condition_codes
WHERE asset_class = 'stocks'
AND type = 'sale_condition'
AND multiSearchAnyCaseInsensitive(name,
['odd lot', 'form t', 'extended trading hours', 'out of sequence',
'prior reference', 'derivatively priced', 'average price',
'price variation', 'seller'])) AS not_high_low_codes
SELECT
formatDateTime(toStartOfFifteenMinutes(toTimeZone(sip_timestamp, 'America/New_York')), '%H:%i') AS et_time,
round(toFloat64(max(price)), 2) AS tape_high,
round(toFloat64(maxIf(price, NOT hasAny(conditions, not_high_low_codes))), 2) AS eligible_high
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
AND sip_timestamp >= toDateTime('2026-06-17 08:00:00', 'UTC')
AND sip_timestamp < toDateTime('2026-06-18 00:00:00', 'UTC')
AND (toHour(toTimeZone(sip_timestamp, 'America/New_York')) * 60
+ toMinute(toTimeZone(sip_timestamp, 'America/New_York'))) >= 570
AND (toHour(toTimeZone(sip_timestamp, 'America/New_York')) * 60
+ toMinute(toTimeZone(sip_timestamp, 'America/New_York'))) < 960
GROUP BY et_time
HAVING countIf(NOT hasAny(conditions, not_high_low_codes)) > 0
ORDER BY et_timeLa session ouvre à 09:30. Le plus-haut du tape atteint $302.07, contre un plus-haut éligible de $302.07, et la session compte 26 tranches jusqu’à la clôture. La ligne du plus-haut éligible ne peut jamais dépasser celle du tape, car les prints éligibles constituent un sous-ensemble de l’ensemble des prints. Lorsque les deux lignes se confondent, tous les prints de ce quart d’heure pouvaient fixer le plus-haut. Lorsque la ligne supérieure s’écarte, au moins un print de la période s’est négocié au-dessus du prix éligible le plus élevé. Aucun graphique appliquant les règles d’éligibilité ne l’affichera.
Cet écart constitue la réponse exacte à la divergence. Une source qui retient le prix maximal de chaque print publie un plus-haut. Une source qui applique les flags d’éligibilité en publie un autre. Une source qui exclut également le premarket et le post-close en publie un troisième. Toutes lisent le même tape.
Quelle est la fiabilité de la couche d’éligibilité ?
Elle est limitée. Les flags sont des données de référence, et ces données peuvent être corrigées. Un fournisseur commercial de market data a corrigé son propre dictionnaire des conditions de transaction. Il a reclassé l’éligibilité d’une sale condition pour fixer l’ouverture et la clôture officielles. Aucune transaction n’a changé. Le tape de chaque journée concernée était identique avant et après la correction. Un seul flag a changé dans une table de correspondance. Avec lui ont changé l’ouverture et la clôture officielles affichées par tous les graphiques et backtests utilisant cette table en aval.
Considérez donc le OHLC d’un fournisseur comme une lecture du tape, et non comme une vérité absolue. Lorsque deux sources divergent, demandez quelles règles d’éligibilité chacune a appliquées. Les flux de quotes retardés et consolidés ajoutent une seconde version du même problème. Celle-ci concerne le timing plutôt que l’éligibilité.
Où trouver la liste de référence des codes de condition de transaction
Les tapes fonctionnent dans le cadre de deux plans du national market system : le CTA Plan pour les titres cotés au NYSE et le UTP Plan pour les titres cotés au Nasdaq. Chacun publie la spécification des sale conditions applicable au tape qu’il administre. Ces spécifications font autorité. Tout ce qui est construit en aval, y compris les identifiants utilisés dans les panneaux ci-dessus, correspond au mapping qu’un fournisseur fait de ces spécifications dans sa propre nomenclature. L’identifiant d’un code chez un fournisseur ne désigne donc pas nécessairement la même chose chez un autre. Apprenez les catégories plutôt que les numéros. Les catégories sont stables depuis des années. Les numéros figurent dans une table de correspondance, et ces tables sont modifiées.
Notes sur les données
Les catégories des panneaux ci-dessus sont construites à partir du dictionnaire lui-même, et non d’identifiants codés en dur. Chaque catégorie repose sur une correspondance de nom au sein de la famille sale condition : odd lot, form T et horaires de trading étendus, out of sequence, prior reference price, derivatively priced, average price, price variation et seller. Ouvrez le SQL sous chaque panneau pour consulter les patterns exacts. Les codes ne s’excluent pas mutuellement. Un même print peut en porter plusieurs. Les pourcentages des catégories se chevauchent donc et leur total n’atteint pas celui de la session. Les deux panneaux AAPL et le panneau consacré aux cinq valeurs couvrent une seule session déterminée de juin 2026, fixée dans le SQL. Rien sur cette page ne change à mesure que de nouvelles sessions sont ajoutées.
FAQ
Qu’est-ce qu’un code de condition de transaction ?
Il s’agit d’un tag associé à un trade report sur le consolidated tape. Il décrit la nature du report, par exemple une transaction déclarée en retard, à prix dérivé, un odd lot ou une transaction réalisée en horaires étendus. Chaque code comporte des flags indiquant si la transaction peut mettre à jour le dernier cours, le plus-haut et le plus-bas, l’ouverture, la clôture et le volume consolidé.
Pourquoi deux sites affichent-ils des plus-hauts quotidiens différents pour la même action ?
Chacun applique un ensemble différent de règles d’éligibilité aux mêmes prints. L’un peut retenir le prix le plus élevé de toutes les transactions déclarées. Un autre peut exclure les prints dont les codes de condition les empêchent de fixer le plus-haut. Un troisième peut également exclure le premarket et le post-close. Tous lisent le même tape.
Les transactions en odd lot sont-elles comptabilisées dans le volume ?
Oui. Un odd lot, c’est-à-dire moins de 100 actions, est comptabilisé dans le volume consolidé, tout en restant inéligible pour fixer le dernier cours ou le plus-haut et le plus-bas du jour. Les odd lots n’étaient pas déclarés sur le consolidated tape avant la fin de 2013. Les comparaisons de volume sur longue période franchissent donc une rupture de définition à cette date.
Les transactions after-hours sont-elles prises en compte dans le plus-haut et le plus-bas quotidiens ?
Pas dans le plus-haut et le plus-bas de la session régulière. Les prints du premarket et du post-close portent une condition extended hours ou form T. Celle-ci les exclut de l’ouverture, du plus-haut, du plus-bas et de la clôture de la session régulière, tout en les maintenant dans le volume consolidé du jour.
Où trouver la liste officielle des sale condition codes ?
Le CTA Plan et le UTP Plan publient les spécifications des sale conditions applicables aux tapes qu’ils administrent. Ces documents font autorité. Les flux des fournisseurs renumérotent les conditions dans leur propre espace d’identifiants. Un code numérique d’un fournisseur ne correspond donc pas nécessairement au même numéro chez un autre.
Chaque panneau est accompagné du SQL qui l’a produit. Ouvrez-en un, remplacez le ticker ou la date, puis appliquez la même analyse des conditions à toute session sur le terminal Strasmore.