Cada amenaza nueva suele llegar con su propio proveedor. Lo que casi nunca llega es la cuenta completa de lo que cuesta mantenerlos juntos, ni de lo que se escapa entre ellos.
En resumen: cada proveedor de identidad o antifraude añade un SDK, una integración, una dependencia y otra consola de reglas. El coste real no está en las licencias, sino en mantenerlos juntos y en el fraude que se cuela en los relevos entre herramientas.
El patrón se repite en casi todas las organizaciones reguladas. Primero llega un proveedor para verificar la identidad en el alta. Después, otro para la inteligencia de dispositivo. Luego, uno para detectar bots, otro para analizar el comportamiento en la sesión y, si hace falta, uno más para reforzar la autenticación. Cada decisión tiene sentido por separado. El problema aparece cuando se suman.
Lo que aparece en la factura y lo que no
La licencia es el coste visible. Es el que se negocia, se aprueba y se revisa cada año. Pero cada proveedor nuevo arrastra una serie de costes que no aparecen en ningún contrato y que acaba pagando el equipo técnico.
Más SDK
Cada control en el canal digital suele pedir su propio SDK. Eso significa más peso en la app, más permisos que justificar ante el usuario, más librerías que mantener al día y más posibilidades de conflicto entre ellas. Y cada actualización de un proveedor obliga a probar de nuevo todo el flujo, porque nadie garantiza que no rompa lo que hace el de al lado.
Más integraciones
Cada herramienta habla su propio idioma: su modelo de datos, su formato de puntuación, sus tiempos de respuesta y su manera de devolver un resultado. Alguien tiene que traducir entre todas ellas y decidir qué hacer cuando no coinciden. Esa capa intermedia rara vez se diseña. Crece sola, integración a integración, hasta que nadie la conoce entera.
Más dependencias
Con cada proveedor llega su hoja de ruta, su calendario de versiones, sus acuerdos de nivel de servicio y su forma de tratar los datos. Si uno cae, el recorrido se resiente. Si uno cambia de condiciones, hay que renegociar. Y cada uno es un tercero más con acceso a datos personales, con lo que eso supone para la gestión de riesgos y para la conversación con el regulador.
Más deuda técnica
La lógica de decisión acaba repartida: unas reglas viven en una consola, otras en otra, otras en el backend propio. Aparecen umbrales duplicados que se contradicen y excepciones que nadie recuerda por qué se crearon. Cambiar un criterio deja de ser una decisión de riesgo y se convierte en un proyecto de desarrollo.
| Coste | Dónde aparece | Quién lo paga |
|---|---|---|
| Licencia | Contrato anual | Compras y negocio |
| SDK adicional | Peso de la app, permisos, pruebas en cada versión | Equipo móvil |
| Integración | Traducción entre modelos de datos y puntuaciones | Equipo técnico |
| Dependencia | SLA, hoja de ruta y tratamiento de datos de un tercero más | Riesgos, legal y DPO |
| Deuda técnica | Reglas repartidas en varias consolas | Fraude y desarrollo |
| Huecos entre herramientas | Fraude que pasa y fricción a clientes legítimos | Toda la organización |
El coste que no se mide: los huecos entre herramientas
Todo lo anterior se puede presupuestar, aunque cueste. Lo que no se presupuesta es lo que pasa entre una herramienta y otra.
Pensemos en un caso habitual de account takeover. En el alta, la persona se verificó correctamente. Meses después, alguien entra con sus credenciales, que son las buenas. La herramienta de autenticación da el acceso por válido. La que analiza la sesión ve un dispositivo nuevo y un comportamiento algo distinto, pero no sabe quién se verificó en el alta ni cómo suele operar esa persona, así que no tiene con qué compararlo. Cada sistema aprueba su tramo. Ninguno ve la historia completa.
El fraude no necesita romper ningún control. Le basta con moverse por el espacio que queda entre ellos.
Cuantos más proveedores, más relevos y más espacio. Cada herramienta tiene una parte del contexto y ninguna lo tiene entero. El resultado es doble: más fraude que pasa sin ser visto y más clientes legítimos que reciben fricción porque ningún sistema sabe lo suficiente sobre ellos como para dejarlos pasar.
El mercado lo está viendo. Gartner anticipa que las soluciones puntuales de distintas áreas se consolidarán en plataformas unificadas, construidas en torno a la gestión de casos y a motores de decisión:
«La prevención del fraude online cambiará de forma significativa antes de que acabe la década». Gartner, Emerging Tech: The Future of Online Fraud Prevention (Gartner, enero de 2025; traducción propia)
Profundizamos en lo que Gartner ve en banca en su informe de Gartner 2026 sobre detección del fraude y prevención del blanqueo.
Cinco preguntas antes de sumar el siguiente proveedor
Si estás decidiendo entre una plataforma y especialistas, lo analizamos en suite o best of breed: cuándo elegir cada enfoque.
- ¿Comparte contexto con lo que ya tienes? Si no sabe quién se verificó en el alta, va a decidir sobre una identidad que desconoce.
- ¿Cuántos SDK tendrá tu app después? Y quién se encarga de que convivan en cada versión.
- ¿Dónde vivirá la decisión? Si añade otra consola de reglas, añade otro sitio donde revisar por qué se aprobó o se bloqueó algo.
- ¿Qué pasa con los datos? Dónde se procesan, quién los controla y qué opciones de despliegue hay.
- ¿Podrás reconstruir una decisión dentro de un año? Si la evidencia queda repartida entre proveedores, la auditoría también.
Un proveedor menos, no uno más
La alternativa no es renunciar a controles. Es que dejen de vivir aislados. Una identidad verificada en origen que acompaña cada acceso y cada sesión (verificación continua de la identidad) permite que cada señal nueva se compare con lo que ya se sabe de esa persona. Un solo SDK para todo el recorrido reduce la superficie técnica. Y una única lógica de riesgo, que propone y deja la decisión final al motor de reglas de cada organización, devuelve el control a quien tiene que tenerlo. Es el principio de la orquestación de identidad white box.
Menos piezas que mantener, menos relevos que vigilar y menos huecos por los que pueda entrar el fraude. Es el enfoque de la Facephi Identity Platform. Si quieres revisar cuántos proveedores sostienen hoy tu recorrido, habla con nuestro equipo.
Preguntas frecuentes sobre el coste de sumar proveedores
Más allá de la licencia: SDK adicionales en la app, integraciones que traducen entre herramientas, dependencias de terceros con acceso a datos personales y reglas repartidas en varias consolas. Y, sobre todo, el fraude que pasa por los huecos entre ellas.
Porque cada herramienta ve solo su tramo. Si la que analiza la sesión no sabe quién se verificó en el alta, no puede comparar el comportamiento con nada y aprueba un acceso que, visto entero, era sospechoso.
No. Significa que los controles compartan contexto: una identidad verificada que acompaña cada acceso y una lógica de riesgo común, con la decisión final en el motor de reglas de cada organización.
Si comparte contexto con lo que ya tienes, cuántos SDK tendrá tu app, dónde vivirá la decisión, qué pasa con los datos y si podrás reconstruir una decisión dentro de un año.
