24. Cotizaciones en tiempo real, demoradas y de cierre

24.1 Una cotización no es solo un número

Una pantalla puede mostrar $100, pero ese número podría ser la mejor compra, la mejor venta, la última operación, un punto medio, un cierre o un precio calculado. Cada dato tiene un significado diferente.

También necesita instrumento, mercado, moneda, sesión, fuente y tiempo. Omitir ese contexto puede hacer que dos cifras correctas parezcan contradictorias o que una cifra antigua se use como si fuera actual.

Idea central: antes de consumir un precio, preguntá qué representa, cuándo se originó, cuándo llegó, de qué mercado proviene y bajo qué licencia puede utilizarse.

24.2 Los componentes mínimos

24.3 Bid, ask y última operación

24.4 Cotización en tiempo real

Una cotización en tiempo real se distribuye sin una demora intencional preestablecida. Eso no significa latencia cero: capturar, normalizar, transmitir, procesar y dibujar el dato requiere tiempo.

“Tiempo real” describe una modalidad de distribución. Para decidir si un dato sigue vigente hay que medir su antigüedad y conocer el estado del mercado.

24.5 Cotización demorada

Una cotización demorada se publica después de un intervalo definido por el proveedor o mercado. Puede servir para educación, información general o análisis que no depende del estado inmediato.

Actualizar la pantalla cada segundo no convierte un dato demorado en tiempo real: solo refresca repetidamente información cuyo origen sigue retrasado. La interfaz debe mostrar claramente la demora y, cuando sea posible, su duración.

24.6 Datos de cierre

El dato de cierre representa una referencia asociada al final de una sesión o fecha de mercado. Puede provenir de la última operación elegible, una subasta de cierre, un cálculo oficial u otra metodología.

Es adecuado para informes diarios y determinadas valoraciones, pero no describe una propuesta vigente durante la sesión siguiente. Debe acompañarse con fecha de mercado y condición de cierre.

24.7 Última operación y cierre oficial

La última operación cronológica no siempre coincide con el cierre oficial. Pueden existir operaciones fuera de la sesión regular, ejecuciones con condiciones especiales o una subasta que determine el cierre.

24.8 Cierre sin ajustar y cierre ajustado

El cierre sin ajustar conserva el precio publicado para esa fecha. El cierre ajustado modifica la serie histórica para reflejar determinados eventos, como desdoblamientos o distribuciones, según la metodología del proveedor.

No debe reemplazarse el precio original sin identificar la transformación. Para auditoría conviene conservar ambos valores, factores de ajuste, eventos considerados y versión de la metodología.

Atención: proveedores distintos pueden producir cierres ajustados diferentes si no usan los mismos eventos, fechas o supuestos de reinversión.

24.9 Comparación de modalidades

24.10 Tres relojes diferentes

Una aplicación robusta separa al menos tres instantes. La hora del evento indica cuándo ocurrió en el mercado; la hora de recepción, cuándo llegó al sistema; la hora de procesamiento, cuándo la aplicación terminó de tratarlo.

Usar únicamente la hora del equipo que dibuja la pantalla impide medir la demora anterior y puede alterar el orden real de los acontecimientos.

24.11 El recorrido de una actualización

Cada tramo agrega latencia y puede fallar de manera independiente. Medir solo el tiempo total ayuda a detectar un problema, pero no a localizarlo.

24.12 Zona horaria y fecha de mercado

Las marcas temporales deben incluir zona u offset, o expresarse en UTC. Aun así, la fecha calendario del servidor puede no coincidir con la fecha de mercado relevante para la sesión.

Una sesión puede atravesar la medianoche, y mercados diferentes pueden estar en fechas locales distintas. Agrupar datos mediante timestamp.slice(0, 10) sin reglas de sesión puede asignar una operación al día incorrecto.

24.13 Vigencia y dato obsoleto

Un dato está obsoleto o stale cuando su antigüedad supera el umbral aceptable para el uso previsto. Ese umbral depende del instrumento, la sesión, la fuente y la función de la aplicación.

Durante una pausa o con el mercado cerrado, la ausencia de actualizaciones puede ser normal. Por eso la vigencia no se clasifica correctamente sin estado de sesión.

24.14 Instantáneas y flujo continuo

Una instantánea describe el estado conocido en un momento. Un flujo transmite cambios sucesivos. Para reconstruir estado, una aplicación suele partir de una instantánea y aplicar después actualizaciones incrementales.

Si se pierde un mensaje, continuar aplicando incrementos puede dejar un libro incorrecto. El protocolo debe indicar cómo detectar brechas y solicitar o recibir una nueva instantánea.

24.15 Secuencia, duplicados y mensajes fuera de orden

Los números de secuencia permiten ordenar mensajes dentro del alcance definido por la fuente. Una secuencia repetida puede indicar duplicación; un salto, pérdida; una secuencia menor que la aplicada, llegada tardía.

Regla práctica: documentar si la secuencia es global, por instrumento, por canal o por sesión. Comparar números pertenecientes a alcances distintos produce falsas alarmas.

24.16 Streaming y consultas periódicas

En streaming, la fuente envía actualizaciones cuando ocurren. En una consulta periódica o polling, el cliente pregunta cada cierto intervalo. Ambos modelos pueden entregar datos en tiempo real o demorados según el producto contratado.

El transporte no determina la modalidad económica del dato. Un WebSocket puede transportar precios demorados y una API consultada periódicamente puede devolver la última cotización en tiempo real disponible.

24.17 Fuente directa y fuente consolidada

Una fuente directa proviene de un mercado específico. Una fuente consolidada combina información de varios centros bajo reglas de selección y normalización.

La mejor compra consolidada puede provenir de un mercado y la mejor venta de otro. Para evaluar ejecutabilidad hay que considerar acceso, enrutamiento, cantidades, tasas, moneda, horarios y reglas de cada centro.

24.18 Profundidad y alcance

El nivel superior suele incluir mejor bid y mejor ask con sus cantidades. La profundidad agrega niveles posteriores. Un flujo de operaciones informa ejecuciones, no necesariamente órdenes vigentes.

Los nombres comerciales varían. La documentación de campos y alcance es más confiable que asumir contenido a partir de una etiqueta.

24.19 Correcciones y cancelaciones

Una operación publicada puede corregirse o cancelarse posteriormente. Si una aplicación solo agrega mensajes, conservará precios o volúmenes que la fuente ya rectificó.

Conviene almacenar el identificador del evento original, tipo de acción, versión, estado y referencia a la corrección. Recalcular indicadores desde una secuencia auditable evita modificar silenciosamente la historia.

24.20 Licencias y permisos de uso

Los datos de mercado suelen estar sujetos a contratos, permisos y categorías de uso. Visualizar, redistribuir, almacenar, derivar indicadores o mostrar a usuarios profesionales pueden requerir autorizaciones distintas.

Importante: que una API sea técnicamente accesible no implica que sus datos puedan copiarse, redistribuirse o conservarse sin límites. La aplicación debe respetar la licencia de la fuente concreta.

24.21 Laboratorio: evaluar una cotización

Seleccioná modalidad, sesión, antigüedad operativa y spread. El ejemplo añade 15 minutos cuando la fuente es demorada y clasifica el dato según su uso posible.

24.22 Validar una cotización con JavaScript

function validarCotizacion(cotizacion) {
  const errores = [];
  if (!cotizacion.instrumento) errores.push("Falta el instrumento");
  if (!cotizacion.mercado) errores.push("Falta el mercado");
  if (!cotizacion.moneda) errores.push("Falta la moneda");
  if (!Number.isFinite(cotizacion.bid) || !Number.isFinite(cotizacion.ask)) {
    errores.push("Las puntas deben ser numéricas");
  } else if (cotizacion.bid > cotizacion.ask) {
    errores.push("El bid supera al ask");
  }
  if (Number.isNaN(Date.parse(cotizacion.horaEvento))) {
    errores.push("Hora de evento no válida");
  }
  return { valida: errores.length === 0, errores };
}

console.log(validarCotizacion({
  instrumento: "ABC",
  mercado: "MERCADO-EJEMPLO",
  moneda: "ARS",
  bid: 99.80,
  ask: 100.20,
  horaEvento: "2026-09-14T11:30:15.250-03:00"
}));

24.23 Clasificar la vigencia

function clasificarVigencia({ horaEvento, horaActual, modalidad, sesion }) {
  const antiguedadMs = Date.parse(horaActual) - Date.parse(horaEvento);
  if (!Number.isFinite(antiguedadMs) || antiguedadMs < 0) return "INVALIDA";
  if (modalidad === "CIERRE") return "REFERENCIA_DE_CIERRE";
  if (modalidad === "DEMORADA") return "DEMORADA";
  if (sesion === "CERRADA") return "ULTIMA_CONOCIDA_MERCADO_CERRADO";
  return antiguedadMs <= 30000 ? "VIGENTE" : "OBSOLETA";
}

console.log(clasificarVigencia({
  horaEvento: "2026-09-14T14:00:00.000Z",
  horaActual: "2026-09-14T14:00:12.000Z",
  modalidad: "TIEMPO_REAL",
  sesion: "ABIERTA"
}));

24.24 Controlar una secuencia de actualizaciones

function aplicarActualizacion(estado, mensaje) {
  if (mensaje.secuencia <= estado.secuencia) {
    return { ...estado, advertencia: "Duplicado o mensaje tardío" };
  }
  if (mensaje.secuencia !== estado.secuencia + 1) {
    return { ...estado, advertencia: "Brecha: solicitar instantánea" };
  }
  return {
    ...estado,
    secuencia: mensaje.secuencia,
    bid: mensaje.bid,
    ask: mensaje.ask,
    advertencia: null
  };
}

const estado = { secuencia: 104, bid: 99.80, ask: 100.20 };
console.log(aplicarActualizacion(estado, {
  secuencia: 106,
  bid: 99.90,
  ask: 100.20
}));

24.25 Modelar cierre y ajustes por separado

const datoDiario = {
  instrumento: "ABC",
  fechaMercado: "2026-09-14",
  moneda: "ARS",
  cierreOficial: 120.50,
  ultimaOperacion: 120.45,
  cierreAjustado: 60.25,
  factorAjuste: 0.5,
  motivoAjuste: "DESDOBLAMIENTO_2_POR_1",
  version: 2,
  fuente: "PROVEEDOR-EJEMPLO"
};

console.log("Cierre publicado:", datoDiario.cierreOficial);
console.log("Cierre comparable ajustado:", datoDiario.cierreAjustado);
console.log("¿Coincide con la última?", datoDiario.cierreOficial === datoDiario.ultimaOperacion);

24.26 Errores frecuentes

• Mostrar un precio sin indicar si es bid, ask, última operación o cierre.
• Llamar “tiempo real” a un dato solo porque la pantalla se actualiza seguido.
• Confundir hora del evento con hora de recepción.
• Ignorar zona horaria, sesión y fecha de mercado.
• Usar la última operación como una cotización ejecutable.
• Tratar cierre oficial, última operación y cierre ajustado como equivalentes.
• Aplicar incrementos después de perder mensajes sin reconstruir el estado.
• Redistribuir datos sin verificar permisos y licencia.

24.27 Ejercicio integrador

Una aplicación recibe a las 14:30:20 UTC una cotización con hora de evento 14:15:18 UTC, marcada como demorada 15 minutos. El bid es $75,10, el ask $75,50 y la última operación $75,40. Calculá la demora técnica adicional, el spread y el punto medio. Indicá si la última operación es una oferta vigente.

const evento = Date.parse("2026-09-14T14:15:18Z");
const recepcion = Date.parse("2026-09-14T14:30:20Z");
const demoraTotalSegundos = (recepcion - evento) / 1000;
const demoraContractualSegundos = 15 * 60;
const demoraTecnica = demoraTotalSegundos - demoraContractualSegundos;

const bid = 75.10;
const ask = 75.50;
const ultima = 75.40;
const spread = ask - bid;
const puntoMedio = (bid + ask) / 2;

console.log({ demoraTecnica, spread, puntoMedio, ultima });

24.28 Ideas para recordar

• Todo precio necesita tipo, instrumento, mercado, moneda, fuente y tiempo.
• Tiempo real no significa ausencia de latencia.
• Una demora intencional debe mostrarse explícitamente.
• Última operación, cierre oficial y cierre ajustado responden preguntas diferentes.
• Hora del evento, recepción y procesamiento permiten medir tramos distintos.
• Secuencias y nuevas instantáneas ayudan a mantener un estado coherente.
• La licencia del dato importa tanto como su formato técnico.

En el próximo tema estudiaremos las series OHLCV: apertura, máximo, mínimo, cierre y volumen.