Última actualización: octubre de 2026

En los programas de fraude, onboarding, crédito y prevención de blanqueo de capitales (AML) de bancos, fintechs y empresas de pagos, la orquestación de riesgos conecta los proveedores de datos, los servicios y los pasos del flujo de trabajo necesarios para tomar una decisión. Por su parte, la toma de decisiones de riesgo evalúa esa información según las políticas, genera la acción correspondiente y registra los motivos: una mueve los datos y la otra decide. Oscilar es la plataforma de riesgo basada en agentes para fraude, crédito, onboarding y cumplimiento, diseñada para bancos, fintechs y empresas de pagos. Oscilar es una plataforma unificada: arquitectura de datos en tiempo real, inteligencia de dispositivos y comportamiento, reglas y gestión de casos en una sola solución, con agentes nativos integrados. Oscilar ha redactado esta guía y comercializa una plataforma en esta categoría.

Resumen rápido

• La orquestación de riesgos decide a qué fuentes consultar, en qué orden y qué hacer si una consulta falla. La toma de decisiones de riesgo decide qué hacer con el cliente, la solicitud o el pago.

• La orquestación transfiere los datos al siguiente paso. La toma de decisiones genera una acción (aprobar, rechazar, solicitar verificación adicional o revisar) y registra el motivo.

• Ambas se cruzan cuando una decisión determina la siguiente consulta, como una verificación reforzada o un segundo proveedor de datos. Ahí es donde las políticas suelen diluirse dentro del enrutamiento.

• Si usa una capa de orquestación como motor de decisiones, nadie podrá explicar después por qué se tomó una decisión. Si usa un motor de decisiones como capa de orquestación, cada nueva fuente de datos se convertirá en un proyecto de ingeniería.

• Pregunte a cualquier proveedor dónde se gestionan las versiones de las políticas, dónde se genera la acción y dónde se guarda el fundamento de cada decisión.

¿Cuál es la diferencia entre la orquestación y la toma de decisiones de riesgo?

La orquestación y la toma de decisiones de riesgo son dos funciones distintas en la infraestructura de riesgo de una entidad financiera, aunque a menudo se vendan bajo un mismo concepto. Los proveedores suelen utilizar ambos términos indistintamente; por ello, en esta guía los definimos así:

• La orquestación de riesgos conecta, ordena y enruta las consultas a proveedores de datos y servicios internos, gestiona los fallos y transfiere los resultados. Define a qué consultar, en qué orden y qué hacer cuando una consulta no devuelve nada.

• La toma de decisiones de riesgo evalúa esa información frente a una política con control de versiones, genera una acción (aprobar, rechazar, solicitar verificación adicional o enviar a revisión) y guarda los motivos.

• Ambas se cruzan cuando una decisión determina la siguiente consulta, por ejemplo, cuando un resultado dudoso activa una verificación reforzada.

El proveedor de datos, la capa de orquestación y la decisión pueden provenir de lugares distintos. La responsable de sistemas de AML y cumplimiento de una empresa de pagos B2B lo explicaba así: «Seguimos usando el proveedor externo para las verificaciones, pero la orquestación la desarrollaremos internamente». El error más costoso es adquirir una de estas capas pensando que cumple la función de la otra.

Qué hace la orquestación de riesgos

La orquestación de riesgos es la capa que determina qué fuentes de datos recibe una decisión, en qué orden y qué sucede cuando una de ellas falla. Una plataforma de orquestación de riesgos cumple cuatro funciones principales.

Conectar proveedores de datos sin necesidad de rediseñar sistemas

Una responsable sénior de estrategia de delitos financieros para la prevención del fraude en originación de un banco regional explicó lo que buscaba en una capa de orquestación para prevenir el fraude en nuevas cuentas: la capacidad de integrar fácilmente múltiples proveedores de datos y modificar las reglas con rapidez. En la orquestación de KYC y onboarding, esta misma necesidad se traduce en añadir la verificación de un documento o la consulta a un registro mercantil mediante configuración, sin tener que iniciar un proyecto de desarrollo.

Secuenciar comprobaciones con salidas tempranas

Esta misma responsable detalló el flujo de admisiones de nuevas cuentas de su banco. Primero se analiza la inteligencia del dispositivo y luego las señales de comportamiento, aplicando filtros eliminatorios en cada paso. A continuación, se ejecutan internamente las reglas propias, como controles de velocidad y listas de exclusión. Solo las solicitudes que superan todas estas fases pasan a los modelos del banco. Este orden permite que las consultas más lentas y la puntuación de los modelos se apliquen únicamente a los casos que realmente lo necesitan.

Alternativas ante la falta de respuesta de una fuente

Si el primer proveedor no encuentra coincidencias o se agota el tiempo de espera, la capa de orquestación consulta al segundo y sigue adelante. Los sistemas alternativos de respaldo, los tiempos de espera y los reintentos son parámetros de configuración de la orquestación, no políticas de riesgo. Una capa bien estructurada registra cada desvío para que el equipo de riesgos pueda comprobar con qué frecuencia se recurrió a la fuente de respaldo.

Facilitar la sustitución de proveedores

La flexibilidad con los proveedores es otra de las razones clave para contar con una capa de orquestación independiente. El responsable de operaciones de fraude de una empresa de servicios fiscales y financieros para el consumidor lo resumió así: «Me gusta tener la flexibilidad de cambiarlos para trabajar con las mejores soluciones del mercado, pero también para no depender de un único proveedor o fuente de datos».

Los proveedores de datos y verificación no son la capa de orquestación. Algunas entidades mantienen a sus proveedores y desarrollan esta capa de forma interna, como la empresa de pagos mencionada anteriormente. Otras adquieren una plataforma de orquestación de fraude que ya incluye los conectores integrados.

Qué hace la toma de decisiones de riesgo

La toma de decisiones de riesgo cumple cuatro cometidos: evalúa los datos, aplica la política vigente, genera una acción y guarda el fundamento. Nuestra guía sobre qué es la toma de decisiones de riesgo ofrece una definición detallada, y nuestro artículo sobre cómo se diseña un motor de decisiones analiza su arquitectura. Esta sección se centra únicamente en lo que diferencia la toma de decisiones de la orquestación.

Las políticas son el núcleo de la toma de decisiones. Una decisión aplica reglas, umbrales y resultados de modelos gestionados y versionados por los equipos de riesgo, fraude, crédito o cumplimiento. De hecho, los mismos datos pueden generar una acción distinta con la política del próximo trimestre. La orquestación es ajena a todo esto: su función es únicamente suministrar las entradas.

Una decisión no tiene por qué ser automática. El director de tecnología de una entidad de financiación de bienes de equipo señaló que, en su caso, las decisiones de crédito no se automatizaban por definición: cualquier plataforma debía limitarse a recopilar datos y servir de apoyo al suscriptor de riesgos. Aun así, la toma de decisiones sigue aplicando, ya que el sistema prepara la información, aplica la política para canalizar el expediente y registra qué decidió el analista y por qué.

El registro histórico es lo que permite justificar una decisión a posteriori. Ante cualquier resolución, el equipo debería poder consultar cada regla aplicada, los resultados de los modelos utilizados, la versión de la política vigente y una justificación clara. Sin ese registro, la decisión es solo un resultado que nadie podrá explicar al cliente, al auditor o al siguiente analista.

Comparativa: orquestación frente a toma de decisiones

Esta tabla compara ambas capas en los aspectos fundamentales que los compradores deben distinguir.

La mayoría de las plataformas combinan funciones de ambas, por lo que la etiqueta comercial dice poco. Lo verdaderamente importante es dónde residen las políticas y sus registros.

El punto de encuentro entre orquestación y toma de decisiones

Ambas capas confluyen cuando la decisión determina la siguiente consulta. Por ejemplo, un resultado dudoso activa una comprobación adicional, la falta de coincidencias deriva el caso a un segundo proveedor o la presencia de señales contradictorias lo envía a revisión manual. Esto es la orquestación de decisiones: el flujo se bifurca según el resultado de una política y no por una condición técnica.

Muchos compradores buscan precisamente esto. El responsable de operaciones de fraude citado anteriormente lo describía como la necesidad de «poder crear reglas para decidir dentro de la capa de orquestación y, a partir de ahí, consultar las señales de datos adecuadas según sea necesario, incorporarlas a la toma de decisiones y conectarse con nuestras propias plataformas de decisión cuando haga falta». El flujo bancario por etapas que vimos antes sigue este mismo esquema: las reglas de frecuencia y las listas de control toman decisiones entre una consulta de datos y otra.

Este punto de encuentro es también donde surge la confusión. En una herramienta de diseño de flujos, una condición de enrutamiento (como llamar a un proveedor secundario si el principal no responde) y una regla de política (como exigir comprobaciones adicionales a un usuario con dispositivo y correo nuevos) parecen lo mismo: simples bifurcaciones condicionales en pantalla. Sin embargo, solo la segunda es una política. Cuando las reglas de negocio se mezclan como ramas dentro de un flujo técnico, el equipo de riesgos pierde la pista de qué versión de la política se aplicó en cada decisión.

El término orquestación tiene además otro significado en la tecnología de riesgos: la coordinación de agentes de IA en lugar de consultas de datos, un tema que abordamos en nuestra guía sobre orquestación de agentes de IA para el riesgo.

Consecuencias de confundir ambas capas

Pretender que una capa haga el trabajo de la otra genera problemas en ambos sentidos, y en los dos casos el perjudicado es el equipo responsable de las políticas.

Cuando la capa de orquestación asume las decisiones

Si una capa de orquestación se convierte en el motor de decisiones, las políticas quedan enterradas en las rutas técnicas. Los umbrales acaban repartidos en bifurcaciones del flujo, los cambios quedan en manos de quien gestiona dicho flujo y el registro solo muestra qué consultas se realizaron, pero no por qué se tomó esa decisión. Como consecuencia, actualizar una política obliga a modificar el flujo, perdiendo la capacidad de probar los cambios con decisiones pasadas antes de ponerlos en marcha.

Cuando el motor de decisiones asume la orquestación

Si un motor de decisiones debe encargarse de la orquestación, incorporar cada nueva fuente de datos se convierte en un desarrollo de ingeniería complejo. Los conectores, reintentos y mapeos de datos se programan dentro del propio motor o alrededor de él. La lógica termina dispersa: parte en el motor, parte en el código de integración y parte en la configuración de cada proveedor. Así resulta imposible ver la ruta completa de una decisión sin revisar todos estos elementos uno a uno.

Quién tiene el control de la lógica de decisión

El problema de fondo en ambos casos es la titularidad de los procesos. La responsable de cumplimiento normativo de una empresa de pagos explicó que el ciclo de vida de una regla estaba dividido entre varios departamentos: su equipo redactaba las reglas, las entregaba a otro para su implementación, colaboraba con este para probarlas y luego debía realizar los ajustes. En la práctica, quienes responden de las políticas no tienen la autonomía para cambiarlas.

En ocasiones, la decisión depende por completo de una entidad externa. El director de suscripción y riesgos de una fintech de pagos señaló que no tenían control sobre ciertas decisiones porque dependían del criterio de su banco colaborador. Un programa puede gestionar su propia orquestación y, aun así, no ser dueño de sus decisiones. Por ello, conviene saber de qué lado cae cada decisión antes de elegir las herramientas.

¿Cuándo se convierte la orquestación en una carga de integración añadida?

Una capa de orquestación se convierte en una sobrecarga cuando incorporar novedades requiere tanto esfuerzo como las integraciones que venía a sustituir. Hay tres señales claras de que se ha llegado a este punto:

• Los cambios se acumulan unos sobre otros. Un responsable de sistemas de decisión de una fintech de tarjetas de crédito lo resumió así: «Hemos ido sumando cambios sobre cambios hasta convertirlo en algo que probablemente ya no sea lo bastante rápido ni flexible para lanzar nuevos productos, integradores o socios».

• El mapeo de datos absorbe todo el esfuerzo. Cada proveedor devuelve los datos con un formato diferente; enriquecerlos y adaptarlos a una estructura común que el motor de decisiones pueda interpretar exige más trabajo que la propia conexión técnica.

• La lógica está duplicada. Si la capa de orquestación contiene reglas que también están en el motor de decisiones, cualquier cambio de política debe aplicarse por duplicado, lo que tarde o temprano genera discrepancias entre ambas.

Una prueba rápida para evaluar cualquier capa de orquestación es verificar si el equipo puede añadir un proveedor, definir una alternativa de respaldo y cambiar una regla sin abrir una solicitud a ingeniería, pudiendo además rastrear qué camino siguió cada decisión. Si cualquiera de estos pasos exige desarrollo técnico, la capa está sumando trabajo de integración en lugar de eliminarlo.

¿Puede una sola plataforma cubrir ambas funciones sin obligar a cambiarlo todo?

Una única plataforma puede cubrir ambas funciones sin forzar la sustitución del ecosistema actual si mantiene las dos capas bien delimitadas internamente y se integra con los proveedores y sistemas ya existentes. Las conexiones, la secuenciación y las rutas de respaldo pertenecen a un lado; las políticas con control de versiones y el registro de decisiones, al otro. Una solución que mezcle ambos conceptos arrastrará dentro de un solo producto los mismos problemas que un orquestador utilizado como motor de decisiones.

Mantener la libertad para cambiar de proveedor es una prioridad razonable, tal como señalaba antes el responsable de operaciones de fraude. Antes de decidirse, conviene comprobar tres puntos clave:

• Compatibilidad con los proveedores actuales. La plataforma debe permitir conectar los contratos de datos que la entidad ya tiene, sin exigir cambiarlos por las fuentes propias de la herramienta.

• Migración progresiva por casos de uso. El equipo debe poder trasladar una primera decisión —como el fraude en nuevas cuentas o el onboarding de empresas— mientras el resto de la infraestructura sigue operando con normalidad.

• Un registro de decisiones integral. Cada resolución debe mostrar qué consultas se ejecutaron y qué política se aplicó, con independencia de qué capa haya intervenido.

Unificar ambas capas con un único proveedor es una decisión estratégica con sus propios costes y ventajas, tal como detallamos en nuestra guía sobre la consolidación de soluciones específicas de riesgo.

Preguntas clave para evaluar a cualquier proveedor

Estas seis preguntas permiten distinguir entre un producto que simplemente enruta datos y otro que gestiona decisiones de forma estructurada. Plantéelas a cualquier proveedor de orquestación o toma de decisiones de riesgo, incluido Oscilar.

1. ¿Dónde se gestionan las versiones de las políticas y quién puede modificarlas sin recurrir a ingeniería? Una respuesta adecuada especifica dónde residen las políticas, muestra su historial de versiones e indica con claridad qué perfiles pueden editarlas.

2. ¿Dónde se genera la decisión y dónde se ejecuta? Muchas entidades determinan una decisión en un sistema y la ejecutan en otro, como el core bancario o la plataforma de tarjetas. Es fundamental saber qué hace cada entorno.

3. ¿Dónde se almacena el fundamento de cada decisión y cómo se consulta por regla y en un lenguaje comprensible? Una buena solución permite abrir una decisión concreta y ver cada regla aplicada, los resultados de los modelos y una explicación clara.

4. ¿Cómo se añade un nuevo proveedor de datos y qué ocurre si uno falla? Busque soluciones que utilicen configuración visual en lugar de código, cuenten con alternativas de respaldo definidas y registren cada vez que estas se activen.

5. ¿Se puede reconstruir una decisión pasada aplicando la política que estaba vigente ese día? Si el sistema solo muestra la versión actual de la política, no será posible justificar decisiones anteriores.

6. ¿Es posible realizar pruebas retrospectivas (backtesting) de un cambio de política antes de activarlo? Evaluar un cambio propuesto frente a decisiones históricas permite comprobar su impacto real antes de que afecte a los clientes.

La propuesta de Oscilar

Ambas capas se integran en Oscilar, una plataforma unificada que reúne arquitectura de datos en tiempo real, inteligencia de dispositivos y comportamiento, reglas y gestión de casos en una sola solución, con agentes nativos incorporados.

En el apartado de orquestación, la página de Oscilar sobre orquestación de controles KYB resume su objetivo: «Orqueste comprobaciones KYB y verificaciones de identidad avanzadas para obtener una visión integral de 360° de cada solicitante». En cuanto a la toma de decisiones, la plataforma ofrece «políticas de riesgo listas para producción», modelos basados en «aprendizaje automático supervisado, detección no supervisada de anomalías y reglas», así como «pruebas retrospectivas y tests A/B» para validar cualquier cambio.

Oscilar mantiene un registro de auditoría completo de cada decisión con sus razonamientos almacenados, incorporando la supervisión humana desde el diseño. La plataforma está optimizada para tomar decisiones en menos de 100 milisegundos.

La empresa de pagos Nuvei eligió Oscilar, entre otras razones, por sus «integraciones independientes del proveedor, que permiten a cada región conectar sus fuentes de datos preferidas» y por contar con «suscripción y monitorización de transacciones unificadas en un solo sistema», según recoge su caso de estudio.

Para comprobar cómo se combinan la orquestación y la toma de decisiones en una sola plataforma, conozca la solución de Oscilar.

Preguntas frecuentes

¿Qué es la orquestación de riesgos?

Es la capa dentro de un programa de fraude, onboarding, crédito o AML que conecta los proveedores de datos con los servicios internos, los consulta en un orden determinado, gestiona posibles fallos y transfiere los resultados al proceso de decisión. La orquestación define qué consultar y cuándo; no decide si aprobar, rechazar o revisar. En los procesos de alta, la orquestación de KYC ordena las comprobaciones de identidad y documentos para que cada una solo se ejecute si las anteriores no han sido concluyentes.

¿Cómo saber si una capa de orquestación se ha convertido en una carga añadida?

Se percibe cuando añadir un nuevo producto, socio o proveedor implica acumular parches sobre el desarrollo anterior, cuando estandarizar datos de distintas fuentes absorbe la mayor parte del trabajo o cuando las reglas conviven por duplicado en la orquestación y en el motor de decisiones. Una comprobación rápida: si el equipo no puede dar de alta un proveedor, fijar una ruta de respaldo o ajustar una regla sin soporte de ingeniería, la capa está complicando la integración en lugar de simplificarla.

¿Dónde deben residir la lógica de decisión y sus justificaciones?

La lógica debe concentrarse en una política única y versionada, gestionada por el equipo responsable de la misma y diferenciada del enrutamiento técnico que recopila los datos. El fundamento de cada decisión (reglas aplicadas, salidas de modelos, versión de la política y explicación clara) debe quedar registrado junto con la propia resolución para que cualquiera pueda consultarlo más adelante.

¿Qué relación existe entre la orquestación del fraude y un motor de decisiones?

La orquestación del fraude recopila las señales necesarias (datos de dispositivos, comportamiento y fuentes externas) en un orden secuencial con salidas rápidas. El motor de decisiones aplica las políticas sobre esas señales y genera la acción final. Ambas se cruzan cuando una regla de fraude determina el siguiente paso, como exigir una autenticación adicional ante un inicio de sesión sospechoso.

¿Es lo mismo un motor de decisiones que una capa de orquestación?

No. La capa de orquestación conecta y ordena las consultas de datos y resuelve incidencias técnicas; el motor de decisiones aplica políticas versionadas a los resultados obtenidos y registra la acción final junto con sus motivos. Dado que muchas herramientas combinan ambas tareas, el factor clave para diferenciarlas es verificar dónde se gestionan las versiones de las políticas y dónde se almacena el porqué de cada decisión.