Motor de decisión de crédito: guía de requisitos de RFP para prestamistas

Última actualización: septiembre de 2026

Un RFP para un motor de decisión crediticia debe describir lo que el equipo de crédito debe ser capaz de hacer después de la migración, ya que un RFP redactado a partir de las integraciones, campos de datos y número de reglas actuales solo comprará una copia más rápida del sistema vigente. Redacte cada requisito como un resultado esperado, pida a cada proveedor que lo demuestre con sus propios datos en lugar de solo describirlo y defina las ponderaciones antes de recibir las respuestas. Establezca como condición para preseleccionar a un proveedor la realización de una prueba con sus solicitudes reales. Incluya en el mismo RFP las condiciones para las solicitudes en curso, las decisiones históricas y el funcionamiento en paralelo, mientras todavía tenga capacidad de negociación.

Resumen rápido (TL;DR)

• Un RFP copiado de las integraciones, campos y cantidad de reglas del sistema actual traslada los límites de ese sistema al nuevo contrato. Redacte los requisitos como resultados que el equipo de crédito debe lograr tras la migración y detalle las limitaciones de integración por separado.

• Pida a cada proveedor que demuestre cada funcionalidad con sus propios datos o en una sesión de trabajo. Una funcionalidad demostrada califica más alto que una simplemente descrita.

• Defina las ponderaciones de mutuo acuerdo con los equipos de cumplimiento, crédito, riesgo y tecnología antes de recibir cualquier propuesta, y califique los requisitos indispensables con un criterio de aprobado o reprobado (pass/fail).

• Establezca como condición para la preselección una prueba con sus solicitudes reales: un análisis retrospectivo (backtest) con solicitudes pasadas y un entorno espejo (shadow) con solicitudes reales en vivo, con criterios de éxito firmados por ambas partes antes de comenzar.

• Defina claramente en el RFP cómo se tratarán las solicitudes en curso, dónde se guardarán las decisiones históricas, cómo finalizará el funcionamiento en paralelo y cómo sería el proceso de salida.

• El RFP es el punto de partida para la debida diligencia de terceros. La guía interinstitucional de junio de 2023 sobre relaciones con terceros está vigente a partir del 28 de septiembre de 2026, pero los organismos propusieron un reemplazo el 11 de septiembre de 2026, por lo que debe verificar qué versión aplica cuando envíe su RFP.

¿Qué debe definir correctamente un RFP para un motor de decisión crediticia?

El RFP para un motor de decisión crediticia debe describir el modelo operativo que la entidad financiera desea tras la migración, ya que los requisitos copiados del sistema actual solo conseguirán una versión más rápida del mismo. El RFP debe constar de seis partes: requisitos redactados como resultados esperados, preguntas que obliguen a cada proveedor a demostrar dichos resultados, ponderaciones definidas antes de recibir las respuestas, una prueba con solicitudes reales del cliente como condición para la preselección, verificación de referencias y condiciones de migración y transición.

Un motor de decisión crediticia es el sistema que ejecuta las llamadas de datos, reglas, modelos y políticas que transforman cada solicitud de crédito en una decisión y sus respectivos motivos. El funcionamiento técnico de un motor se detalla en qué es y qué hace un motor de decisión; esta guía se centra en el proceso de adquisición.

El RFP suele ser uno de tres flujos de trabajo paralelos. Un gerente de riesgos de proveedores y proyectos en un banco los describió como "vías paralelas que podemos realizar simultáneamente": "darle forma al RFP es una de ellas", la revisión de la gestión de riesgos de terceros es otra, "y luego también la prueba de concepto". Redacte el RFP de modo que alimente los otros dos procesos, incluyendo las preguntas de debida diligencia que el equipo de riesgos de todos modos formulará y las condiciones de la prueba a las que se someterá a los finalistas.

Si el equipo aún no ha decidido si prefiere desarrollar internamente o comprar una solución, resuelva ese dilema antes de redactar el RFP, ya que este documento asume que la decisión es comprar.

Por qué los RFP terminan especificando el mismo sistema que se quiere reemplazar

Los requisitos suelen partir de la documentación del sistema actual, por ser la que el equipo tiene a la mano. Sus integraciones, campos de datos y número de reglas se copian en el RFP como requisitos, y con ellos se arrastran sus vicios. Un oficial de BSA en un banco, al planificar el reemplazo de un sistema de cumplimiento, señaló la costumbre que se debe evitar: el mapeo de datos hecho de la "manera fácil" y basada en "así es como siempre lo hemos hecho", frase que el oficial describió como "algo que se dice mucho por aquí y que debemos erradicar".

El documento de requisitos resultante suele ser genérico y nadie se hace responsable de él. Al preguntarle si existía un documento de requisitos de negocio para la plataforma en evaluación, un líder de crecimiento en una empresa de activos digitales respondió: "Tenemos uno muy genérico", y añadió que "necesita ser mucho más específico y detallado, especialmente sobre... ¿cuál es la tolerancia al riesgo, qué tipo de controles queremos implementar?". La empresa también estaba contratando a "una persona que se responsabilizará de este flujo", lo cual es la solución correcta: un RFP necesita un dueño que pueda definir claramente qué debe ser capaz de hacer el equipo de crédito.

Parte de la rigidez del sistema que se reemplaza se diseñó en el momento de la compra, de mutuo acuerdo entre el comprador y el proveedor. Un vicepresidente sénior y director de prevención de lavado de dinero (AML) y sanciones en un gran banco regional, al describir el sistema de AML del banco, comentó que "tanto el cliente como el proveedor fueron cómplices en ciertas decisiones de diseño", y que el resultado fue "demasiado cerrado": "tienes que llevarlo al concesionario para que le hagan cualquier ajuste al motor. No puedes hacerlo tú mismo". Un RFP redactado en torno al desarrollo actual repite ese mismo error con el próximo motor.

El costo de esa rigidez se hace evidente cada vez que el equipo de crédito necesita un cambio. En un gran banco regional, un ejecutivo de crédito mencionó que implementar una nueva política de tarjetas tomaba meses de principio a fin, dedicando la mayor parte del tiempo a las pruebas. Un director de delitos financieros en un emisor de tarjetas comentó que "cada solicitud de cambio cuesta una cantidad astronómica de dinero", y que el equipo buscaba "un sistema que sea mucho más autosuficiente porque, literalmente, ya no podemos con tantas solicitudes de cambio".

Nada de esto significa que el sistema actual no sirva, y un RFP que lo describa como inservible le resta credibilidad al comprador. Un director sénior de crédito en un banco digital, al redactar un caso de negocio, comentó: "estamos en una posición bastante buena con [nuestro sistema actual]. Así que no está inservible", y planeó reformular una evaluación del estado actual que mostraba "capacidad limitada, sin capacidad", porque "si presento este caso de negocio ante los ejecutivos, me van a preguntar qué demonios he estado haciendo, ¿verdad?". Describa el sistema actual con precisión y justifique el cambio a partir de las necesidades del modelo operativo post-migración.

Una forma de mantener los requisitos orientados hacia el futuro es el método descrito por un líder de operaciones del área de crédito y cobranza de una empresa de servicios financieros digitales: "un documento de requisitos o especificaciones" que cubra lo necesario para satisfacer las necesidades del equipo de forma interna, comparado con "un documento de contraste con todo lo que ya viene listo de fábrica" por parte de los proveedores. Construya el documento de requisitos a partir de las capacidades que el equipo de crédito necesitará y use el contraste para ver qué proveedores ya las cumplen.

Señales de que un RFP está describiendo el sistema antiguo:

• Los requisitos detallan las integraciones, campos o cantidad de reglas actuales en lugar de lo que el equipo de crédito debe ser capaz de hacer.

• El documento de requisitos es una plantilla genérica o no tiene un responsable asignado.

• Cada cambio descrito en los requisitos asume que debe realizarlo el proveedor.

• El estado actual se presenta como inservible cuando no es así.

• Las condiciones de migración se dejan de lado para definirse en el acuerdo de trabajo (SOW).

Redacte los requisitos pensando en cómo operará tras la migración

Redacte cada requisito como un resultado que un equipo específico debe poder lograr tras la migración y defina las pruebas que aceptará para validarlo. La siguiente tabla reformula nueve requisitos que los RFP suelen copiar del sistema actual.

Las funcionalidades que realmente vale la pena buscar se detallan en qué buscar en una plataforma de decisión crediticia. El objetivo del RFP es más acotado: convertir esas necesidades en requisitos que el proveedor debe demostrar con hechos.

Cada reformulación especifica quién debe ser capaz de hacer qué, algo que se le puede pedir al proveedor que demuestre.

El cambio de políticas y las pruebas van primero porque es ahí donde se consume el tiempo. Un ejecutivo de crédito en un gran banco regional comentó que "el gran esfuerzo siempre está en las pruebas, que creo que son manuales", con equipos que "diseñan casos de prueba manualmente para luego activar diferentes ramas de la política y asegurar que se implemente como se planeó". El requisito debe solicitar lo que describió un director de estrategia de riesgo crediticio de un gran banco regional: "volver a procesarlo en el motor de decisión y ver los impactos en todo, eso es muchísimo más rápido".

El registro de cada cambio debe guardarse en el motor, ya que las pruebas de cambio se auditan. Un líder de implementación en un banco, al describir el inicio de la auditoría antes de un lanzamiento, comentó: "cada nuevo cambio ahora requiere una solicitud de cambio, que es un [ticket]". Exija que el propio motor mantenga ese registro: quién cambió qué, cuándo y con la aprobación de quién. Una herramienta de tickets externa deja las pruebas en otro lugar.

Las excepciones manuales requieren el mismo tratamiento. Un evaluador de crédito comercial sénior en un banco comunitario preguntó durante una evaluación: "¿Hay alguna manera de hacer excepciones dentro de esto? ¿O hay que ceñirse estrictamente a la política de crédito una vez que se implementa?". El manual de la OCC sobre Gestión de Riesgos de Carteras de Préstamos y Crédito (julio de 2026) señala que el registro de préstamos generalmente incluye "registrar las excepciones a la política y los requisitos de monitoreo continuo para fines de seguimiento y reporte", por lo que debe incluir ese registro en el requisito.

Las explicaciones son una obligación legal, por lo que deben figurar en los requisitos. La Regulación B exige que la declaración de motivos para una acción adversa sea "específica e indique el motivo o motivos principales de la acción adversa" (12 CFR 1002.9(b)(2)), y cuando un reporte de crédito haya influido, la sección 615(a) de la FCRA añade sus propios requisitos de notificación, incluyendo la puntuación de crédito (credit score) si se utilizó una. La prueba que el motor debe superar es la que definió un líder de crédito en un emisor de tarjetas: "necesitaba asegurarme de poder... vincularlo directamente con la... toma de decisiones".

Redacte también el registro de decisiones como un requisito. Un líder de riesgos de un banco recordó que sus reguladores les dijeron "tienen que validar lo que hay ahí" y le pidieron al banco "empezar a enviarnos cada solicitud y cada dato que influye en esa decisión, para que podamos verificar el motor de decisión". Ese es el testimonio de un banco sobre lo que pidieron sus supervisores y sirve como una excelente prueba para el requisito: cualquier decisión debe poder reconstruirse a partir de sus entradas, la versión de la política que se ejecutó y los motivos generados.

Las pruebas deben realizarse en el motor que se va a comprar. Cuando las pruebas retrospectivas y el monitoreo se ejecutan en un repositorio de datos separado del motor de decisión, como ocurre en una entidad financiera digital, el equipo está probando una copia de su política en lugar del motor real que toma las decisiones. Para las pruebas tipo A/B, especifique un entorno espejo real con aplicaciones en vivo y una asignación constante, ya que un solicitante recurrente que termine en un grupo de prueba diferente contaminará la comparación.

Especifique los volúmenes de solicitudes y las necesidades de consulta en el RFP, y solicite los costos de rendimiento y almacenamiento a esa escala, para que el precio refleje su realidad operativa. Agregar una fuente de datos no debería requerir un cambio de plataforma. Si el plan incluye datos bancarios autorizados por el consumidor, redacte el requisito de modo que no dependa del calendario de la norma de derechos de datos financieros personales de la CFPB bajo la Sección 1033, cuyas fechas de cumplimiento están suspendidas por orden judicial mientras la CFPB reconsidera la norma (a septiembre de 2026).

Si se van a crear o monitorear modelos en el motor, especifique las herramientas necesarias en el requisito. La lista que un prestamista de consumo presentó a su proveedor incluía muestreo y ponderaciones, inferencia de rechazo, pruebas de exclusión (holdout), medidas de estabilidad y discriminación como PSI, KS y AUC, cómo se derivan los códigos de motivo de acción adversa a partir de un modelo, análisis de características y una variedad de algoritmos. Si la entidad financiera aporta sus propios modelos, exija una ruta clara para su implementación y monitoreo.

Defina qué le corresponde al motor de decisión y qué permanece en el sistema de originación de préstamos (LOS). Un prestamista de consumo mantiene cada decisión en su motor, pero gestiona la generación y firma de contratos fuera de él, tratando la plataforma estrictamente como un motor de decisión.

Añada un requisito con miras al futuro: un nuevo modelo, fuente de datos o estrategia debe poder llegar a producción sin necesidad de nueva infraestructura. Las limitaciones de integración (como el sistema central o core, la plataforma de streaming y los burós de crédito) son reales y deben ir en una lista aparte, de modo que el proveedor no pueda responder a un resultado esperado simplemente con un diagrama de integración. Un gerente de estrategia de alianzas en un emisor de tarjetas atribuyó los límites de una plataforma local a su arquitectura y señaló lo que le faltaba: "la capacidad de hacer pruebas retrospectivas, la capacidad de hacer pruebas beta con diferentes variables". Esas capacidades son las que deben detallar los requisitos.

Lista de verificación del RFP: preguntas para cada proveedor

Cada una de las siguientes preguntas pide al proveedor una demostración con sus datos o en una sesión de trabajo práctica. Incorpore estos bloques en el RFP y sume sus propios requisitos indispensables. Un oficial de BSA en un banco mantuvo una pregunta clave durante toda la evaluación: "¿ya le hicimos la siguiente pregunta al proveedor?".

Pregunte sobre cada funcionalidad si está disponible hoy en vivo o si forma parte de su plan de desarrollo (roadmap). Un director de delitos financieros en un emisor de tarjetas, al recordar una propuesta sobre un "modelo centrado en IA que se aplicaría a nuestros sistemas heredados", preguntó: "¿eso alguna vez ocurrió? Estoy viendo un sistema de hace años".

Cambio y control de políticas

• ¿Cuáles de las funcionalidades mencionadas en su respuesta están disponibles en vivo hoy y cuáles están en desarrollo? ¿Se comprometerá por contrato a entregar las funciones en desarrollo de las que dependemos?

• Demuestre cómo un analista de crédito modifica un límite, lo prueba y lo publica, sin que intervenga el personal de soporte de su empresa.

• ¿Quién puede aprobar un cambio de política y dónde se registra dicha aprobación?

• ¿Cómo se realizan las excepciones manuales, qué límites aplican y dónde aparece cada excepción a la política en los reportes?

• ¿Qué cambios requieren de su equipo de soporte después de la puesta en marcha y qué costo tienen?

Pruebas y demostración práctica

• Vuelva a procesar una muestra de nuestras solicitudes anteriores con una política modificada y muestre el impacto antes de publicarla.

• Muestre una nueva política ejecutándose en un entorno espejo real con solicitudes en vivo e indique dónde se registran esas decisiones espejo.

• ¿Cómo aseguran que un solicitante recurrente se mantenga en el mismo grupo de prueba?

• ¿Realizarán una prueba con nuestras propias solicitudes antes de la firma del contrato, bajo las condiciones de este RFP? ¿Existe un límite de tiempo para esta prueba?

• ¿Qué datos necesitan para la prueba, en qué formato y cómo la realizan si no podemos compartir información confidencial completa?

Explicaciones y acción adversa

Un director de riesgos en un emisor de tarjetas estableció el estándar para este grupo: "Necesito poder explicar por qué elegimos estos límites. Y si mi explicación es porque el proveedor nos dijo que lo hiciéramos, no va a caer muy bien".

• Muestre los motivos que su motor genera para estas muestras de rechazo y rastree cada uno hasta el paso de la política que rechazó la solicitud.

• Envíe su lista completa de códigos de motivo, con una definición sencilla de cada código.

• Muestre cómo los factores del reporte de crédito llegan a la notificación de acción adversa en una solicitud rechazada que utilizó dicho reporte.

• ¿Cómo se generan los motivos cuando un modelo analítico contribuye al rechazo?

• ¿Qué documentación nos proporcionarán para poder explicar nuestros propios límites y parámetros de riesgo sin depender de ustedes?

Datos e integración

• ¿Qué fuentes de datos están integradas actualmente y qué implica agregar una nueva?

• Cotice el rendimiento y el costo de almacenamiento para los volúmenes de solicitudes y necesidades de consulta detallados en este RFP.

• ¿Cómo exportamos nuestros datos de decisión y en qué formato?

Modelos y monitoreo

Un líder de gestión de riesgos de modelos en un banco regional describió el orden que esperan los validadores: "Necesitaríamos validarlo antes de que... la primera línea lo implemente y lo ejecute".

• ¿Qué componentes de su motor consideran como modelos y qué documentación acompaña a cada uno?

• ¿Qué recibirán nuestros validadores para cada modelo que nos proporcionen y en qué momento?

• ¿Cómo implementamos y monitoreamos un modelo desarrollado por nosotros mismos?

• ¿Qué variables analiza el monitoreo después de la puesta en marcha y quién recibe las alertas?

Registro de decisiones y auditoría

• Reconstruya esta decisión pasada para nosotros: sus datos de entrada, la versión de la política que se ejecutó y los motivos que generó.

• ¿Qué información contiene un registro de cambios y podemos exportarlo para presentarlo ante un supervisor o auditor?

• ¿Durante cuánto tiempo se conservan los registros de decisión y la información utilizada para tomarlas, y en qué formato?

Seguridad, resiliencia y debida diligencia de terceros

• Proporcione su documentación de seguridad de la información, así como sus planes de resiliencia operativa y continuidad de negocio.

• ¿Cómo nos reportan los incidentes de seguridad y en qué plazos?

• ¿Qué subcontratistas tienen acceso a nuestros datos o decisiones y cómo nos notificarán si incorporan uno nuevo?

• Proporcione información sobre su situación financiera y sus coberturas de seguro.

• ¿Con qué indicadores de rendimiento (SLAs) se comprometerán en el contrato?

Migración y transición (cutover)

• ¿Cómo tratan las solicitudes que ya están en proceso al momento de la transición y con cada cambio posterior de versión de política? Responda por escrito.

• ¿Qué información histórica se migra de nuestro motor actual, en qué formato y qué se descarta u omite?

• ¿Cómo funcionarán los dos motores en paralelo y qué se considerará una diferencia justificada?

• ¿El entorno de producción se construirá desde cero o se promoverá desde el entorno de pruebas?

• ¿Qué necesitan de nuestro core bancario, de nuestro sistema de originación y de los burós durante y después de la migración, para cuándo y quién controla cada conexión?

Condiciones comerciales y salida

• Defina el precio de la prueba práctica, de la implementación y los costos de mantenimiento antes de que comience dicha prueba.

• ¿Qué tipo de soporte y asesoría en riesgo de crédito recibiremos tras la firma y por parte de quién?

• ¿Qué flexibilidad permiten las condiciones del contrato si el servicio no cumple las expectativas?

• En caso de rescisión, ¿a qué plazos de preaviso, asistencia en la transición y devolución o destrucción de nuestros datos e histórico de decisiones se comprometen?

Cómo calificar y ponderar las respuestas

Defina las ponderaciones de los criterios de evaluación antes de recibir las respuestas, para que las calificaciones reflejen las prioridades acordadas de antemano. Un líder de estrategia de fraude en un neobanco diseñó una plantilla de evaluación "con diferentes ponderaciones" y luego planeó "alinear las ponderaciones con los distintos líderes del proyecto", esperando que el director de cumplimiento dijera: "si van a hacer esta inversión, debemos cumplir con [estos] requisitos obligatorios". Deje que el equipo de cumplimiento defina los indispensables y califíquelos como aprobado/reprobado.

Asigne un responsable a cada área. Un líder de alianzas en una fintech que presta servicios a bancos comunitarios y cooperativas de crédito describió una división de la plantilla de evaluación para que "diferentes miembros del equipo se encarguen de la usabilidad y la escalabilidad, las funcionalidades existentes y los costos de cambio, así como de la viabilidad del proveedor y la continuidad del negocio". Los costos de cambio y la continuidad deben estar en la evaluación junto con las características técnicas.

Califique más alto lo que el proveedor demostró frente a lo que escribió. Una funcionalidad demostrada en sus solicitudes reales, en una sesión práctica o durante la prueba de concepto, vale más que la misma funcionalidad descrita en un papel, y una característica en desarrollo no suma puntos hasta que esté comprometida por contrato.

Las ponderaciones son decisivas cuando dos proveedores parecen estar empatados. Un líder de riesgos en un banco, al describir una selección anterior, la calificó como "un lanzamiento de moneda al aire. Ambos eran muy competitivos y muy buenos", y comentó que la decisión final recayó en los miembros del equipo de fraude, quienes "simplemente prefirieron" al otro proveedor "desde el punto de vista de la usabilidad". Las ponderaciones acordadas de antemano y una prueba con solicitudes reales son lo que diferencia a los proveedores que parecen idénticos en el papel.

Exija el mismo nivel de exigencia para cada respuesta: completa y bajo control de riesgos. Un líder de riesgos en una entidad financiera de consumo describió el objetivo como "no solo buscar una solución atractiva a primera vista, sino una herramienta que cuente con todos los controles de riesgo y la estructura necesarios".

Las filas de aprobado/reprobado funcionan como un filtro: el proveedor que repruebe una queda fuera, sin importar su calificación en las demás secciones.

Establezca como condición para la preselección una prueba con sus solicitudes reales

La cláusula de prueba de concepto existe porque los compradores recuerdan lo que reveló la implementación la última vez. Un directivo responsable de contratos y de la exposición regulatoria explicó por qué exigían una prueba técnica: "La solución que tenemos en este momento no es la que realmente desearíamos, ¿verdad? Por eso, no queremos volver a caer en la misma situación de la última vez que compramos una herramienta, avanzamos en la implementación y luego nos dimos cuenta de que había cosas que simplemente no podíamos hacer".

Una demostración comercial no basta para resolver esa duda. Un CTO en una fintech de crédito comentó que una prueba "no tiene por qué ser un ejercicio gigante", solo lo necesario para responder una pregunta: "¿realmente funciona tan bien como en la hermosa demostración, o simplemente nos deslumbró con palabras y todo fue simulado?".

Escriba la prueba de concepto en el RFP como un requisito obligatorio para preseleccionar a un proveedor, bajo estas condiciones:

• Alcance. Un análisis retrospectivo (backtest) con sus propias solicitudes pasadas y un entorno espejo real con solicitudes en vivo. Un líder de tecnología de riesgo crediticio en una entidad financiera de consumo describió los sustitutos habituales: "lanzar un modelo, calcular una puntuación y no hacer nada con ella... o tener un entorno espejo pero a muy bajo volumen", y concluyó que "eso no es un verdadero análisis en espejo".

• Criterios firmados antes de comenzar. Defina el cronograma, redacte criterios de éxito que ambas partes firmen y obtenga el compromiso previo de un ejecutivo de que el cumplimiento de los mismos significará avanzar en el proceso. La redacción de estos criterios se detalla en criterios de aceptación para una prueba de concepto.

• Aportes de cada parte. Acuerde por escrito qué debe responder la prueba y qué recursos proporcionará cada parte. Un líder de riesgos de un banco recordó que un análisis retrospectivo que aún se hacía de forma manual se debió a un alcance que no se delimitó desde el inicio: "algunos malentendidos sobre cuál es la capacidad real del sistema y qué intentamos lograr".

• Duración y límites. Especifique cuánto tiempo durará la prueba, con qué volumen de tráfico y qué eventos marcarán su finalización. Un líder de integración en una fintech de crédito preguntó directamente a un proveedor: "¿Existe alguna limitación de su parte sobre cuánto tiempo puede durar la prueba de concepto?".

• Precio definido de antemano. Acuerde el precio y el alcance antes de ejecutar la prueba, de modo que una aprobación técnica no se detenga por una sorpresa en el presupuesto.

Defina las condiciones de protección de datos con el área legal y su equipo de privacidad antes de compartir cualquier información fuera de la institución: qué datos, en qué formato y bajo qué acuerdo. Las instituciones lo manejan de diferentes formas: un líder de datos y operaciones de un banco comentó que podían proporcionar datos reales pero que "preferirían avanzar utilizando datos sintéticos" si eso agilizaba el proceso, y que la información preparada "ha sido tokenizada, por lo que no hay revelación ni exposición de datos de carácter personal (PII o NPI)". Pregunte a cada proveedor cómo realiza una prueba de concepto cuando no se pueden compartir datos reales.

Tenga claridad sobre lo que una prueba de concepto puede demostrar antes de firmar el contrato. Puede mostrar las decisiones que toma el motor con sus solicitudes, los motivos que genera y cómo se modifica, prueba y publica una política. No puede mostrar el comportamiento de pérdidas a largo plazo, que solo se hace evidente con el tiempo de maduración de los créditos; por lo tanto, las métricas de pérdidas provienen del análisis retrospectivo (backtest) con solicitudes pasadas cuyos resultados finales ya se conocen. Un líder de estrategia de fraude en un neobanco calificó una prueba técnica comparativa cara a cara para elegir una plataforma como "una tarea muy pesada", ya que una evaluación real entre opciones tomaría muchos meses.

La guía de las mejores plataformas de decisión de riesgo crediticio para prestamistas detalla cómo ejecutar estas pruebas con los finalistas: un análisis retrospectivo de decisiones pasadas, una política alternativa junto a la actual, una verificación de los motivos de acción adversa, un cambio de política cronometrado y un esquema de monitoreo acordado antes de la puesta en marcha.

Qué preguntar a las referencias de un proveedor

Las llamadas de referencias son fundamentales en la debida diligencia, así que reserve un espacio para ellas en el cronograma. Un gerente de proyectos de un banco las incluyó con el resto de la "debida diligencia de proveedores" y añadió: "no lo digo como un trámite para salir del paso, sino como algo que realmente debemos analizar a fondo".

Solicite una referencia que tenga un perfil similar al suyo: el mismo tipo de institución, productos financieros parecidos y que haya migrado desde un sistema similar al de ustedes. Pregunte por el problema específico que tenía cada referencia y cómo se resolvió. Un líder de riesgo crediticio en un emisor de tarjetas comentó: "siempre me cuesta creer ciertas afirmaciones generales como 'se redujeron las tasas de riesgo promedio', prefiero conocer un problema muy específico que tenían antes de contratar al proveedor y cómo se resolvió exactamente".

Pregunte cómo se comportó el soporte y el conocimiento en temas de crédito después de la firma del contrato. Un director de estrategia de crédito en una fintech, que planeaba dejar a su proveedor actual, resumió la queja como "falta de soporte, falta de conocimiento, falta de todo", junto con la negativa del proveedor a permitirles un contrato mes a mes.

Preguntas para formular a cada referencia:

• ¿De qué sistema migraron y qué fallas surgieron al momento de la transición?

• ¿Qué problema específico plantearon a este proveedor y cómo se resolvió?

• ¿Cómo se comparó el equipo de implementación con el equipo comercial de ventas?

• ¿Cómo ha sido la calidad del soporte y su conocimiento en temas de crédito desde que firmaron el contrato?

• ¿Qué compromisos de desarrollo (roadmap) se cumplieron y cuáles no?

• ¿Cuánto tiempo les toma ahora realizar un cambio de política y quién lo hace?

Incluya las condiciones de migración y transición en el RFP

Las condiciones de migración que se acuerdan después de firmar el contrato se negocian sin capacidad de presión. Inclúyalas en el RFP, solicite respuestas por escrito y califíquelas. Analícelas en este orden:

1. Solicitudes en curso. Pregunte cómo se tratan las solicitudes que ya están en proceso al momento de la transición y con cada cambio posterior de versión de política, y exija la respuesta por escrito. Una solicitud que comienza bajo una versión de la política y finaliza bajo otra requiere una regla registrada que defina con qué versión se tomó la decisión.

2. Decisiones históricas. La Regulación B exige que un acreedor conserve cada solicitud, "cualquier otra información escrita o registrada utilizada para evaluar la solicitud" y copias de la notificación de la acción tomada, junto con cualquier declaración escrita de motivos específicos, durante 25 meses para crédito de consumo y 12 meses para crédito comercial, con algunas excepciones (12 CFR 1002.12(b)). Defina qué histórico de datos se migrará al nuevo motor, qué datos seguirán disponibles para consulta en el sistema anterior y quién asumirá los costos de mantenerlos legibles; trate la carga de datos históricos como un flujo de trabajo prioritario desde el inicio del proyecto. Un líder de ingeniería en una empresa de pagos que no migró su histórico aún mantiene activa "una pequeña instancia de gestión de casos" de su proveedor anterior para que los auditores "puedan seguir consultando los casos antiguos". La aplicación de las normas de retención de datos a los registros de un motor específico es un tema que debe consultar con su equipo legal.

3. Funcionamiento en paralelo. Planifíquelo en retrospectiva a partir de la fecha de vencimiento del contrato actual. Un oficial de BSA en un banco calculó la fecha de puesta en marcha del nuevo sistema restando el periodo de preaviso del contrato vigente, con un margen de seguridad para el cierre de año cuando "no se hace nada de trabajo", y un subdirector de estrategia de riesgo de cumplimiento en un banco regional señaló el límite estricto: "si realmente queremos hacer una prueba en paralelo real, tiene que ser antes de [la fecha en que se apague el sistema actual]". Establezca criterios de salida de antemano y defina qué se considera una diferencia justificada, ya que un nuevo motor que replique exactamente cada decisión del anterior solo estará duplicando sus mismos errores.

4. Entorno de producción limpio. Construya el entorno de producción desde cero. Un líder de programa que dirigía una evaluación de proveedores rechazó el atajo de promover el entorno de pruebas a producción, debido a que un plan de transición siempre incluye la eliminación de datos de prueba, y "nunca se debe eliminar información en un entorno de producción real".

5. Dependencias. Detalle cada sistema del que dependan los datos del motor (como el core bancario, el sistema de originación y los burós) y quién los controla. Un director de operaciones y oficial de BSA en un banco cuyo core se había tercerizado a un servicio gestionado externamente no lograba contactar al personal del proveedor del core, a pesar de que todos los datos de la nueva plataforma debían provenir de ahí. Planifique la transición considerando otros proyectos en curso: un líder de programas de cumplimiento y BSA en un banco rechazó iniciar un segundo proyecto durante la migración de la plataforma, ya que sumarlo al mismo tiempo "añadiría complejidad y un riesgo de ejecución que no estamos preparados para asumir hoy".

6. Fases. Si planea migrar toda una cartera de productos crediticios a un solo motor, realice el proceso por fases según la línea de productos y redacte el RFP considerando la cartera completa, incluyendo los productos que se migrarán al final. Un prestamista de consumo está consolidando sus productos de esta manera, una línea de productos a la vez, bajo la supervisión de su equipo directivo.

7. Condiciones de salida. Defina cómo se transferirá el servicio a otro proveedor sin costos excesivos y cómo se le devolverán o destruirán sus datos e historial de decisiones, bajo un calendario definido por usted.

Una vez que el nuevo motor esté en vivo, cada cambio posterior requerirá su propio proceso de aprobación, pruebas y control, lo cual se detalla en control de cambios con el motor en vivo.

La debida diligencia de terceros comienza con el RFP

La Guía Interinstitucional sobre Relaciones con Terceros: Gestión de Riesgos de junio de 2023 es la normativa de gestión de riesgos de terceros vigente para los bancos al 28 de septiembre de 2026. El 11 de septiembre de 2026, la FDIC, la Reserva Federal, la NCUA y la OCC propusieron una guía de reemplazo, y una vez que se apruebe la versión definitiva, las agencias bancarias planean revocar la guía de 2023; por lo tanto, verifique qué versión está vigente al enviar su RFP.

La guía de 2023 estructura la gestión de riesgos de terceros en cinco etapas: planificación, debida diligencia y selección de terceros, negociación de contratos, monitoreo continuo y terminación del servicio. El RFP pertenece a la etapa de debida diligencia y selección, con la planificación previa, y el marco de la guía es claro sobre quién conserva la responsabilidad: "El uso de terceros por parte de una organización bancaria no disminuye su responsabilidad de cumplir con estos requisitos en la misma medida que si las actividades fueran realizadas de forma interna por la propia organización".

Bajo la guía de 2023, tal como está vigente al 28 de septiembre de 2026, la debida diligencia abarca temas como seguridad de la información, resiliencia operativa, reporte de incidentes y dependencia de subcontratistas; por su parte, la negociación de contratos cubre aspectos como indicadores de rendimiento (SLAs), una transición ordenada al término del contrato y la devolución o destrucción de los datos del banco. Incluya el primer grupo en el RFP en forma de preguntas y el segundo como condiciones contractuales, de modo que los proveedores respondan y coticen estos conceptos antes de la selección final.

Un prestamista que forma parte del grupo de un banco, o que opera a través de un banco socio, adopta los procesos de dicho banco. Un ejecutivo de crédito y cobranza en una entidad financiera de consumo propiedad de un banco explicó que, al ser una subsidiaria de un banco, "cualquier proveedor que trabaje con nosotros debe pasar por el proceso de selección de proveedores del banco corporativo". Una fintech de crédito suele enfrentar el mismo proceso a través de su banco socio, por lo que es recomendable involucrar al equipo de gestión de proveedores del banco desde la redacción del RFP.

Los modelos del proveedor también siguen siendo responsabilidad del prestamista en cuanto a su comprensión técnica. La guía interinstitucional revisada sobre gestión de riesgos de modelos del 17 de abril de 2026 (Reserva Federal SR 26-2, Boletín OCC 2026-13, FDIC FIL-15-2026) señala que las organizaciones bancarias "podrían no recibir del proveedor el código fuente, los datos o la metodología subyacente que obtendrían si el modelo se desarrollara internamente. Sin embargo, los principios de gestión de riesgos de modelos siguen siendo aplicables". Detalla que una buena práctica "incluye desarrollar una comprensión clara del modelo del proveedor, lo que incluye su solidez conceptual, diseño, datos de desarrollo y rendimiento", además de "llevar a cabo un monitoreo continuo y análisis de resultados" de dichos modelos.

La misma guía define un modelo como "un método, sistema o enfoque cuantitativo complejo que aplica teorías estadísticas, económicas o financieras para procesar datos de entrada en estimaciones cuantitativas", y excluye los procesos basados en reglas aritméticas simples y deterministas que carecen de una teoría estadística o económica subyacente. Determinar qué componentes de un motor de decisión entran en esa definición es una decisión del equipo de riesgo de modelos del prestamista, por lo que debe preguntar a cada proveedor qué partes de su solución consideran modelos y qué documentación entregan con cada una.

Cómo responde Oscilar a este RFP

Las páginas de originación de crédito de Oscilar detallan que los equipos pueden realizar pruebas retrospectivas (backtests) con datos históricos para validar nuevas políticas de crédito antes de su implementación en producción, evaluar cómo cambia el rendimiento de los modelos entre diferentes versiones y gestionar tasas de aprobación, índices de cartera vencida y sus propios KPIs de negocio. Oscilar monitorea la desviación (drift) de datos, variables y conceptos junto con KPIs de resultados segmentados.

En cuanto a las preguntas de registro de decisiones y aprobación planteadas anteriormente, la respuesta de Oscilar es una pista de auditoría completa por decisión con lógica de aprobación almacenada y un diseño pensado con intervención humana en el proceso (human-in-the-loop). Las especificaciones de su plataforma garantizan decisiones en menos de 100 milisegundos; al igual que con cualquier especificación de proveedor, le sugerimos probar este rendimiento con sus propios volúmenes durante la prueba de concepto.

Chartis Research incluyó a Oscilar en su lista FCC50 de 2026, un ranking de proveedores de tecnología para la prevención de delitos financieros y cumplimiento normativo, con reconocimientos destacados en Innovación en IA Agéntica y Personalización Low-Code/No-Code. Este ranking se especializa en tecnología de cumplimiento y prevención de delitos financieros, por lo que no evalúa directamente motores de decisión crediticia. Entre las empresas que utilizan Oscilar para decisiones de crédito y riesgo se encuentran SoFi, Nuvei y Clara.

Preguntas frecuentes

¿Cómo evitar que un RFP lo ate a su arquitectura tecnológica actual?

Redacte cada requisito enfocado en el resultado que el equipo de crédito debe lograr tras la migración (por ejemplo, cambiar y probar una política sin tener que abrir un ticket con el proveedor) y mantenga las limitaciones de integración en una lista separada. Pida a cada proveedor que demuestre cada resultado esperado con sus propios datos. Describa el sistema actual con precisión y justifique el cambio a partir de las necesidades del modelo operativo post-migración.

¿Se debe enviar el RFP también al proveedor actual?

Sí, siempre y cuando la entidad financiera considere seriamente la opción de continuar con él. Las respuestas del proveedor actual permitirán ver si su motor puede adaptarse al modelo operativo que necesitan tras la migración, y someterlo a la misma prueba de concepto garantiza una evaluación justa y transparente. Si no cumple con los requisitos indispensables, el RFP dejará documentados los motivos claros para realizar el cambio.

¿Qué puede demostrar una prueba de concepto antes del contrato y qué no?

Una prueba con sus propias solicitudes reales puede mostrar las decisiones que toma el motor, los motivos que genera y cómo se modifica, prueba y publica una política de crédito. No puede predecir el comportamiento de pérdidas a largo plazo, ya que estas solo se observan con la maduración de los créditos en el tiempo. La evidencia sobre pérdidas proviene del análisis retrospectivo (backtest), que se ejecuta sobre solicitudes del pasado cuyos resultados reales ya se conocen.

¿Sigue vigente la guía de terceros de 2023 para la compra de un motor de decisión?

Sí, al 28 de septiembre de 2026: la Guía Interinstitucional sobre Relaciones con Terceros: Gestión de Riesgos de junio de 2023 está vigente para los bancos regulados, y el RFP de un motor de decisión es donde inicia su etapa de debida diligencia. El 11 de septiembre de 2026, la FDIC, la Reserva Federal, la NCUA y la OCC propusieron una guía de reemplazo, y las agencias planean revocar la de 2023 una vez aprobada la versión final. Verifique qué versión aplica cuando envíe su RFP.

¿Se puede apagar el motor antiguo tan pronto como el nuevo esté en vivo?

Solo después de haber resuelto dónde se almacenará su histórico de datos. La Regulación B exige conservar las solicitudes, la información de evaluación y las notificaciones enviadas durante 25 meses para crédito de consumo y 12 meses para crédito comercial (con excepciones), por lo que el histórico que no se migre al nuevo motor debe seguir disponible para consulta en algún lugar. El RFP debe especificar qué se migra, qué permanece y quién asume los costos de esa consulta.

Por dónde empezar con un RFP para un motor de decisión crediticia

Comience revisando los requisitos que han sido copiados del sistema actual. Reformule cada uno de ellos como un resultado que el equipo de crédito debe lograr tras la migración, asocie las métricas de prueba que considerará válidas y defina las ponderaciones de evaluación antes de enviar el RFP. Luego, añada la cláusula de prueba de concepto y las condiciones de migración, que son mucho más fáciles de negociar antes de la firma del contrato.

Si Oscilar está entre sus opciones finalistas, envíele este mismo RFP y las condiciones de la prueba de concepto. La sección sobre originación de crédito B2B de Oscilar detalla cómo gestiona las decisiones de crédito comercial.