Prevención de fraude al abrir cuentas

Última actualización: septiembre de 2026

La mayoría de las arquitecturas de prevención de fraude en la apertura de cuentas crecen proveedor a proveedor. Se añade una verificación de documentos tras un mal trimestre, una señal de dispositivo tras un ataque de bots y un segundo proveedor de datos para cubrir los huecos del primero. Cada adquisición tenía sentido cuando se firmó el contrato, pero en conjunto suelen ralentizar el proceso de registro, aumentar las revisiones manuales y generar decisiones que nadie puede explicar del todo.

La respuesta rápida: las herramientas de prevención de fraude en la apertura de cuentas funcionan cuando se unifican en una única decisión que gestiona el equipo de riesgos. Acumular proveedores de verificación rara vez funciona. Evalúe cada control en función de cómo influye en el resultado final (ya sea para aprobar, solicitar pasos adicionales, revisar o rechazar) y analice si su señal sigue estando disponible una vez abierta la cuenta.

Resumen rápido

• El fraude en la apertura de cuentas (también conocido como fraude de cuentas nuevas o de solicitud) consiste en abrir una cuenta utilizando una identidad robada, inventada o tergiversada, o con la intención de hacer un mal uso de ella una vez activa.

• Una arquitectura de prevención se compone de dos elementos: las comprobaciones que se realizan al abrir la cuenta y la lógica que unifica sus resultados en una sola decisión.

• Cada capa responde bien a una pregunta concreta pero pasa por alto otras. Los datos de identidad no pueden ver quién está tecleando; una comprobación de documentos no puede detectar una identidad sintética creada a partir de datos reales fragmentados.

• Añadir otro proveedor de verificación para responder a una pregunta que ya tiene respuesta solo aporta más trabajo de integración, tiempos de espera y abandono de usuarios, sin aportar información nueva.

• Realice comprobaciones pasivas a todos los usuarios y recurra a verificaciones costosas y complejas únicamente cuando el nivel de riesgo lo justifique. La decisión final debe tomarla una única capa de políticas, gestionada y probada por el equipo de riesgos.

• La decisión tomada durante el registro debe acompañar al cliente en el monitoreo de transacciones, ya que el fraude suele manifestarse en los primeros pagos de la cuenta.

¿Qué es el fraude en la apertura de cuentas y qué debe hacer una arquitectura de prevención?

El fraude en la apertura de cuentas es la apertura de una cuenta de depósito, tarjeta, préstamo o pago utilizando una identidad robada, inventada o falsa, o por parte de un solicitante que planea hacer un uso indebido de ella. En el sector crediticio, esto suele denominarse fraude de solicitud. Por lo general, la cuenta es solo el medio para lograr un fin: un préstamo que nunca se pagará, una tarjeta que se llevará al límite o una vía para mover dinero robado.

Una arquitectura de prevención de fraude en la apertura de cuentas es el conjunto de comprobaciones que realiza una entidad cuando alguien solicita el alta, junto con la lógica que transforma esos resultados en una de estas cuatro opciones: aprobar, solicitar pasos adicionales, enviar a revisión o rechazar. Muchas instituciones también realizan estas comprobaciones para cumplir con la normativa de identidad, pero una verificación de cumplimiento y una decisión de fraude no son lo mismo. Una arquitectura puede cumplir con lo primero y fallar en lo segundo.

El éxito de una arquitectura se mide por la decisión que genera y la información que transmite; el número de comprobaciones que incluye no es lo más importante. En los programas mejor gestionados, los equipos de fraude, crédito, registro y cumplimiento consultan el mismo perfil de riesgo del cliente, y cada decisión sirve para enriquecerlo. Ese es el estándar de referencia que utilizamos en esta guía.

Lo que debe detectar la arquitectura de prevención

Existen cuatro tipos de solicitantes que logran superar un proceso de registro débil, y cada uno de ellos requiere una capa específica de protección en la arquitectura.

Identidades robadas. La persona es real y los datos son correctos, pero el solicitante no es quien dice ser. Los datos de las agencias de crédito y de identidad coincidirán, y por eso mismo no bastan por sí solos.

Identidades sintéticas. La Reserva Federal define el fraude de identidad sintética como "el uso de una combinación de información de identificación personal (PII) para fabricar una persona o entidad con el fin de cometer un acto fraudulento para obtener un beneficio personal o financiero". Como las piezas pueden ser reales, las comprobaciones que validan cada campo de forma aislada pueden dar por buena a una persona que no existe. La creación y detección de identidades sintéticas merece un análisis aparte; en esta guía solo abordaremos su lugar en la arquitectura.

Solicitudes manipuladas y de primera persona. El solicitante es real y es quien dice ser, pero miente sobre sus ingresos, empleo o intenciones, o planea no pagar. Las comprobaciones de identidad no sirven de nada aquí, por lo que el fraude de primera persona necesita sus propias señales: la coherencia interna de la solicitud y el comportamiento de la cuenta una vez abierta.

Cuentas mula e intención de movimiento de dinero. La cuenta se utiliza para mover dinero, a veces abierta por un participante voluntario con su propio nombre. El fraude suele detectarse en las primeras transacciones, no en la solicitud. Para el defraudador, estos cuatro casos forman parte de un mismo proceso (desde la identidad hasta el dispositivo, pasando por las cuentas vinculadas y los fondos), mientras que la entidad financiera suele verlos a través de sistemas aislados.

Las capas de una arquitectura de prevención y lo que cada una pasa por alto

Cada capa de la arquitectura responde bien a una pregunta concreta, pero no detecta otros problemas. La siguiente tabla las compara detalladamente.

Las primeras cuatro capas generan señales; solo las dos últimas toman decisiones, y la arquitectura es tan buena como lo sean estas dos últimas.

Los datos de identidad y el buró de crédito son la base para verificar la identidad: ¿coinciden este nombre, fecha de nacimiento, dirección e identificación? Para saber más sobre esta fase, consulte la sección sobre detección de fraude en procesos KYC.

Aquí es donde las arquitecturas suelen empezar a fragmentarse. Un banco estadounidense nos explicó que utilizaba un proveedor para verificar el teléfono y el correo electrónico, y otro distinto para el nombre, la fecha de nacimiento y la dirección. Cada respuesta puede ser correcta de forma aislada, pero ningún sistema tiene una visión completa del solicitante.

La verificación de documentos y selfi confirma que un documento es auténtico y que la persona que lo presenta es su titular. Es una medida eficaz contra el robo de identidad, pero poco útil contra una identidad sintética que use un documento real. Además, es el paso que genera más fricción para el usuario, por lo que debe aplicarse solo cuando se supere cierto umbral de riesgo, en lugar de exigirse a todos los solicitantes. El software de verificación de identidad suele cubrir esta capa y la anterior, y el resto de la arquitectura debe estructurarse en torno a ellas.

Las señales de dispositivo y comportamiento analizan la sesión en lugar de la identidad: el dispositivo que se usa, cómo se rellena el formulario, o si el comportamiento se parece al de un usuario real que se registra por primera vez o al de alguien que ya lo ha hecho muchas veces. Detectan lo que los datos de identidad pasan por alto, pero no aportan información sobre el historial de esa identidad.

Las señales de red y relaciones analizan si el solicitante está conectado con otros de formas que no serían habituales en personas reales. La Reserva Federal de Boston recomienda analizar "relaciones más amplias que la simple suma de unos pocos datos", como la antigüedad del correo electrónico, el tiempo que lleva activo el teléfono, las conexiones sociales y las afiliaciones institucionales. Las personas reales desarrollan esta red con el tiempo; las identidades falsas, no.

La capa de decisiones y políticas traduce todas las señales en un único resultado. La revisión de casos es el destino de los casos dudosos, y solo funciona si la alerta llega con contexto: qué dispositivo y sesión se han usado, qué elementos están vinculados a la identidad y por qué se marcó como sospechosa. Una alerta que solo indica que "algo es inusual" no le da al analista información suficiente para decidir.

Muchas entidades operan con mucho menos que esto. Un equipo de delitos financieros de un banco comunitario estadounidense nos explicó que las comprobaciones de identidad pasaban por su proveedor principal, que utilizaban un control de pasaportes independiente para solicitantes internacionales y que no tenían ninguna otra herramienta contra el fraude en cuentas nuevas, siendo el monitoreo de sesiones y pagos en tiempo real "casi inexistente".

Por qué añadir más proveedores de verificación rara vez mejora la decisión

Cuando el fraude se cuela durante el registro, la reacción habitual es contratar otra herramienta de verificación. Sin embargo, rara vez ayuda tanto como se espera por cuatro razones:

Cada proveedor requiere una integración que sus ingenieros deben mantener. El responsable técnico de plataformas de fraude e identidad de un gran banco regional de EE. UU. lo resumió claramente: "Las aplicaciones de algunos proveedores se integran sin problemas. Otras no. Hemos tenido casos en los que nos dimos cuenta de que algo no encajaba bien, tuvimos que descartarlo y buscar otra opción". Firmar el contrato es la parte más sencilla de añadir un proveedor.

Los flujos de verificación en cascada fallan en producción. El director de cumplimiento de un neobanco para pequeñas empresas nos contó que tardó meses en diseñar un flujo en cascada entre varios proveedores de verificación: si el primero no confirmaba los datos, se llamaba al segundo. Cuando una parte del proceso de registro fallaba, un ingeniero tenía que intervenir y todas las solicitudes pasaban a revisión manual. Con el equipo de ingeniería ya saturado, optimizar la arquitectura de riesgo siempre quedaba relegado en la lista de prioridades.

La fricción acumulada frustra al usuario. El mismo director describió el impacto en los usuarios: "Afecta enormemente a la experiencia del cliente... Vivimos en un mundo que busca la satisfacción inmediata, y ahora resulta que el proceso va a tardar horas". Cada paso adicional es una oportunidad para que un buen cliente abandone el proceso.

Una segunda respuesta a la misma pregunta genera costes sin aportar valor. Si un nuevo proveedor confirma lo que uno existente ya ha validado, la decisión final no cambia. Un responsable de riesgos de un banco regional estadounidense resumió el resultado: "No me gusta tener demasiados proveedores vinculados a un solo proceso".

Unifique las herramientas en una sola decisión

La unificación consiste en que las herramientas que ya tiene alimenten una sola decisión, en un orden lógico y bajo una política que controle el equipo de riesgos. En la práctica, esto se resume en cuatro pasos:

1. Realice comprobaciones pasivas y de bajo coste a todos los usuarios. Los datos de identidad, las señales de dispositivo y comportamiento, y las señales de red no molestan al solicitante y pueden aplicarse a cada solicitud.

2. Exija pasos adicionales solo cuando el nivel de riesgo lo justifique. Solicite la verificación de documentos y selfis, o fuentes de datos adicionales, únicamente si las señales pasivas generan dudas reales. Exigir todos los requisitos a todo el mundo dispara el abandono. En una plataforma de préstamos, a los solicitantes que se desviaban del proceso rápido se les obligaba a pasar por todas las páginas de documentos adicionales, incluso cuando ya se tenían los datos necesarios para decidir, lo que provocaba que "la gente abandonara el proceso en masa".

3. Deje que una sola capa de políticas tome la decisión. Cada señal debe alimentar una decisión única acompañada de sus motivos. La prueba de fuego es que estos motivos lleguen con claridad al analista que gestiona el caso, permitiéndole ver por qué una solicitud se aprobó, requirió pasos adicionales o se rechazó.

4. Ponga al equipo de riesgos a cargo de la política. Si para modificar una regla es necesario abrir una tarea para el equipo de ingeniería, la arquitectura de prevención deja de ser ágil. El equipo de riesgos debe tener autonomía para cambiar los umbrales y la lógica de verificación, así como para probar los cambios con solicitudes anteriores antes de aplicarlos en producción.

Para ver cómo se implementa esto en un único programa, consulte la sección sobre protección contra el fraude en la apertura de cuentas.

La decisión de registro debe acompañar al cliente

El riesgo evaluado durante el registro sigue siendo útil durante meses, que es precisamente cuando un defraudador suele empezar a mover dinero. Sin embargo, en muchas entidades, el equipo de registro detecta una identidad sospechosa pero esa señal nunca llega al sistema de monitoreo de transacciones o de cumplimiento porque los sistemas no comparten información. Un responsable de riesgos de una empresa de pagos nos describió casos de identidades sintéticas detectadas durante el registro que luego pasaban desapercibidas en otros departamentos debido a esta falta de conexión.

Para solucionar esto, la decisión tomada en el registro (y sus motivos) debe formar parte del expediente del cliente que consultará cualquier decisión posterior. El mismo responsable de unificación nos describió su objetivo: "Queremos lograr una integración real que comience con la apertura de la cuenta o la tarjeta de crédito, y que con el tiempo se convierta en una unificación completa para todos los controles de fraude". Evaluar cómo debe aplicarse esa puntuación de riesgo en pagos con tarjeta, transferencias ACH o transferencias electrónicas es un análisis independiente que vale la pena realizar.

Cómo evaluar una arquitectura de prevención o su próxima herramienta

Antes de añadir una nueva herramienta, o al revisar su arquitectura actual, plantee estas seis preguntas para cada control del proceso:

1. ¿Qué decisión cambia esta comprobación y a cuántos solicitantes afecta? Si la respuesta sincera es "rara vez" o "confirma lo que ya sabemos", esa comprobación no aporta valor real.

2. ¿Se aplica a todos los usuarios o solo cuando el nivel de riesgo lo justifica? Las comprobaciones complejas aplicadas a todos los solicitantes se traducen en clientes perdidos.

3. ¿Cuál es su coste en términos de integración, latencia y abandono? Calcule el tiempo de ingeniería necesario para conectarla y mantenerla, y qué ocurre con el proceso si falla.

4. ¿Puede el equipo de riesgos modificar la política que la utiliza y probar el cambio antes de aplicarlo? Un control que el equipo no puede ajustar se queda obsoleto rápidamente con la configuración inicial.

5. ¿Llega su resultado al monitoreo de las primeras transacciones de la cuenta? Una señal que se detiene tras el registro no ayuda cuando el dinero empieza a moverse.

6. ¿Cómo afecta a las aprobaciones? En la apertura de cuentas, un falso positivo equivale a perder un cliente. Mida tanto los buenos solicitantes aprobados como el fraude evitado.

Estas mismas preguntas se aplican a decisiones de plataforma más amplias. Nuestra guía para evaluar software de prevención de fraude detalla los criterios generales, y los requisitos de una plataforma de prevención de fraude en tiempo real van mucho más allá del proceso de registro.

Dónde encaja Oscilar

Oscilar es una plataforma unificada: arquitectura de datos en tiempo real, inteligencia de comportamiento y dispositivos, reglas de decisión y gestión de casos en un solo lugar, con agentes nativos integrados. En la apertura de cuentas, esto significa que los controles que ya realiza alimentan una única decisión gestionada por el equipo de riesgos, y el resultado permanece en el expediente del cliente para cualquier análisis futuro. La evaluación se realiza mediante pruebas retrospectivas con sus alertas históricas y un modo simulación en su flujo de producción, con un informe final detallado. Diseñada con un registro de auditoría completo y justificación de decisiones en cada paso, mantiene siempre el criterio humano como prioridad.

Preguntas frecuentes

¿Qué es el fraude en la apertura de cuentas?

Es la apertura de una cuenta utilizando una identidad robada, inventada o falsa, o con la intención de hacer un uso indebido de ella una vez activa. También se le conoce como fraude de cuenta nueva o fraude de solicitud. La cuenta suele ser un medio para un fin: un préstamo que no se pagará, una tarjeta al límite o una vía para mover fondos de origen ilícito.

¿Qué herramientas necesita un banco para prevenir el fraude en la apertura de cuentas?

Un banco necesita comprobaciones de datos de identidad y buró de crédito, verificación de documentos y selfi para casos de riesgo, señales de dispositivo y comportamiento, así como señales de red y relaciones. También requiere una capa de decisiones que combine todo en un único resultado y un proceso de revisión de casos dudosos. La capa de decisión es la más importante, ya que define qué controles se activan y qué significan sus resultados.

¿Añadir más proveedores de verificación de identidad reduce el fraude en cuentas nuevas?

No por sí solo. Un proveedor que responde a una pregunta que ya tiene respuesta solo añade trabajo de integración, latencia y fricción para el usuario sin cambiar la decisión final. Más proveedores solo ayudan si cada uno cubre un vacío real de información y alimenta una única capa de decisión en lugar de crear una cadena de controles independientes de aprobado o rechazado.

¿Cómo se comparan las herramientas de prevención de fraude en cuentas nuevas?

Compárelas por el impacto real que tienen en la decisión final y no solo por su lista de funciones. Analice si la herramienta se aplica a todos los usuarios o solo según el riesgo, su coste de integración y abandono, si el equipo de riesgos puede ajustar y probar la política de uso, y si los resultados se comparten con el monitoreo posterior al registro. Mida los buenos solicitantes aprobados junto con el fraude evitado.

¿Cómo se integra la prevención de fraude en cuentas nuevas en el proceso de registro?

Realice comprobaciones pasivas (como datos de identidad y señales de dispositivo y comportamiento) a todos los solicitantes, y recurra a comprobaciones complejas (como verificación de documentos y selfi) solo cuando el riesgo lo justifique. Centralice todas las señales en una única capa de políticas que controle el equipo de riesgos. Por último, traslade la decisión de registro al monitoreo de transacciones para evaluar la actividad inicial de la cuenta con el contexto adecuado.

¿Cómo pueden los equipos reducir los falsos positivos sin aumentar las pérdidas por fraude?

Aplique pasos adicionales según el nivel de riesgo en lugar de exigir todas las comprobaciones a todo el mundo, y asegúrese de que cada decisión incluya los motivos para que los analistas puedan comprenderla. Pruebe los cambios de política con solicitudes anteriores antes de aplicarlos en producción y continúe ajustando las reglas. En la apertura de cuentas, un falso positivo es un cliente perdido, por lo que es fundamental medir tanto las aprobaciones de buenos solicitantes como el fraude detectado.

Si está valorando la próxima mejora para su proceso de registro, empiece por analizar la decisión que desea optimizar. Conozca cómo Oscilar aborda el fraude en la apertura de cuentas y, si desea analizarlo adaptado a su propio flujo de trabajo, puede solicitar una demostración desde esa página.