Redes Empresariales

August 10, 2026

La conectividad fintech que sí aguanta una auditoría CNBV

Los SLAs de revendedor no resisten una auditoría CNBV. Cómo Telecom District opera conectividad fintech con backbone propio y evidencia reconstruible.

Ingeniero de red revisando telemetría y registros de disponibilidad en una consola de varios monitores

Por Eduardo Martino, COO de Telecom District.

El problema de conectividad de una fintech regulada en México aparece el día que el auditor pide trazabilidad del enlace y lo que hay encima de la mesa es una hoja de Excel con el SLA de un revendedor. Este es el modelo que sí sostiene la revisión, visto desde quien lo opera con trece fintech en producción.

El día que el auditor de CNBV pide ver el enlace

Casi todas las fintech mexicanas reguladas descubren su problema de conectividad el mismo día: el día que la Comisión Nacional Bancaria y de Valores pide evidencia operativa concreta del enlace que sostiene su plataforma. Lo que pide es la capacidad de reconstruir qué pasó en el enlace durante una ventana específica, quién lo operaba en ese momento, cómo se levantó cada incidente y por qué el tráfico crítico hacia Banxico se mantuvo o no priorizado.

Ahí aparece la brecha. Porque el modelo que suele estar debajo, contratado durante los primeros dos años de vida de la fintech cuando la prioridad era montar producto rápido, es un revendedor. Alguien que compró capacidad en un operador grande, la re-empaquetó como un servicio con su marca y la vendió con un SLA en PDF. Cuando el auditor pide ver telemetría, logs de disponibilidad, tickets de incidentes y quién levantó cada tramo, la fintech se da cuenta de que "SLA 99.9%" en un papel no responde una sola de las preguntas que le hace el regulador.

Qué le falla al modelo de revendedor

El problema no es que el revendedor sea malicioso. Es estructural. Un revendedor no tiene backbone propio, así que no tiene telemetría propia. Tampoco tiene ingenieros operando los nodos, de modo que carece de autoridad para reconstruir un incidente sin depender del operador raíz. Y sus diagramas de tu enlace específico están siempre a medias, porque tu enlace es una porción compartida de un servicio genérico. Cuando la auditoría pide trazabilidad, que es en el fondo la capacidad de reconstruir qué pasó, cuándo pasó y por qué, el revendedor no la puede dar porque nunca la tuvo.

Lo que se ofrece en su lugar es la promesa de un SLA. Un SLA es una cláusula contractual. La cláusula dice qué debería pasar; la evidencia dice qué pasó. Al regulador le importa lo segundo.

Qué cambia cuando el operador es dueño del backbone

Un operador dueño de su backbone opera bajo un modelo distinto. En Telecom District, todo enlace enterprise corre sobre nuestra propia infraestructura EVPN sobre SRv6 que llevamos en producción desde marzo de 2025. Eso significa dos cosas prácticas para una fintech regulada.

La primera: todo tráfico que pasa por nuestra red genera telemetría que nosotros mismos operamos. Cuando el auditor pide un log de disponibilidad de tu enlace específico durante un trimestre, no hay que pedírselo a un tercero. Está en nuestros sistemas, con marca de tiempo, sin intermediarios, reconstruible al detalle.

La segunda: cada incidente lo levanta y lo cierra un ingeniero de Telecom District que sabe exactamente qué nodos toca, qué política de ruteo lo gobierna y qué QoS aplica. Es la consecuencia natural de que la red es nuestra. Cuando la fintech necesita presentar el post-mortem de un incidente al regulador, existe post-mortem, con causa raíz identificada, con acción correctiva y con firma de un ingeniero identificable.

Kontrol Edge, nuestra plataforma de conectividad empresarial, es donde se opera todo esto. La IA asiste al equipo humano: detecta patrones, cruza señales, sugiere primeras hipótesis. Pero la decisión operativa y la firma de la evidencia siguen siendo de la persona. Lo aclaramos porque hay ruido de mercado sobre "redes operadas por IA". La nuestra la opera gente, y es una decisión de diseño.

Trece fintech en producción: qué cambia realmente

Hoy operamos trece fintech mexicanas reguladas bajo este modelo. No podemos compartir nombres ni segmentos específicos porque la información es confidencial. Sí podemos compartir el perfil típico y lo que suele resolver.

El tamaño típico es una fintech entre 50 y 400 empleados, con producción activa, con al menos una integración crítica hacia Banxico o hacia un operador de servicios financieros regulado. Son operaciones que ya cursan pagos en producción y que se auditan.

El punto de entrada más común es una reingeniería de la conectividad que empezó porque la anterior no sostuvo una auditoría reciente, o porque un incidente de disponibilidad expuso la fragilidad del modelo de revendedor. En ambos casos, la conversación empieza en la mesa directiva con el área legal y el área de riesgo, no solo con el CIO.

Lo que ganan al migrar es un enlace enterprise que sí es auditable, con telemetría propia, con ingeniería identificable, con documentación reconstruible de cada tramo. Un tiempo de respuesta ante incidentes que se cuenta en minutos, sin escalamiento entre dos empresas. Y una relación comercial directa, sin capas intermedias que te separen del operador que efectivamente mueve tu tráfico.

Qué pesa realmente en la revisión regulatoria

La CNBV y Banxico revisan la conectividad de las instituciones fintech bajo criterios que evolucionan cada ciclo. Sin entrar en referencias específicas, que dependen de la naturaleza de la fintech, del tipo de servicios que cursa y del alcance de la revisión, hay tres áreas que aparecen sistemáticamente.

Continuidad operativa. No basta con tener un enlace redundante; hay que poder demostrar que la redundancia opera con evidencia. Un backbone propio con caminos alternos activos y con conmutación registrada da esa evidencia. Un modelo de revendedor rara vez la puede dar sin depender de la buena voluntad del operador raíz.

Trazabilidad del tráfico crítico. Los flujos hacia Banxico, hacia procesadores de pagos y hacia integraciones core deben ser identificables, priorizables y auditables. Un modelo con QoS real, aplicada por el operador dueño del backbone, resuelve esto por diseño.

Documentación y evidencia bajo pedido. El regulador puede pedir evidencia operativa con ventanas de tiempo específicas y con nivel de detalle específico. La única respuesta que sostiene la revisión es "aquí está". Ese aquí está lo da un operador que corre su propia red y tiene autoridad sobre los datos que la describen.

Si eres CIO o CFO de una fintech regulada, cómo empezar a evaluar

No hace falta migrar completo el día uno. Hace falta empezar a hacerse las preguntas correctas antes de la próxima revisión.

  • ¿Tu proveedor actual puede darte un log de disponibilidad de tu enlace específico, con marca de tiempo, sin intermediarios, dentro de 48 horas?
  • ¿Tu proveedor actual tiene ingenieros con nombre y apellido asignados a tu enlace, o pasas siempre por un pool de soporte que rota?
  • ¿Los post-mortems de tus últimos tres incidentes incluyen causa raíz identificada, o solo restablecimiento del servicio?
  • ¿Tu enlace crítico hacia Banxico o hacia tu procesador de pagos tiene QoS aplicada al nivel del backbone, o depende de que la red no esté saturada?

Si alguna de esas respuestas es incómoda, el problema está en el modelo.

Dónde queda Telecom District en esto

En Telecom District hacemos un tipo específico de trabajo: conectividad enterprise para instituciones que se auditan, bajo un modelo específico de red propia, ingeniería identificable y evidencia reconstruible. Las trece fintech en producción llegaron después de una auditoría o de un incidente, cuando entendieron que el papel no reemplaza al operador.

Eduardo Martino, COO de Telecom District

Eduardo Martino es COO de Telecom District. Dirige la operación comercial y regulatoria de la compañía y los proyectos enterprise en LATAM.

Mira cómo se opera una red sobre backbone propio

La capa sobre la que corren las trece fintech en producción: telemetría propia, ingeniería identificable y evidencia reconstruible de cada tramo.