En tecnología de seguridad, hay un momento del que poco se habla: el tiempo que transcurre entre detectar un problema y tener la solución funcionando. En cualquier estrategia de respuesta al fraude, ese intervalo puede prolongarse mucho más de lo esperado.
Hay un estado intermedio en el ciclo de respuesta al fraude que el sector raramente nombra con precisión. El problema ya se ha detectado. El equipo de fraude sabe qué necesita. Y, aun así, la solución puede tardar meses o incluso años en estar operativa, mientras pasa por un proceso que incluye conseguir respaldo interno, aprobar presupuesto, evaluar proveedores, negociar el contrato, completar la integración técnica y validar la solución en producción.
La tecnología no está operativa, pero tampoco ha quedado descartada. Está en un purgatorio.
Y mientras permanece ahí, el fraude que esa solución debería evitar sigue ocurriendo.
El purgatorio no es un fallo de ejecución
La primera reacción suele ser atribuir este retraso a problemas de integración: plazos de IT mal estimados, falta de recursos o dependencias técnicas que no se identificaron a tiempo. Todo eso influye, pero solo explica la última parte del proceso. El purgatorio empieza mucho antes.
Es un problema estructural. Cada equipo que toca la decisión tiene su propia velocidad y sus propias métricas. El fraude no espera a que se sincronicen.
El equipo de fraude detecta un nuevo vector de ataque en días. Para que una solución llegue a producción, normalmente atraviesa esto:
- Reconocer y validar el problema a nivel interno.
- Conseguir visibilidad y patrocinio ejecutivo.
- Obtener la aprobación del presupuesto.
- Evaluar y seleccionar al proveedor.
- Completar la negociación contractual y las revisiones legales.
- Integrar la solución en el entorno tecnológico.
- Validarla antes de su despliegue en producción.
Cada uno de estos pasos tiene sus propios tiempos y depende de equipos distintos. El fraude, en cambio, no espera a que la organización complete el proceso.
El tiempo entre identificar una necesidad de ciberseguridad y tener la solución operativa en instituciones financieras reguladas suele extenderse durante 12 meses y, en entornos con gobernanza más compleja, puede alargarse todavía más de 18 meses. Durante ese tiempo, el vector de ataque que originó la necesidad sigue activo.
¿Has caído en el purgatorio tecnológico?
Detectar el fraude no es lo mismo que responder a él. Entre identificar el problema y tener una solución operativa pueden pasar meses. Y durante ese tiempo, el fraude no se detiene.
Lo que el purgatorio le cuesta al negocio
El coste del purgatorio tecnológico no suele aparecer en los informes de fraude porque, sencillamente, no se mide como una categoría específica. Se registran las pérdidas provocadas por el fraude, pero no el coste que supone el tiempo que transcurre entre identificar un problema y disponer de una solución operativa.
Y cuando ese impacto no se cuantifica, resulta mucho más difícil darle prioridad.
El cálculo es sencillo. Toma el volumen mensual de transacciones del segmento de riesgo que la solución debería proteger. Aplica la tasa de fraude estimada en ausencia de esa protección y multiplícala por el coste medio de cada incidente. El resultado ofrece una aproximación al coste mensual de permanecer en ese intervalo.
En banca digital de mercados emergentes, esas tasas pueden ser significativas. Y suben cada semana que esperas.
Sin embargo, las soluciones de monitorización post-onboarding, que suelen requerir integraciones más profundas con la infraestructura core, también son las que más tiempo tardan en entrar en producción.
No es una coincidencia: cuanto más compleja es la implantación, mayor suele ser el tiempo que la organización permanece expuesta. De hecho, según el 2026 Cybersecurity Outlook de PwC, solo el 24% de las instituciones financieras globales ha logrado priorizar inversiones en el despliegue proactivo y rápido de infraestructura tecnológica de defensa; la gran mayoría sigue atrapada en ciclos reactivos condicionados por la complejidad de sus sistemas core.
La identificación de una cuenta mula suele producirse entre tres y seis meses después de su apertura. Durante ese tiempo, el fraude continúa generando pérdidas. Si existe una solución capaz de detectar esa actividad antes, cada mes que tarda en desplegarse amplía esa ventana de exposición.
El coste de este retraso es idéntico al impacto del Dwell Time en ciberseguridad. Reportes de la industria, como » Cost of a Data Breach”, sitúan el tiempo medio para identificar y contener una brecha en entornos financieros en 277 días.
Trasladado al negocio, un retraso de tres a seis meses en el despliegue de una herramienta equivale a regalarle a los defraudadores la mitad de su ciclo de vida operativo sin ninguna resistencia.
La arquitectura del problema
Para reducir ese intervalo, primero hay que entender por qué se produce. En la práctica, el purgatorio tecnológico se sostiene sobre tres factores:
El primero es la fragmentación de la urgencia
Ningún área tiene una visión completa del impacto del retraso. El equipo de fraude conoce el riesgo, pero no decide el presupuesto. El CFO controla el presupuesto, pero no ve de forma directa cuánto cuesta cada semana sin una solución operativa. La dirección acaba viendo el impacto cuando las pérdidas ya aparecen en los informes. El problema está presente en cada etapa del proceso, pero nadie tiene una visión completa de su coste.
El segundo es la falta de un responsable del proceso de principio a fin
En la mayoría de las organizaciones, el fraude tiene un responsable operativo, pero nadie asume la responsabilidad de acelerar todo el ciclo de respuesta. Y ahí está el problema: no depende solo de la tecnología, sino de la velocidad de decisión. Sin un patrocinio claro desde la dirección, cada paso espera su turno dentro de los procesos habituales, mientras el fraude avanza.
El tercero es cómo se mide el éxito en la relación entre proveedor y cliente
En muchos procesos comerciales, la firma del contrato se considera el hito principal. Pero, en seguridad de identidad, ese no es el momento en que la solución antifraude genera valor. Solo lo hace cuando está funcionando en producción. Todo el tiempo que transcurre antes —desde que se identifica la necesidad hasta la aprobación, la selección del proveedor, la negociación y la integración— forma parte del purgatorio tecnológico. Y durante ese tiempo, la organización sigue expuesta al fraude.
La receta para salir
El purgatorio tiene salida. Requiere decisiones en el orden correcto y tomadas por las personas correctas.
| Fase | Plazo | Acciones |
|---|---|---|
| Fase 1 Mapear y medir el purgatorio completo |
Semanas 1–2 |
|
| Fase 2 Acelerar la cadena de decisiones |
Semanas 3–6 |
|
| Fase 3 Comprimir el ciclo con el vendor |
Semanas 6–12 |
|
| Fase 4 Cerrar el ciclo y prevenir la recaída |
Mes 3 en adelante |
|
Lo que esto requiere de los vendors
Salir del purgatorio tecnológico no depende solo del cliente. Los proveedores también tenemos que asumir parte de esa responsabilidad.
Los vendors especializados en identidad y prevención del fraude contamos con una visión que difícilmente puede tener una organización por sí sola. Vemos patrones de ataque en distintos mercados, detectamos señales de escalada antes de que se generalicen y observamos cómo determinados métodos de fraude aparecen en una región antes de extenderse a otras. Esa información puede ser decisiva para un equipo intenta poner en marcha una solución y desconoce que el riesgo que motivó el proyecto ya está creciendo en su mercado.
Compartir ese conocimiento de forma proactiva debería formar parte del servicio. No solo cuando la solución ya está implantada, sino también durante ese periodo en el que el cliente sigue atravesando el purgatorio tecnológico.
El purgatorio tecnológico no aparece en los informes financieros.
Pero cada semana que una solución espera para entrar en producción tiene un coste. La diferencia es que pocas organizaciones lo calculan.
La decisión atraviesa una cadena que ningún departamento controla por completo: reconocer el problema, escalarlo, aprobar presupuesto, evaluar al proveedor, negociar el contrato e integrar. Cada eslabón tiene su propia velocidad. A ese intervalo entre detectar el fraude y tenerlo cubierto lo llamamos purgatorio tecnológico.
Coste mensual del purgatorio = volumen de riesgo expuesto sin cobertura × tasa de fraude esperada × coste medio por incidente. Es un coste acumulativo que rara vez aparece en los reportes de fraude porque no se mide como categoría propia.
Después del onboarding: la mayor parte del fraude ocurre en la fase de monitorización continua. La paradoja es que las soluciones post-onboarding, al requerir integraciones más profundas con el core bancario, son también las que más tardan en entrar en producción.
Un propietario ejecutivo con mandato sobre todo el ciclo, desde la detección hasta el go-live: CRO, COO o CDO según la estructura. Sin esa autoridad, cada decisión espera su turno en la agenda del departamento que la procesa, y el fraude no está en ninguna.
El fraude agéntico usa agentes de IA para ejecutar ataques a escala y velocidad. Ya es visible en los datos de inteligencia del sector. Las instituciones sin monitorización conductual post-onboarding activa probablemente tienen esa defensa aún sin desplegar.
La detección media de una cuenta mula, desde su apertura hasta su identificación, ronda los tres a seis meses. Ese intervalo no es solo tiempo de fraude activo: también es el tiempo que la solución capaz de detectarla antes pasó sin estar operativa.
Tres requisitos: un SLA de tiempo hasta producción (no solo de disponibilidad), sandbox y documentación técnica de due diligence desde el primer contacto, y un protocolo de alerta temprana ante vectores emergentes. El tiempo de evaluación también es tiempo de exposición.
Sí — y suele ser la vía más rápida. Una capa de orquestación que conecte las herramientas ya desplegadas y las combine con señales de identidad, comportamiento y actividad de cuenta evita el rip-and-replace, reduce el ciclo de integración y aprovecha la inversión existente. La media de 4–6 herramientas de fraude apiladas no es el problema; que no compartan señales, sí.
