El mejor software de incorporación para bancos: 8 criterios a tener en cuenta

Última actualización: septiembre de 2026

El mejor software de incorporación para bancos es la capa que gestiona las verificaciones de identidad del banco, en lugar de una de las verificaciones individuales. Orquesta a los proveedores de KYC, KYB y verificación de identidad que el banco ya utiliza, eleva el nivel de verificación de cada solicitante a más controles solo cuando su riesgo lo justifica, lo reduce cuando no es así, y toma y explica cada decisión de incorporación. Envía a un revisor solo las solicitudes que no puede decidir por sí mismo, con el contexto necesario para resolverlas, y deja un registro que un inspector puede auditar. La forma más fiable de diferenciar los productos en estos puntos es probarlos con sus propias solicitudes anteriores antes de firmar.

Esta guía establece ocho criterios para elegir un software de incorporación, cada uno con las preguntas que debe hacer a un proveedor y cómo es una respuesta débil, seguido de una prueba para realizar con sus propias solicitudes y una plantilla de evaluación para reutilizar.

Resumen rápido

• Elija el software de incorporación que orqueste a sus proveedores actuales, ajuste el nivel de verificación de los solicitantes según el riesgo, decida y explique cada solicitud, y mantenga la cola de revisión manual limitada a los casos que una persona realmente necesita ver.

• Evalúe las aprobaciones del software según lo que ocurra con las cuentas después, y no solo por la tasa de aprobación. La tasa de aprobación es una política que define el apetito de riesgo del banco.

• La norma del Programa de Identificación de Clientes (CIP) del banco, 31 CFR 1020.220, establece el mínimo que el registro debe evidenciar: nombre, fecha de nacimiento, dirección y un número de identificación obtenido antes de abrir la cuenta, con la identidad verificada bajo procedimientos basados en el riesgo.

• La supervisión sigue siendo responsabilidad del banco. La guía interinstitucional de junio de 2023 sobre relaciones con terceros está vigente y se propuso su sustitución el 11 de septiembre de 2026 (estado al 29 de septiembre de 2026), y el programa de terceros de un banco cubre tanto la plataforma como a cada proveedor que hay detrás de ella.

• Pruebe cada opción recreando sus propias solicitudes anteriores, y pruebe a un proveedor que nunca haya utilizado en vivo con una parte de su tráfico.

• Oscilar escribió esta lista y comercializa una plataforma de incorporación y riesgo. Los criterios no mencionan a ningún proveedor específico.

La respuesta corta: cómo debe elegir un banco su software de incorporación

Un banco debe elegir el software de incorporación que orqueste a sus proveedores de identidad, KYC y KYB en un solo flujo, ajuste los controles de cada solicitante según su riesgo, apruebe, rechace o derive cada solicitud con un motivo justificado, mantenga una cola de revisión manual pequeña y deje un registro de cada decisión listo para una inspección. La forma de confirmar estos puntos es pasar una muestra de sus propias solicitudes anteriores por cada software candidato antes de firmar, ya que una demostración muestra lo que el software puede hacer en general, pero sus solicitudes muestran lo que hace por usted.

El software de incorporación es fundamental porque una verificación de KYC responde a una pregunta más limitada que la que el banco debe decidir. Una verificación de KYC confirma que una identidad declarada existe y coincide con sus documentos en un momento dado. No establece la intención ni determina si la identidad no fue creada específicamente para superar el control. Decidir qué hacer con un solicitante que pasa la verificación es tarea del software de incorporación.

Oscilar redactó esta lista y comercializa una plataforma de riesgo e incorporación. Oscilar orquesta verificaciones de identidad, KYC y KYB de terceros, y no es un proveedor de datos o verificación por sí mismo. Los criterios que se detallan a continuación no mencionan proveedores ni productos específicos, y en una sección posterior se aplican estos mismos criterios a Oscilar.

Esta guía aborda la elección del software de incorporación en su conjunto. Para conocer las capas independientes de detección de fraude en la apertura de cuentas, y lo que cada capa puede y no puede detectar, lea nuestra guía sobre la estructura de prevención de fraude en la apertura de cuentas.

Qué hace el software de incorporación que no hace un solo proveedor de verificación

El software de incorporación es la capa de decisión y orquestación en la apertura de cuentas. Decide qué controles aplicar a cada solicitante, con qué proveedor, en qué orden y qué hacer con los resultados. Un proveedor de KYC, KYB o verificación de identidad (IDV) responde a una sola pregunta sobre un solicitante, como si un nombre, fecha de nacimiento y dirección coinciden, o si un documento es auténtico. El software de incorporación combina esas respuestas con los datos y la política del banco para tomar una decisión sobre la solicitud.

Un solicitante que supera todos los controles aún puede ser un defraudador. Un director sénior de gestión de riesgos de fraude de una empresa de pagos describió a un empleador anterior que dejaba de lado los resultados de KYC y KYB en sus modelos: "Incluso en mi experiencia anterior, no utilizábamos a ningún proveedor de KYC o KYB en nuestros modelos porque teníamos demasiados casos en los que los defraudadores simplemente superaban sin problemas todos los controles de KYC/KYB". Los controles siguen siendo importantes, pero la decisión sobre un solicitante que los supera debe provenir de la capa superior.

En la práctica, el software de incorporación se encarga de cinco tareas que ningún proveedor de verificación cubre por sí solo:

• Orquestación: llamar a cada proveedor en el orden definido por el banco y gestionar los casos en los que un proveedor falla o supera el tiempo de espera.

• Flujo basado en el riesgo: aumentar los controles de un solicitante o reducirlos en función de su nivel de riesgo.

• Decisión: aprobar, rechazar, elevar controles o derivar cada solicitud, adjuntando el motivo.

• Revisión: una cola y una vista de caso para las solicitudes que una persona debe decidir manualmente.

• Registro: qué se verificó, a través de qué proveedor, qué se decidió y por qué.

Algunos de los controles que ejecuta el software de incorporación requieren contrataciones independientes. Elegir un proveedor de KYB para las verificaciones comerciales es una evaluación aparte con sus propios criterios, al igual que elegir un proveedor de verificación de identidad por sí solo. Cuando las identidades sintéticas son el riesgo principal, evaluar el software de detección de fraude de identidad sintética es un ejercicio independiente. Lo mismo ocurre al evaluar herramientas de detección de deepfakes cuando el riesgo son selfies y vídeos manipulados.

Si todavía está definiendo su enfoque estratégico general, incluido el recorrido del solicitante en la apertura de cuentas, empiece con nuestra guía sobre estrategia de incorporación en bancos digitales. Esta guía asume que ese enfoque ya está definido y se centra en el software necesario para ejecutarlo.

Los ocho criterios y cómo utilizarlos

Los ocho criterios siguen el recorrido de una solicitud durante la incorporación: orquestar los controles, aumentar o reducir el nivel de verificación del solicitante, tomar la decisión, gestionar las excepciones, trabajar en la cola de revisión, cambiar políticas, mantener el registro y adaptarse a los sistemas y la supervisión del banco. Cada criterio tiene las mismas tres partes: en qué consiste, qué preguntar al proveedor y cómo es una respuesta débil.

Haga las mismas preguntas por escrito a todos los proveedores y pruebe cada respuesta con sus propias solicitudes anteriores en lugar de con datos de demostración. Es fundamental acertar en la elección a la primera, ya que el software de incorporación abarca todo el flujo de apertura de cuentas y es costoso de reemplazar. El líder de un equipo de producto en una empresa de pagos comentó que querían estar seguros antes de elegir "porque es una integración enorme y una iniciativa muy grande".

1. Orquesta a sus proveedores en lugar de reemplazarlos

En qué consiste: La orquestación es la capacidad del software para llamar a los proveedores que el banco ya utiliza, en el orden que este decida, y unificar sus respuestas en un solo flujo. Los bancos ya dividen los controles de identidad entre distintos proveedores: un banco describió el uso de un proveedor para verificar el teléfono y el correo electrónico, y otro diferente para el nombre, la fecha de nacimiento y la dirección. Un líder tecnológico de un banco comunitario señaló que las herramientas de verificación solían ser cajas negras, y que lo que buscan ahora es un flujo configurable en el que puedan integrar cualquier fuente de datos que necesiten consultar durante el proceso de KYC. Un vicepresidente sénior de estrategia contra delitos financieros de un gran banco regional comentó que esperaban una capa de orquestación donde se pudieran conectar muchos proveedores de verificación y cambiar las reglas rápidamente.

La orquestación incluye la cascada (cascading), donde el software llama a un segundo proveedor solo cuando el primero no puede verificar al solicitante. Un director sénior de analítica de decisiones de riesgo en una empresa de pagos buscaba un proveedor que se situara al final de una cascada de dos o tres, llamando a cada uno solo cuando el anterior fallaba, para aumentar la proporción de solicitantes verificados sin intervención humana. Desarrollar esto manualmente es lento y complejo. Un director de cumplimiento en un neobanco para pequeñas empresas describió que pasaron meses intentando crear un flujo en cascada entre socios de verificación, y el día en que parte del flujo de incorporación falló, un ingeniero tuvo que intervenir y todas las solicitudes pasaron a revisión manual.

La tasa de aprobación depende tanto de los datos que envía el banco como del proveedor al que se envían. El mismo director sénior de analítica de decisiones de riesgo señaló que, en una ocasión, una tasa de aprobación muy baja se debió a la mala calidad de los datos enviados y no al proveedor. Un software que muestre qué campos se enviaron a qué proveedor y qué se recibió de vuelta permite al banco distinguir estas dos causas.

El objetivo de la orquestación es tomar una mejor decisión, independientemente del número de proveedores. Un líder de riesgo de un banco regional comentó: "No me gusta tener demasiados proveedores asociados a un único proceso". Por otro lado, un vicepresidente de riesgo de pagos, cumplimiento y operaciones en una empresa de pagos sopesó la otra perspectiva: "No quiero limitar el número de proveedores solo por una preocupación de cumplimiento y luego comprometer la calidad de nuestras decisiones, ¿verdad?". La orquestación resuelve esta tensión al aplicar una única decisión sobre todos los proveedores que el banco necesite.

Qué preguntar a un proveedor:

• Configure nuestro flujo actual en su software, incluyendo a nuestros proveedores actuales. ¿A cuáles de ellos puede llamar hoy mismo y cómo se añade uno nuevo?

• ¿Puede nuestro equipo cambiar el orden de los proveedores o añadir un paso en cascada sin necesidad de un desarrollo de ingeniería?

• Cuando un proveedor supera el tiempo de espera o no está disponible, ¿qué ocurre con la solicitud en proceso?

• Para cada solicitud, ¿podemos ver qué campos se enviaron a qué proveedor y qué devolvió cada uno?

Cómo es una respuesta débil: Un flujo fijo estructurado en torno a las propias verificaciones del proveedor, donde añadir o reordenar un proveedor requiere un proyecto de servicios profesionales. Una tasa de aprobación citada sin mostrar los datos que la generaron es otra señal de alerta.

2. Ajusta el nivel de verificación de los solicitantes según el riesgo, en ambas direcciones

En qué consiste: El ajuste dinámico según el riesgo significa que el software añade controles cuando el riesgo de un solicitante lo requiere y elimina fricciones cuando no es necesario. El detonante es el riesgo, que puede aparecer tanto después de que una verificación se apruebe como cuando falla. El director sénior de gestión de riesgos de fraude mencionado anteriormente comentó: "Querría activar un control adicional cuando tenga dudas de fraude en la incorporación, el beneficiario o la verificación del propietario, incluso si superan el KYC".

Las propias verificaciones deben adaptarse según el solicitante. Un director de producto técnico que lideraba el rediseño de KYB en una empresa de pagos describió este requisito: "Necesitamos que el flujo de verificación sea dinámico. Por ejemplo, queremos crear diferentes plantillas de verificación según el sector, el nivel de riesgo, el país u otros parámetros. En función de estos parámetros, deberíamos poder activar una plantilla de verificación específica con un conjunto concreto de campos o controles".

Este ajuste dinámico también funciona en sentido contrario. Un director sénior de analítica de fraude en una entidad de crédito al consumo señaló: "Creo que si pudiéramos identificar solicitudes de muy bajo riesgo a las que reducir la fricción desde el punto de vista de la autenticación, eso nos ayudaría mucho". Los controles estrictos generalizados tienen un coste. En una plataforma de préstamos, los solicitantes que no cumplían los requisitos para una vía rápida tenían que pasar por todas las páginas de condiciones, incluso cuando los datos para decidir ya estaban disponibles, lo que provocó que muchos de ellos abandonaran el proceso.

Un control adicional es tanto un estado en el flujo como una verificación extra. El director de analítica de decisiones de riesgo citado en el criterio 1 señaló que una vez que se le pide a un solicitante un control de documento y selfie, el resto del flujo debe pausarse hasta que lo complete, ya que ejecutar los controles restantes no tiene sentido si el solicitante nunca hace clic en el enlace.

Siempre habrá clientes legítimos a los que se les pedirán controles adicionales. Un responsable de riesgo de fraude de tarjetas en una entidad de crédito al consumo admitió que "inevitablemente habrá ocasiones en las que tengamos que pedir controles adicionales a clientes legítimos", por lo que el proceso debe ser fácil de completar. El director sénior de gestión de riesgos de fraude de una empresa de pagos describió el objetivo: "Buscamos que esta experiencia sea fluida, que es una mejor palabra que sin fricciones, porque sí hay fricción, pero debe ser fluida en el sentido de lo fácil que resulta para el usuario completarla".

Los controles por capas y basados en el riesgo son lo que respalda la guía de 2021 del FFIEC, "Autenticación y acceso a servicios y sistemas de instituciones financieras". La guía señala: "La seguridad por capas incorpora múltiples controles preventivos, de detección y correctivos, y está diseñada para compensar las posibles debilidades de cualquier control individual". También espera que una evaluación de riesgos respalde las decisiones sobre las técnicas de autenticación.

Qué preguntar a un proveedor:

• Muestre un ejemplo de un solicitante que superó el KYC pero al que se le aplicaron controles adicionales por otra señal de riesgo, y un solicitante de bajo riesgo que se saltó un paso.

• ¿En qué punto se pausa el flujo mientras un solicitante completa un control adicional y qué ocurre si el solicitante nunca regresa?

• ¿Podemos definir diferentes rutas de verificación por producto, tipo de solicitante o nivel de riesgo sin necesidad de desarrollo técnico?

• Pase nuestras solicitudes anteriores por su política predeterminada. ¿A quiénes les habría aplicado controles adicionales y por qué?

Cómo es una respuesta débil: Controles adicionales que solo se activan cuando falla una verificación, o los mismos pasos adicionales para todos los solicitantes que no entran en la vía rápida. Un control adicional que reinicia la solicitud es otra señal de alerta, porque significa que el flujo no detecta en qué punto del proceso se encuentra el solicitante.

3. Toma la decisión, y usted la evalúa por la calidad de las aprobaciones

En qué consiste: La decisión de incorporación es el resultado que genera el software para cada solicitud: aprobar, rechazar, aplicar controles adicionales o derivar a revisión manual, detallando el motivo. Un software que solo transmite los resultados del proveedor obliga al equipo del banco a tomar cada decisión de forma manual. La prueba práctica de la explicabilidad es si cada decisión incluye códigos de motivo y atributos que el analista que revisa el caso, y posteriormente el registro, puedan interpretar fácilmente.

Evalúe estas decisiones por la calidad de las aprobaciones y no solo por la tasa de aprobación. El director sénior de gestión de riesgos de fraude de una empresa de pagos comentó: "Definitivamente queremos optimizar no necesariamente solo las tasas de aprobación, sino también la calidad de esas aprobaciones". Una tasa de verificación alta puede deberse a una definición muy laxa de lo que se considera verificado, por lo que debe preguntar cómo define cada proveedor del flujo una verificación exitosa y hacer un seguimiento de las cuentas aprobadas para ver qué ocurrió con ellas.

La propia tasa de aprobación la define el apetito de riesgo del banco. Un vicepresidente de transformación de riesgos en un adquirente de comercios señaló: "Eso es realmente una cuestión de política, ¿verdad? ... Es el apetito de riesgo. Aceptamos esto y aquello; si los comercios se desvían de eso, su tasa de aprobación será la que deba ser". Un proveedor que promete una tasa de aprobación más alta sin preguntar sobre el apetito de riesgo del banco está describiendo una política más laxa.

Qué preguntar a un proveedor:

• Para una muestra de nuestras solicitudes, muestre cada decisión y los motivos de la misma, tal como los vería un analista de revisión.

• ¿Cómo define cada proveedor del flujo una verificación válida y podemos ver la evidencia que respalda cada resultado?

• ¿Podemos hacer un seguimiento de las cuentas aprobadas después de la incorporación, por segmentos, para ver cuáles resultaron ser fraude más adelante?

• ¿Qué decisiones toma el software y cuáles deja en manos de nuestro equipo?

Cómo es una respuesta débil: Una puntuación única o un indicador de aprobado/rechazado sin motivos explicativos. Una tasa de aprobación presentada como una funcionalidad del producto es otra señal de alerta, porque la tasa es una política que define el banco.

4. Gestiona las excepciones sin enviar todo a revisión manual

En qué consiste: La gestión de excepciones es lo que hace el software con una solicitud que no supera los controles limpiamente, y no todos los fallos deben terminar en la cola de revisión manual. Un responsable de riesgos en una empresa de remesas señaló: "Para los fallos de verificación de identidad (IDV), no los envíe a revisión manual. Porque incluso si lo hace, no hay nada que podamos hacer al respecto. En ese caso, se le debería pedir al cliente que lo intente de nuevo".

Algunas excepciones parecen idénticas en la superficie pero necesitan rutas que las diferencien. El director de gestión de riesgos de fraude de una empresa de pagos mencionó que cuando una agencia de informes de crédito no devuelve información sobre un solicitante, este puede ser un cliente legítimo con un historial crediticio limitado (thin-file), alguien joven, un recién llegado al país, o bien alguien que introdujo un nombre y fecha de nacimiento ficticios pero con apariencia real. El resultado de "sin coincidencias" es el mismo para ambos casos, por lo que el software debería derivarlo a controles adicionales que puedan diferenciarlos, en lugar de aprobar o rechazar basándose únicamente en ese resultado.

Qué preguntar a un proveedor:

• ¿Qué fallos hacen que el solicitante vuelva a intentarlo en el momento y cuáles se derivan a una persona? ¿Puede nuestro equipo modificar esa división?

• Muestre la ruta para un solicitante sin historial de crédito en agencias, tanto para un cliente legítimo con historial limitado como para una identidad falsa.

• Cuando un proveedor devuelve un error en lugar de un resultado, ¿qué ve el solicitante?

Cómo es una respuesta débil: Cada fallo se deriva a revisión manual, o cada resultado sin coincidencias se rechaza. Lo primero traslada el coste de cada excepción al personal de revisión, y lo segundo penaliza a los solicitantes legítimos.

5. Ofrece una cola de revisión que su equipo pueda gestionar

En qué consiste: La cola de revisión es el conjunto de solicitudes que el software no puede decidir por sí mismo y envía a una persona. Su volumen y el tiempo que requiere cada caso determinan cuántas personas se necesitan para la incorporación y cuánto tiempo deben esperar los solicitantes legítimos. Un director sénior de analítica de fraude en una entidad de crédito al consumo describió el impacto: "En nuestro proceso de revisión manual, pausamos las solicitudes en tiempo real, ¿verdad? Y esto afecta nuestra tasa de conversión en todas las solicitudes que revisamos manualmente, porque no trabajamos los domingos".

El analista de revisión debe ver todo lo necesario para decidir en una sola pantalla, junto con el motivo por el cual se creó el caso. El mismo director señaló que la entidad no había automatizado más procesos porque sus fuentes de datos están aisladas e independientes entre sí, por lo que un analista debe consultar varios sistemas para resolver una sola solicitud. Un software que unifica el resultado de cada proveedor, los datos del propio banco y el motivo de la derivación en un solo caso elimina ese problema.

La aplicación coherente de las políticas es una de las razones para permitir que el software tome las decisiones que pueda. Un vicepresidente de transformación de riesgos en un adquirente de comercios comentó: "Los humanos somos inconsistentes al aplicar las políticas, ¿verdad? ... Puedo estar cansado un miércoles o tener resaca un viernes, ¿no? Y ahí es probablemente donde logramos un pequeño margen de mejora al tener esa consistencia".

Qué preguntar a un proveedor:

• Para nuestra muestra de datos, ¿cuántas solicitudes se enviarían a revisión y por qué motivos?

• Muestre un caso de revisión. ¿Muestra el resultado de cada proveedor, nuestros propios datos y el motivo de la creación del caso en un solo lugar?

• ¿Cómo se priorizan los casos y qué ocurre con las solicitudes pausadas fuera del horario laboral?

• Cuando un analista anula la decisión del software, ¿dónde se registra esto y cómo puede nuestro equipo de riesgo utilizarlo para ajustar la política?

Cómo es una respuesta débil: Una cola que enumera las solicitudes únicamente con una puntuación, obligando al revisor a abrir el portal de cada proveedor. Un volumen de revisión que nadie puede estimar antes de la puesta en marcha es otra señal de alerta.

6. Su equipo de riesgos puede cambiar las políticas y probar los cambios primero

En qué consiste: El control de políticas define quién puede cambiar las reglas de incorporación, con qué rapidez y qué pruebas respaldan que el cambio funcionará. Si cada cambio requiere una solicitud al equipo de ingeniería, el flujo se queda atrás respecto al fraude que debe detener, y los equipos de riesgo dejan de proponer mejoras. El equipo de riesgos debería poder cambiar una regla, un umbral o una ruta de controles adicionales por sí mismo, dentro de los controles de seguridad que establezca el banco.

Cada cambio debe probarse antes de entrar en producción. El backtesting recrea solicitudes históricas a través de la política propuesta para mostrar qué decisiones habría tomado. Una prueba A/B ejecuta la nueva política en una parte del tráfico real junto a la actual, mostrando su rendimiento con solicitantes que los datos históricos no cubren.

Qué preguntar a un proveedor:

• ¿Quién de nuestro equipo puede modificar una regla y qué aprobación requiere el cambio?

• Muestre un cambio de política probado con nuestras solicitudes históricas, indicando qué decisiones habrían cambiado.

• ¿Podemos aplicar un cambio en una parte de nuestro tráfico real junto a la política actual antes de implementarlo por completo?

• ¿Cómo se gestionan las versiones de cada cambio y podemos ver qué versión de la política decidió cada solicitud?

Cómo es una respuesta débil: Cambios de política que deben solicitarse al proveedor o que solo se pueden probar una vez que están en producción.

7. Deja el registro detallado que un inspector solicitará

En qué consiste: El registro de auditoría es la evidencia, para cada solicitud, de lo que se verificó, a través de qué proveedor, qué decidió el software y por qué, y quién modificó la decisión. El nivel mínimo que debe documentar es la norma del Programa de Identificación de Clientes (CIP) de los bancos, 31 CFR 1020.220, que exige obtener como mínimo, antes de abrir una cuenta, el nombre del cliente, fecha de nacimiento (para personas físicas), dirección y un número de identificación, y verificar la identidad mediante procedimientos basados en el riesgo. Un responsable de riesgo y cumplimiento de una entidad de crédito hipotecario describió esta necesidad en términos de gobernanza: "también está la parte de gobernanza que es muy importante, en cuanto a cómo se tiene la supervisión de las decisiones y las pruebas, y cómo se entregan esas pruebas al regulador".

El origen de cada dato recopilado ahora forma parte del registro. Bajo dos órdenes de exención (de la OCC, la FDIC y la NCUA el 27 de junio de 2025, y de la Junta de la Reserva Federal el 31 de julio de 2025, ambas con la conformidad del FinCEN), los bancos regulados por estas agencias pueden obtener el TIN de un cliente a través de un tercero en lugar de pedírselo directamente al cliente. Esta medida es opcional, y el banco aún debe obtener el TIN antes de abrir la cuenta bajo procedimientos escritos basados en el riesgo, por lo que el software debe registrar el origen de cada dato de identificación.

El registro debe poder recuperarse directamente sin tener que solicitarlo a soporte. Un director de control de calidad de cumplimiento de la BSA en un banco patrocinador, cuyos socios fintech recopilan datos y documentos durante la incorporación, se preguntó: "¿Cómo nos aseguramos de estar cómodos no solo con los datos que recopilan, sino también con la documentación que obtienen?". Para un banco que realiza la incorporación a través de socios, el software debe guardar ese registro donde el banco pueda visualizarlo.

Para solicitantes empresariales, el registro también incluye la titularidad real. Bajo la norma de debida diligencia de clientes (CDD) del FinCEN, 31 CFR 1010.230, el banco debe identificar a cada persona física que posea el 25 % o más de las participaciones de una persona jurídica, además de una persona con responsabilidad significativa para controlar, gestionar o dirigir la entidad, y verificar sus identidades bajo procedimientos basados en el riesgo. La forma en que un proveedor de KYB identifica a estos propietarios corresponde a la evaluación de ese proveedor específico, que es un proceso independiente.

El registro respalda el programa de KYC del banco sin reemplazarlo. Para el programa en sí, lea nuestra guía sobre cómo crear un programa de cumplimiento de KYC.

Lo que el registro debe mostrar para cada solicitud:

• La información de identificación recopilada y el origen de cada dato, incluido cualquier TIN obtenido de un tercero.

• Cada control ejecutado, indicando el proveedor, los campos enviados y el resultado devuelto.

• La decisión tomada, la versión de la política que la generó y los motivos subyacentes.

• Cualquier control adicional aplicado y qué completó el solicitante.

• Cualquier revisión manual, quién tomó la decisión, por qué y si se anuló la decisión del software.

• Para solicitantes empresariales, los titulares reales identificados y cómo se verificó a cada uno.

Qué preguntar a un proveedor:

• Extraiga el registro completo de una solicitud decidida hace meses, sin necesidad de abrir un ticket de soporte.

• ¿Podemos exportar el registro en un formato que un inspector pueda consultar sin necesidad de utilizar su software?

• Para las solicitudes incorporadas a través de un socio, ¿dónde se guardan los datos y documentos del socio, y podemos visualizarlos?

Cómo es una respuesta débil: Un indicador de aprobado/rechazado para cada control, con los detalles guardados únicamente en los registros del proveedor, o un registro al que el banco solo puede acceder mediante una solicitud formal.

8. Se adapta a su infraestructura tecnológica, contratos y programa de supervisión

En qué consiste: La adaptación evalúa si el software se integra con los sistemas, los contratos de proveedores y la supervisión que el banco ya tiene implementados. El software debe conectarse a los sistemas centrales del banco (core bancario), a sus propios datos y a sus proveedores existentes, sin obligar al banco a cambiar de plataforma. Un director de producto de un gran banco describió la propuesta de un proveedor: "Básicamente nos dijeron: 'bueno, si reestructuran todo su backend y vuelcan todo en nuestra plataforma, entonces hará milagros'. Y yo pensé: 'eso está muy bien, pero nunca lo haremos'".

Cambiar un proveedor no debería implicar rediseñar todo el flujo. Un responsable técnico de producto para plataformas de fraude e identidad de un gran banco regional comentó: "Las aplicaciones de algunos proveedores son muy fluidas. Otras pueden no integrarse bien. Hemos tenido situaciones en las que nos dimos cuenta de que algo no se integraba de forma óptima, tuvimos que descartarlo y pasar a otra opción". Un software que trata a cada proveedor como un paso modular y reemplazable permite al banco prescindir de uno sin afectar al resto.

Los contratos con los proveedores también forman parte de la adaptación. Un gestor de alianzas en una fintech de banca comercial preguntó si podía consultar datos a través de una plataforma manteniendo sus propios acuerdos comerciales con los distribuidores de datos, y un director de producto técnico que lideraba un rediseño de KYB en una empresa de pagos planteó: "¿Necesitamos contratos independientes con cada registro público, o solo un contrato con ustedes?". Ambos modelos pueden funcionar, siempre que el banco tenga claro cuál está firmando.

La supervisión sigue siendo responsabilidad del banco. Un responsable de cumplimiento de una empresa de pagos señaló que añadir una plataforma entre la institución y sus proveedores no traslada la responsabilidad de la supervisión, ya que el programa de gestión de terceros de la entidad aún debe cubrir tanto la plataforma como a cada proveedor externo que haya detrás de ella. La Guía Interinstitucional sobre Relaciones con Terceros: Gestión de Riesgos de junio de 2023 está vigente y las agencias OCC, Reserva Federal, FDIC y NCUA propusieron su sustitución el 11 de septiembre de 2026; al 29 de septiembre de 2026, la sustitución es una propuesta abierta a comentarios hasta el 16 de noviembre de 2026. La propuesta enfatiza la necesidad de adaptar la gestión de riesgos de terceros al riesgo evaluado de cada relación y al tamaño y complejidad de la institución.

Qué preguntar a un proveedor:

• ¿A cuáles de nuestros sistemas y proveedores se conecta hoy en día y qué tendríamos que cambiar para empezar a operar?

• Si reemplazamos a un proveedor, ¿qué más debe cambiar en el flujo?

• ¿Podemos mantener nuestros propios contratos con los proveedores, comprar a través de ustedes o combinar ambas opciones?

• ¿Qué documentación facilitarán a nuestro equipo de gestión de riesgos para la debida diligencia sobre ustedes y sobre cada proveedor que los respalda?

Cómo es una respuesta débil: Un plan de implementación que comienza por exigir que mueva todos sus datos a la plataforma del proveedor. Un proveedor que considera que los servicios que subcontrata quedan fuera de la supervisión del banco es otra señal de alerta.

Cómo probar un software de incorporación con sus propias solicitudes

Para evaluar un software de incorporación, pase una muestra de sus solicitudes anteriores por cada sistema candidato y compare sus decisiones con lo que realmente ocurrió con esos solicitantes. El director sénior de gestión de riesgos de fraude de una empresa de pagos explicó por qué una demostración no es suficiente: "Siempre es agradable entrar en la web de un proveedor y ver todas las cosas bonitas que pueden hacer. Pero luego los pruebas y te preguntas: 'bueno, ¿qué es lo que realmente hacen?'".

1. Extraiga una muestra de solicitudes anteriores con resultados conocidos. Incluya fraudes confirmados, buenos clientes y solicitudes que se derivaron a revisión manual, de modo que la prueba cubra los casos clave que definen el valor del software.

2. Recree la muestra en cada software candidato de forma paralela a su flujo actual. Un responsable de prevención de blanqueo de capitales (AML) de una gestora de activos describió haber hecho esto con herramientas anteriores en un "entorno de pruebas temporal donde pudimos procesar algunos de nuestros datos antiguos y compararlos con las tasas de aprobación que teníamos con las herramientas anteriores".

3. Pruebe a un proveedor que nunca haya utilizado con una parte del tráfico real. Un nuevo proveedor no tiene un historial en sus datos para recrear. El director sénior de gestión de riesgos de fraude señaló: "Obviamente no puede ser un análisis retrospectivo. Por lo tanto, debe ser algo más cualitativo o algo que tengamos que conectar y evaluar mediante una prueba de tipo A/B/C".

4. Compare las decisiones, la tasa de controles adicionales, el volumen de revisión y la calidad de las aprobaciones. Evaluar únicamente la tasa de aprobación beneficia a los criterios de verificación laxos, por lo que debe hacer un seguimiento de las cuentas aprobadas en la muestra para ver cuáles resultaron en fraude.

5. Extraiga el registro de auditoría de un grupo de decisiones. Compruebe que un inspector podría reconstruir cada paso desde los datos recopilados, pasando por cada verificación, hasta la decisión final y cualquier intervención manual.

6. Modifique una regla de la política y mida cuánto tiempo se tarda en probarla y subirla a producción. Este ejercicio muestra quién puede realizar el cambio, si se puede realizar un backtesting previo y cuánto tiempo depende de la intervención de terceros.

Dónde encaja Oscilar, evaluado bajo estos mismos criterios

Oscilar redactó esta guía, por lo que esta sección aplica los ocho criterios a Oscilar basándose únicamente en lo que declaran sus páginas públicas oficiales. Oscilar no es un proveedor de datos o de verificación. Orquesta controles de identidad de terceros, KYC y KYB, junto con los datos propios de la institución financiera.

En cuanto a orquestación y controles adicionales (criterios 1 y 2), la página sobre incorporación de consumidores en Oscilar detalla la orquestación de controles de KYC y verificaciones de identidad avanzadas, conectando las bases de datos de la propia institución y fuentes de datos de terceros a través de un catálogo de socios. Oscilar añade inteligencia de dispositivos, biometría del comportamiento y enriquecimiento de datos a estas verificaciones, ejecuta flujos de incorporación que se adaptan al perfil de riesgo de cada solicitante y ofrece verificaciones adicionales que activan medidas de debida diligencia reforzada cuando es necesario. La incorporación de empresas funciona de la misma manera, aplicando controles de KYB en lugar de KYC.

Sobre la decisión, las excepciones y la cola de revisión (criterios 3, 4 y 5), Oscilar combina reglas, aprendizaje automático supervisado y detección de anomalías no supervisada. Su gestión de casos impulsada por IA prioriza los expedientes de incorporación, ofrece una visión integral de cada solicitante y explica en lenguaje sencillo por qué se creó cada caso de revisión.

En cuanto al cambio de políticas (criterio 6), el equipo de riesgos puede diseñar flujos de trabajo en una interfaz sin código o de código bajo (no-code/low-code), realizar backtesting de un nuevo flujo de incorporación con datos históricos antes de implementarlo, ejecutar pruebas A/B y monitorizar posteriormente los falsos positivos, las tasas de aprobación y sus propios indicadores clave de rendimiento (KPI). Oscilar también incluye una monitorización automática de modelos que analiza la desviación de datos (data drift), de características (feature drift) y de conceptos (concept drift), además de medir los KPI de resultados por segmentos.

Sobre el registro de auditoría para inspectores (criterio 7), Oscilar mantiene un registro completo por cada decisión con los motivos almacenados, diseñado para integrar la supervisión humana (human-in-the-loop). En cuanto a la adaptación (criterio 8), Oscilar es una plataforma única que abarca incorporación, crédito, fraude y AML, optimizada para tomar decisiones en menos de 100 milisegundos.

Oscilar no realiza verificaciones de documentos ni pruebas de vida (liveness) directamente. Estas comprobaciones provienen de los proveedores de verificación de identidad que orquesta, por lo que debe preguntar qué proveedor llamaría el flujo para cada verificación y realizar la prueba anterior en Oscilar con la misma muestra que los demás candidatos.

Oscilar fue incluida en la lista FCC50 de Chartis para 2026, su clasificación de proveedores de tecnología de cumplimiento y delitos financieros, ganando en las categorías de Personalización No-Code/Low-Code e Innovación en IA Agéntica. Oscilar es también Socio Preferente de Nacha para Validación de Cuentas, Monitorización de Fraude y Prevención de Riesgos y Fraude. Ninguna de estas distinciones sustituye la prueba de Oscilar con sus propias solicitudes reales.

Los ocho criterios de un vistazo

Esta tabla asocia cada criterio con la pregunta para evaluarlo, la respuesta que debería alertarle y la prueba a realizar con sus propias solicitudes. Complete esta información para cada proveedor de su lista de candidatos.

Preguntas frecuentes

¿Qué hace el software de incorporación bancaria que no haga un proveedor individual de KYC o verificación de identidad?

El software de incorporación toma la decisión sobre qué hacer con un solicitante, mientras que un proveedor de KYC o de verificación de identidad responde a una pregunta específica sobre ese solicitante. El software llama a cada proveedor en el orden que establezca el banco, ajusta los controles según el riesgo de forma dinámica y combina las respuestas con los datos y políticas del banco. Posteriormente aprueba, rechaza, aplica controles adicionales o deriva la solicitud con un motivo justificado, y guarda el registro de cada decisión.

¿Cuándo debería el software de incorporación aplicar controles adicionales a un solicitante?

El software de incorporación debe aplicar controles adicionales a un solicitante siempre que su nivel de riesgo lo justifique (incluso después de haber superado un control de KYC inicial) y no únicamente cuando falla una verificación. Del mismo modo, debe reducir la fricción para los solicitantes de menor riesgo. Mientras el solicitante completa un control adicional, el resto del flujo debe pausarse, y este paso extra debe ser sencillo de completar para un cliente legítimo.

¿Qué debe ocurrir con una solicitud que el software no puede decidir por sí mismo?

Una solicitud que el software no puede resolver debe enviarse a un analista de revisión con toda la información necesaria en una sola pantalla: el resultado de cada proveedor, los datos del propio banco y el motivo por el cual se derivó el caso. Un fallo en el control de selfie o de documentos suele resolverse mejor pidiendo al usuario que lo intente de nuevo en el momento, en lugar de enviarlo a la cola de revisión manual. Un solicitante sin historial en agencias de crédito requiere verificaciones alternativas que diferencien a un cliente legítimo sin historial de una identidad ficticia.

¿Qué solicitará ver un inspector respecto a las decisiones de incorporación de un banco?

Un inspector que revise el proceso de incorporación buscará pruebas de que el banco cumplió con su Programa de Identificación de Clientes (CIP) bajo la norma 31 CFR 1020.220: el nombre, fecha de nacimiento, dirección y número de identificación obtenidos antes de abrir cada cuenta, y cómo se verificó la identidad bajo procedimientos basados en el riesgo. Un registro de auditoría útil muestra, para cada solicitud, qué se verificó, a través de qué proveedor, qué se decidió, por qué y quién autorizó cualquier modificación manual. Para clientes empresariales, también muestra los titulares reales identificados y cómo se verificó a cada uno.

¿Puede un banco obtener el TIN de un cliente a través de un tercero en lugar de pedírselo directamente?

Sí, siempre que el banco esté supervisado por una agencia que haya emitido una orden de exención. Las órdenes emitidas por la OCC, la FDIC y la NCUA el 27 de junio de 2025, y por la Junta de la Reserva Federal el 31 de julio de 2025, todas con la conformidad del FinCEN, permiten a estos bancos obtener el TIN de un cliente a través de una fuente externa en lugar de pedírselo directamente al cliente. Esta medida es opcional, el banco debe seguir obteniendo el TIN antes de abrir la cuenta mediante procedimientos escritos basados en el riesgo, y el texto de la norma 31 CFR 1020.220 no ha sido modificado.

¿Cuánto tiempo debe probar un banco el software de incorporación con sus propias solicitudes?

Un banco debe probar el software de incorporación el tiempo necesario para cubrir un volumen representativo de solicitudes con resultados ya conocidos, incluyendo fraudes detectados, clientes legítimos y casos derivados a revisión manual. La recreación de solicitudes históricas puede realizarse tan pronto como el software candidato esté conectado, ya que esos resultados ya constan en los datos del banco. Una prueba en vivo con un nuevo proveedor en una parte del tráfico debe prolongarse hasta que las cuentas aprobadas muestren su comportamiento real, lo cual dependerá de los productos y volúmenes del banco.

¿Cómo responde Oscilar ante estos criterios?

Oscilar orquesta controles de identidad, KYC y KYB de terceros junto con los datos de la propia institución financiera, y no actúa como proveedor de datos o de verificación directo, por lo que no realiza la verificación de documentos ni pruebas de vida por sí mismo. Ofrece flujos de trabajo de incorporación que se adaptan al riesgo del solicitante, verificaciones de controles adicionales, gestión de casos asistida por IA que detalla el motivo de cada derivación, así como backtesting y pruebas A/B de cambios de políticas. Además, mantiene un registro de auditoría completo de cada decisión con sus argumentos y está diseñado para la intervención humana integrada. Al ser Oscilar el autor de esta guía, le sugerimos probarlo con sus propias solicitudes de la misma manera que lo haría con cualquier otra opción.

El mejor software de incorporación para un banco es aquel que demuestra su eficacia con las solicitudes reales de la propia entidad. Orquesta a los proveedores que el banco ya utiliza, ajusta dinámicamente los controles según el riesgo, decide y explica cada solicitud, mantiene reducida la cola de revisión manual y deja un registro de auditoría claro para los inspectores. El enfoque de Oscilar para la incorporación de consumidores es una opción que puede someter a esta prueba junto con cualquier otra alternativa de su elección.