Strasmore Research

Self-match prevention y wash trades: cómo funcionan

La prevención del self-match evita que tus propias órdenes operen entre sí. Conoce su función en el matching engine y cuándo comienza a aplicar la ley sobre wash trades.

La prevención del self-match es una función del matching engine que impide que dos órdenes de la misma firma operen entre sí. Las órdenes llevan un identificador al entrar, y cuando dos órdenes con ese identificador se cruzarían, el engine cancela una o ambas antes de que se registre una operación. La prevención del self-match es una herramienta de infraestructura del venue que se activa, mientras que la prohibición de wash trades es una norma legal. No cubren lo mismo.

Esta regla se vuelve relevante en cuanto una segunda estrategia cotiza un instrumento que la primera ya cotiza. Un bot de grid con two-to-one niveles sobre un mismo ticker queda sujeto a ella en los mismos términos que un trading desk bancario.

Cómo funciona la prevención del self-match en el matching engine

Cada orden que recibe un venue incluye campos que el engine lee antes de hacer el matching: lado, precio, tamaño y vigencia. La prevención del self-match añade otros dos. El primero es un identificador, un número o una cadena que indica a qué firma, cuenta o grupo de estrategias pertenece la orden. El segundo es una instrucción que indica al engine qué debe hacer cuando dos órdenes activas con ese identificador están a punto de operar entre sí.

La comprobación se ejecuta en el instante en que una orden agresora alcanza el precio de una orden pasiva con la que haría match. Hay cuatro resultados habituales:

  • Cancelar la orden pasiva. La orden entrante continúa en el libro y puede hacer match con las órdenes que estén detrás a ese precio.
  • Cancelar la orden entrante. La orden pasiva conserva su posición en la cola y la agresora desaparece.
  • Cancelar ambas órdenes. Es la configuración más estricta.
  • Reducir y cancelar. La orden más grande se reduce por el tamaño de la más pequeña, la orden pequeña se cancela y el remanente sigue activo.

En ninguno de los cuatro casos se ejecuta una operación. No aparece ningún print en el tape, no se registra nada en el fill log y llega una cancelación no solicitada sobre una de las dos órdenes o sobre ambas.

La posición en la cola es el costo menos visible. Una orden pasiva cancelada bajo una instrucción de cancel-oldest pierde todo lo que había ganado al esperar. Con prioridad precio-tiempo, la pérdida es total: al volver a entrar, la orden queda detrás de todos los participantes que se incorporaron a la cola mientras permanecía allí. Nuestra guía sobre cómo estimar la posición en la cola explica cuánto vale ese lugar.

Un instrumento, muchos libros

La comprobación se hace por venue. Un engine solo compara las órdenes que mantiene en su propio libro. Dos órdenes suyas que estén pasivas en dos libros distintos son invisibles entre sí, y ningún mecanismo de renta variable estadounidense las compara entre venues. Una misma acción estadounidense cotiza simultáneamente en muchos libros. El panel siguiente cuenta los venues distintos que cotizaron y registraron prints de seis acciones conocidas durante una ventana de fifteen minutes en la mañana del 10 de junio de 2026.

ConsultaMercados cotizando y registrando la misma acción en una ventana de 15 minutos
El SQL exacto detrás de cada cifra
SELECT
    q.ticker          AS ticker,
    q.quoting_venues  AS quoting_venues,
    t.printing_venues AS printing_venues
FROM
(
    SELECT
        ticker,
        countDistinct(bid_exchange) AS quoting_venues
    FROM global_markets.cache_stocks_quotes
    WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO', 'JNJ')
      AND sip_timestamp >= toDateTime('2026-06-10 14:00:00', 'UTC')
      AND sip_timestamp <  toDateTime('2026-06-10 14:15:00', 'UTC')
      AND bid_price > 0
    GROUP BY ticker
) AS q
INNER JOIN
(
    SELECT
        ticker,
        countDistinct(exchange) AS printing_venues
    FROM global_markets.stocks_trades
    WHERE ticker IN ('AAPL', 'MSFT', 'NVDA', 'SPY', 'KO', 'JNJ')
      AND sip_timestamp >= toDateTime('2026-06-10 14:00:00', 'UTC')
      AND sip_timestamp <  toDateTime('2026-06-10 14:15:00', 'UTC')
    GROUP BY ticker
) AS t ON t.ticker = q.ticker
ORDER BY quoting_venues DESC, ticker
Run this yourself

AAPL recibió bids de 16 venues distintos durante ese cuarto de hora, y hubo prints en 17 de ellos. Incluso la acción con menor actividad del panel recibió cotizaciones de 11 venues. Un smart order router que divide child orders por diseño colocará sus dos estrategias en libros distintos buena parte del tiempo. En esos casos no se aplica ninguna comprobación a nivel del engine. Las firmas cierran esa brecha aguas arriba, en la capa de gestión de órdenes, antes de que algo salga del edificio. Sus propias órdenes pasivas en lados opuestos y al mismo precio en dos libros también generan un mercado bloqueado o cruzado, sujeto a sus propias reglas.

Cuántos matches hace un libro durante una sesión

La comprobación de self-match está en la ruta de cada match que realiza el engine. En una acción líquida, esa ruta permanece activa durante toda la jornada. El panel siguiente divide una sesión completa de una acción en intervalos de fifteen minutes y cuenta los prints de cada intervalo. Solo conserva los intervalos con al menos 200 prints.

ConsultaOperaciones por intervalo de 15 minutos, una sesión completa
El SQL exacto detrás de cada cifra
SELECT
    formatDateTime(toStartOfInterval(toTimeZone(sip_timestamp, 'America/New_York'), INTERVAL 15 MINUTE), '%H:%i') AS et_time,
    count() AS trade_count
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
  AND sip_timestamp >= toDateTime('2026-06-10 08:00:00', 'UTC')
  AND sip_timestamp <  toDateTime('2026-06-11 04:00:00', 'UTC')
GROUP BY et_time
HAVING count() >= 200
ORDER BY et_time
Run this yourself

A las 04:00 ET, esa acción registró 9402 operaciones en fifteen minutes. A las 19:45 ET registró 1345, en un total de 64 intervalos que superaron el mínimo de 200 prints. Cada print representa un par de órdenes que el engine reunió. Antes de permitir el match, la comprobación lee los identificadores de ambos lados. Toda orden que queda pasiva en el libro puede encontrarse más tarde con otra orden de la misma cuenta.

Qué muestra el tape cuando se ejecuta un self-trade

Un self-match prevenido no deja ningún rastro. El tape solo contiene las operaciones ejecutadas, y cada print llega con condition flags: códigos que el venue informante adjunta para describir cómo ocurrió la operación. El panel siguiente divide una sesión completa de una acción según esos flags.

ConsultaIndicadores de condición de operación en una sesión completa
El SQL exacto detrás de cada cifra
SELECT
    condition_name,
    print_count,
    round(100 * print_count / sum(print_count) OVER (), 2) AS share_pct
FROM
(
    SELECT
        cc.id        AS condition_id,
        any(cc.name) AS condition_name,
        count()      AS print_count
    FROM
    (
        SELECT toInt32(arrayJoin(conditions)) AS condition_id
        FROM global_markets.stocks_trades
        WHERE ticker = 'AAPL'
          AND sip_timestamp >= toDateTime('2026-06-10 08:00:00', 'UTC')
          AND sip_timestamp <  toDateTime('2026-06-11 04:00:00', 'UTC')
    ) AS f
    INNER JOIN
    (
        SELECT
            toInt32(id)  AS id,
            any(name)    AS name
        FROM global_markets.stocks_condition_codes
        WHERE asset_class = 'stocks'
          AND has(data_types, 'trade')
        GROUP BY id
    ) AS cc ON cc.id = f.condition_id
    GROUP BY condition_id
)
ORDER BY print_count DESC
LIMIT 10
Run this yourself

Odd Lot Trade representa 48.34% de los prints con flags de esa sesión. El panel muestra los 10 flags más comunes del día. Observe también lo que no aparece. Ningún código indica que dos órdenes procedían de la misma firma. Un self-trade que sí se ejecuta se ve como cualquier otra operación a ese precio. Por eso, la vigilancia se basa en el tape, en los identificadores de los participantes que conserva el venue y en los números de cuenta asociados a las órdenes.

Dónde termina la prevención del self-match y empieza la legislación sobre wash trades

La prevención del self-match es un servicio del venue. La firma se adhiere, lo configura y, si nunca lo activa, el engine hará match entre sus dos órdenes sin inconvenientes. La prohibición de wash trades no es opcional y no depende de ninguna configuración.

La Section 9(a)(1) de la Securities Exchange Act of 1934 alcanza las operaciones con valores que no implican un cambio en la titularidad efectiva y que se introducen para crear una apariencia engañosa de actividad. La Commodity Exchange Act contiene el equivalente para futuros, y la CME Rule 534 lo reitera en el reglamento del exchange. La FINRA Rule 5210 se aplica a los broker-dealers en ambos casos, y su material suplementario aborda directamente los self-trades: las operaciones entre dos algoritmos no relacionados de una misma firma no constituyen por sí solas una infracción, pero se espera que la firma mantenga políticas para revisarlas y reducirlas.

De aquí se derivan dos consecuencias para quien opera más de una estrategia. Un self-cross puede infringir la prohibición en un venue donde no haya configurado ninguna instrucción de self-match, porque la norma se aplica a la operación y a la intención que la motiva. Un self-cross que la prevención del self-match detuvo no infringe ninguna norma. Detenerlo es precisamente el objetivo de la herramienta.

Cómo lo configuran los operadores: CME, ICE, LME y MiFID II

En CME Globex, la prevención del self-match utiliza un identificador enviado al introducir la orden. Las firmas registran los identificadores que utilizarán, cada orden lleva uno y una instrucción asociada indica qué lado cancela el engine cuando se encuentran dos órdenes con ese identificador. Las órdenes enviadas sin identificador hacen match normalmente. Esa es la trampa para un operador nuevo: la configuración predeterminada está desactivada.

ICE ofrece Self-Trade Prevention Functionality, configurada con un identificador de la firma operadora en lugar de hacerlo orden por orden, con la misma familia de resultados de cancelación. La London Metal Exchange ofrece Self-Execution Prevention en LMEselect para los identificadores de trading de sus miembros. En Europa, el Article 17 de MiFID II impone obligaciones de sistemas y controles a toda firma de inversión que realice trading algorítmico. Incluye pruebas, kill functionality y prevención de operaciones desordenadas. El Article 48 impone una obligación paralela al venue, y las herramientas de prevención del propio venue se convirtieron en un componente estándar junto con esas obligaciones.

La configuración se aplica a nivel de cuenta o de firma, no símbolo por símbolo. El tamaño del option surface de un mismo subyacente explica por qué.

ConsultaContratos de opciones con volumen sobre un subyacente, junio de 2026
El SQL exacto detrás de cada cifra
SELECT
    toString(date)                 AS session_date,
    countDistinct(ticker)          AS contracts_traded,
    countDistinct(strike_price)    AS strikes_traded
FROM global_markets.options_greeks
WHERE underlying_symbol = 'AAPL'
  AND date >= '2026-06-01'
  AND date <= '2026-06-30'
  AND volume > 0
  AND iv_converged = 1
GROUP BY date
ORDER BY date
Run this yourself

El 2026-06-01, un subyacente tenía 1579 contratos negociables por separado con volumen, distribuidos entre 112 strikes. El panel cubre 21 sesiones de características similares. Configurar una regla contrato por contrato resulta inviable con ese volumen. El identificador se asocia a la cuenta y acompaña cada orden que esa cuenta envía.

El modo de fallo que sus fill logs no explicarán

Así se manifiesta en la práctica. Una instrucción de cancel-newest elimina la orden que acaba de enviar en el momento de su llegada, antes de que pueda hacer match. Desde el bot, la secuencia se ve como una orden nueva seguida de una cancelación que ningún componente del sistema solicitó. No hay fill, rechazo ni mensaje de error que indique el motivo. Por eso, quienes se encuentran con este comportamiento por primera vez suelen buscar un fallo en su propia lógica de cancelación.

Dos hábitos ayudan a interpretarlo. Registre literalmente los mensajes de estado de órdenes del venue en lugar de usar un resumen normalizado. El motivo de la prevención suele llegar como un campo de ese mensaje. También debe generar una alerta ante cualquier cancelación que no haya originado su propio código. Esa alerta debe integrarse con sus disyuntores de trading automatizado, porque el fallo pertenece a la misma categoría: el venue cambió el estado de su orden y el proceso continuó como si nada hubiera ocurrido.

Preguntas frecuentes

¿Qué es la prevención del self-match?

Es una comprobación del matching engine que impide que dos órdenes con el mismo identificador de firma o cuenta operen entre sí. Cuando están a punto de hacer match, el engine cancela la orden pasiva, la entrante o ambas, según la instrucción asociada a la orden.

¿Un self-trade es lo mismo que un wash trade?

No. Un self-trade es cualquier operación entre dos órdenes del mismo titular efectivo. Un wash trade es un self-trade introducido sin una exposición genuina al riesgo de mercado y con la intención de crear una apariencia engañosa de actividad. Los self-trades no intencionales entre algoritmos no relacionados reciben un tratamiento distinto al de las operaciones coordinadas. Aun así, se espera que las firmas los supervisen.

¿La prevención del self-match funciona entre exchanges distintos?

No. Cada matching engine aplica la comprobación únicamente a las órdenes de su propio libro. Dos órdenes de una misma firma que estén pasivas en dos venues pueden operar entre sí. Esa prevención corresponde a las comprobaciones pre-trade de la firma, situadas por encima de los venues.

¿Por qué cancelaron mi orden sin fill ni motivo?

Una instrucción de cancel-newest es una posibilidad. El venue canceló la orden al llegar, antes de que pudiera hacer match con una orden pasiva que llevara su identificador. El motivo suele aparecer como un campo del mensaje de cancelación del venue y no como un rechazo.

¿Qué venues exigen un identificador de prevención del self-match?

Los requisitos varían según el venue y el producto. CME solicita un identificador al introducir la orden y exige registrarlo previamente. ICE y la London Metal Exchange ofrecen sus propias configuraciones a nivel de firma. Además, los venues europeos tienen obligaciones de sistemas y controles conforme a MiFID II. El reglamento del venue correspondiente al producto que opera es la autoridad aplicable.


Cada panel incluye el SQL que lo generó. Expanda cualquiera para consultarlo. Para contar los venues que cotizan una acción que opera o dividir una sesión según sus condition flags, formule la consulta en lenguaje sencillo en la terminal de Strasmore.

#market structure#matching engine#wash trades#trading bots#exchange rules