La red como señal, dentro de una autorización

En el Antel Summit de agosto, Javier Beceiro de Kinetix y Juan Andrés Antoniuk de JAAB Tech presentaron un argumento: la red móvil sabe cosas sobre un dispositivo que ningún sistema de pagos puede inferir, y GSMA Open Gateway las convierte en APIs estándar en lugar de integraciones una a una. El argumento completo está publicado, y la frase que quedó fue esta:

“La voz se puede falsificar. El estado de la línea no. La red no infiere: sabe, y con marca de tiempo.”

Esto no es una hipótesis de laboratorio. El caso mejor documentado es el de Itaú Unibanco en Brasil, con otra de las APIs de la familia: integró la consulta de SIM swap en 2023 y para abril de 2025 acumulaba más de 36,5 millones de consultas, un promedio de cinco millones por mes, según el caso publicado por la GSMA. Ataca el fraude de intercambio de SIM, donde alguien se hace pasar por el titular ante la operadora, consigue un chip con el mismo número y pasa a recibir los códigos que el banco manda por SMS. La GSMA mantiene una biblioteca de casos que crece con cada release, con bancos, aseguradoras y plataformas; el repaso de los que más importan está en las notas de la charla.

Esas mismas notas terminaban con una admisión: hasta ese momento no había trabajo hecho sobre las APIs de CAMARA; lo que estaba reconocido era la forma del problema.

Ya está hecho. fluxrig 0.9.0 trae ese caso implementado y documentado de punta a punta.

Qué hace, concretamente

Llega una autorización ISO 8583. Antes de reenviarla al autorizador, el flujo consulta Device Roaming Status, una API de CAMARA, y pregunta en qué país está el dispositivo asociado a esa cuenta. Si el comercio está en Montevideo y el teléfono está en Madrid, eso es un dato que la transacción no contiene y que solo la red conoce.

Lo interesante es que sirve igual en el sentido inverso: un teléfono en el mismo país que el comercio es motivo para sacarle fricción a una transacción que, sin esa señal, habría pedido una verificación adicional al titular.

Y esa verificación no sale gratis. Cada paso que se le agrega al titular pierde gente por el camino: hay quien no tiene el teléfono a mano, quien no recibe el código, quien desconfía de la pantalla que le aparece. Una parte de esas compras se abandona y no vuelve. Evitar el paso cuando la red confirma que no hace falta no es comodidad: es una venta que no se cae.

La parte difícil nunca fue el camino feliz

Una autorización de pago no puede esperar. El titular está frente a un POS, la terminal de pago del comercio, o mirando la pantalla de una compra online, y todo el intercambio tiene que resolverse en menos de lo que dura esa pausa. Esa restricción es la que ordena todo el diseño, y es donde está el trabajo real.

La consulta a la operadora tiene un plazo duro de 250 milisegundos. Lo que importa no es qué pasa cuando responde a tiempo, sino qué pasa cuando no.

Por eso el resultado no es un sí o un no. Son siete situaciones distintas, cada una con su propio código y su propio camino:

1. Los países coinciden.
2. No coinciden.
3. El número no es un abonado conocido de la operadora.
4. La operadora respondió con error.
5. La operadora no respondió dentro del plazo.
6. Respondió, pero sin informar país.
7. La tarjeta no está en el padrón, así que no se consulta nada y el mensaje sigue intacto.

Las dos primeras son la señal. Las cuatro siguientes, de la 3 a la 6, son todas “no hay señal”, y agruparlas sería perder la información más útil: un número que no existe puede ser motivo de sospecha, una operadora caída no dice nada sobre el titular, y una operadora que simplemente tardó permite medirla y reclamarle.

La séptima no es una forma de fallar: es la medida de la cobertura. No toda tarjeta tiene un número asociado, y esa ausencia se registra como tal.

Lo que no viaja

El número de teléfono se usa para consultar y se borra antes de que el mensaje siga camino. No llega al autorizador, no queda en los registros, no aparece en la traza. Es una línea de configuración, no una política que alguien tiene que recordar aplicar.

Y una consecuencia que no era obvia

Mientras se espera a la operadora queda guardada la dirección de vuelta: por qué conexión hay que contestarle a quien preguntó. Esa reserva vive treinta segundos en este escenario, y es configurable.

Si ese tiempo se agota, la respuesta del autorizador no se descarta: sigue viaje, pero sin la dirección de vuelta, y entonces sale por la conexión equivocada, que para el switch es una conexión que ya no existe. O sea que ese valor no es un detalle de memoria: es el límite de cuánto puede demorar el autorizador antes de que la transacción quede sin respuesta.

Configuración, no código

Nada de lo anterior es una extensión ni un plugin. Es un escenario declarativo: los tiempos, el mapeo de códigos, los caminos de degradación y el borrado del número de teléfono son todos configuración. Cambiar el plazo de 250 a 400 milisegundos, o agregar una segunda señal de red al lado de la primera, no requiere compilar nada.

Eso también significa que el caso es auditable antes de correrlo, que es lo que suele pedir quien firma el riesgo.

Medido, no prometido

Los siete resultados se verifican de a una transacción por vez, pero la correlación es una propiedad de concurrencia: una clave que colisiona devuelve la respuesta equivocada a quien no la pidió, y eso una prueba de a una no lo puede ver. Por eso hay una segunda suite que corre el mismo escenario con muchos emisores a la vez.

Los cuatro casos pasan, y todos afirman lo mismo: ninguna respuesta llegó a quien no la había pedido. El de mayor concurrencia movió 12.600 transacciones a 784 por segundo, y el que hace ocurrir los siete resultados al mismo tiempo, 7.000 a unas 780.

La latencia se informa por camino y no como promedio, porque la mezcla es deliberadamente bimodal: cuando la operadora responde, p50 de 31 ms y p99 cerca de 100; cuando no responde a tiempo, 261 y 443, que son los 250 de presupuesto más el mismo trabajo. Un promedio entre las dos daría unos 60 ms y no describiría ninguna transacción real.

La documentación es explícita sobre qué significan esos números y qué no: miden correctitud bajo carga, no capacidad. Todo corrió en un escritorio, con el Mixer, los dos Racks, el autorizador simulado y los cuarenta y dos procesos emisores compitiendo por los mismos núcleos.

Dónde seguir

El tutorial completo construye el caso paso a paso, incluido el simulador de operadora, y cierra con una tabla de qué está disponible y qué no, que es donde conviene mirar antes de planificar sobre esto.

El argumento más amplio, sobre qué APIs existen, qué casos hay en el mercado y por qué la red aporta determinismo donde el antifraude trabaja con probabilidad, está en el artículo de Pyxis y en las notas de la charla.

El puente entre la telco y la fintech no lo construye el estándar: lo construye un primer caso acotado, un solo flujo, medido. Ahora hay uno que se puede leer, correr y discutir. Si trabajás en un banco, en una fintech o en una operadora y estás mirando esto, escribinos.