Cómo Construiría un Sistema de Financiación para Pymes que No Rehace el Mismo Expediente

Respuesta Directa

Un sistema de financiación para pymes que nunca reconstruye el mismo expediente separa tres cosas que el proceso actual fusiona en un solo montón de documentos: los hechos financieros verificados (ingresos, situación fiscal, propiedad, deuda existente, cada uno con una fuente y una fecha), la interpretación que se aplica sobre esos hechos (ratios, tendencias, comparación sectorial), y la política de riesgo de cada banco (apetito de riesgo, precio, garantías personales). Se supone que solo la capa de política debería diferir entre bancos. Hoy las tres se reconstruyen cada vez.

Puntos Clave

• Una empresa que solicita financiación a tres bancos reúne prácticamente el mismo expediente tres veces, y ese trabajo no es reutilizable, ni siquiera por la propia empresa que lo produjo.
• La redundancia no es pereza. Las normas contra el blanqueo de capitales exigen que cada entidad regulada realice su propia diligencia debida del cliente, así que ningún banco puede simplemente heredar el expediente de otro.
• El objeto reutilizable es la identidad financiera verificada de la empresa, no la solicitud de préstamo: hechos, con fuente y fecha, que cualquier contraparte podría consumir.
• El open banking ya permite a una empresa compartir datos de transacciones en vivo con más de un prestamista a través de una API. Todavía no cubre la situación fiscal, la propiedad ni la deuda existente.
• El cuello de botella que debería asumir un sistema nativo en IA es la recopilación de hechos y su trazabilidad, no el criterio de riesgo: eso se queda en el banco.

¿Qué problema asume realmente este sistema?

Una pequeña empresa que busca financiación no tiene una solicitud de préstamo. Tiene la misma imagen de evaluación crediticia, construida desde cero, una vez por cada banco al que se dirige. Estados financieros, un certificado de estar al corriente de pagos con Hacienda, doce meses de movimientos bancarios, prueba de propiedad, una descripción del destino del préstamo, la lista casi no cambia del Banco A al Banco B y al Banco C. Lo que cambia es el portal donde se sube y el analista que hace una pregunta de seguimiento ligeramente distinta sobre las mismas cifras.

El sistema que yo construiría no toca la evaluación de riesgo. El apetito de riesgo de un banco, su precio, su comodidad con un sector determinado: eso es genuinamente propietario, y debe seguir siéndolo. Lo que el sistema asume es más estrecho y menos vistoso: recopila los hechos una vez, los mantiene actualizados, y deja que la empresa decida quién ve cada porción de ellos.

Es un problema de coordinación disfrazado de problema crediticio. La empresa tiene los hechos. Tres bancos distintos quieren los mismos hechos, verificados a su manera, en tres sistemas distintos que nunca se comunican entre sí. Nadie posee la versión que permitiría a un segundo banco confiar en el trabajo del primero, así que nadie la construye, y la empresa sigue reescribiendo su propio NIF en un cuarto portal.

El flujo de trabajo actual que mapearía primero

empresa → reúne expediente → analista banco A → preguntas → más documentos → decisión
        → reúne expediente → analista banco B → preguntas → más documentos → decisión
        → reúne expediente → analista banco C → preguntas → más documentos → decisión

Cada paso por ese bucle repite las mismas categorías de trabajo:

1. Identidad y propiedad: quién posee la empresa, quién puede firmar en su nombre, si alguien en el accionariado aparece en una lista de sanciones o de personas políticamente expuestas.
2. Situación fiscal y regulatoria: si la empresa está al corriente de sus declaraciones, si tiene obligaciones pendientes con Hacienda.
3. Desempeño financiero: ingresos, márgenes, deuda existente, flujo de caja en el historial comercial reciente.
4. Historial de transacciones: los movimientos bancarios reales que un prestamista lee para verificar las cifras de los estados financieros.
5. Uso de fondos y contexto de negocio: por qué existe el préstamo y qué hará la empresa con él.

Antes de asumir que esto puede automatizarse sin más, vale la pena preguntar por qué cada banco insiste en hacer su propia versión de los pasos 1 a 4. La respuesta honesta es regulatoria, no administrativa. La Recomendación 10 del Grupo de Acción Financiera Internacional (GAFI) exige que una entidad regulada identifique y verifique a sus propios clientes y a sus titulares reales antes de iniciar una relación de negocio, en lugar de basarse en la comprobación previa de otra entidad. Cada banco es examinado de forma independiente sobre su propio expediente, así que cada banco construye su propio expediente. Es una restricción real, y cualquier diseño nativo en IA tiene que trabajar con ella, no fingir que no existe.

El paso 5, en cambio, no es en absoluto un requisito regulatorio. Es una narrativa que un analista de crédito quiere leer, construida a partir de hechos que la empresa ya declaró en algún punto de los pasos 1 a 4.

Cómo funcionaría el sistema

Separa el montón en tres capas, porque solo una de ellas se supone que debe reconstruirse en cada banco.

La identidad financiera verificada de la empresa se construye una vez, a partir de fuentes primarias: un flujo desde su sistema contable, una consulta al registro mercantil para propiedad y depósitos, un extracto de Hacienda sobre situación fiscal, y acceso con consentimiento de open banking a los datos de transacciones. Cada hecho lleva consigo de dónde procede y cuándo se confirmó por última vez, no solo una cifra.

Bajo la Directiva revisada de Servicios de Pago de la UE, PSD2, una empresa ya puede autorizar a un banco u otro proveedor regulado a leer sus datos de transacciones mediante una API segura, con base en su propio consentimiento, en lugar de exportar extractos y volver a subirlos a mano. Esa pieza de infraestructura existe y funciona hoy; simplemente se detiene en los datos de transacciones. El sistema que describo extiende la misma idea (acceso trazado, fechado y con alcance limitado por consentimiento) a las demás categorías de hechos que necesita un prestamista: propiedad, situación fiscal, obligaciones existentes.

Cuando la empresa solicita financiación a un segundo o tercer banco, concede a ese banco acceso limitado y con caducidad a los hechos vigentes en lugar de reunir un nuevo expediente. Los propios sistemas del banco calculan la capa de interpretación a partir de esos hechos, los ratios y las líneas de tendencia que le interesan, y aplican su propia política encima. El portal de subida desaparece. El NIF vuelto a teclear desaparece. La decisión crediticia en sí no desaparece, y no debería.

Hice una versión de esta misma separación entre hechos e interpretación cuando analicé cómo un sistema de marcado CE mantendría vivo el expediente técnico de un producto en lugar de reconstruirlo en cada auditoría, y de nuevo en cómo un sistema de diligencia debida inmobiliaria reuniría los datos registrales una sola vez para que un profesional los firmara. El patrón se sostiene aquí por la misma razón que se sostiene allí: los hechos son baratos de mantener actualizados una vez que alguien asume ese trabajo, y caros solo porque ahora mismo nadie lo asume.

¿Qué permanece bajo control humano?

La decisión crediticia permanece por completo en la función de crédito con licencia del banco. Nada en una capa de hechos compartida cambia quién tiene permiso para aprobar un préstamo, fijarle un precio o ponerle condiciones: eso es la capa de política, y se supone que sigue siendo propietaria y humana.

Verificar la titularidad real frente a listas de sanciones y de personas políticamente expuestas sigue siendo una función de cumplimiento regulada. No desaparece porque los hechos estén mejor organizados; se ejecuta sobre datos más recientes y trazados en lugar de un PDF vuelto a teclear, lo cual es una afirmación mucho más limitada que “la IA hace el cumplimiento”.

El consentimiento permanece explícito y con alcance limitado, no general. La Autoridad de Conducta Financiera del Reino Unido (FCA) describe el open banking como una forma regulada de que un cliente o una empresa comparta datos de su cuenta con un tercero autorizado, sobre la base de un consentimiento explícito, en lugar de entregarle sus credenciales bancarias: la empresa decide qué ve un banco determinado y durante cuánto tiempo, y esa decisión tampoco se automatiza. Una capa de hechos que comparte todo con todos por defecto no es un sistema de financiación; es una fuga de datos con una presentación de ventas.

Esto es un modelo diseñado, no un sistema que haya construido. Sigue siendo un modelo hasta que alguien que se dedica de verdad a la evaluación de riesgo de préstamos a pymes me diga dónde se rompe la realidad regulatoria o comercial.

Cuándo esta es la construcción equivocada

Si una empresa toma préstamos de un solo banco durante toda su vida y nunca compara opciones ni refinancia, el coste de coordinación nunca se acumula. No hay nada que reutilizar, porque solo existe una versión del expediente que se construye, y montar un objeto de hechos compartido para una única relación es sobrecarga sin ninguna contraparte que la amortice.

También falla donde un regulador exige que el banco obtenga los documentos originales directamente, sin tolerancia para un resumen certificado por un tercero, por bien fundamentado que esté. En ese caso el sistema sigue ayudando, automatiza la recuperación y mantiene los hechos actualizados, pero no elimina el requisito en sí, y afirmar lo contrario sería el tipo de afirmación de eficiencia que no sobrevive al contacto con un responsable de cumplimiento real.

Y es la construcción equivocada para quien lo lea como “vender a los bancos un atajo de KYC”. La pregunta comercial y regulatoria de en quién se confía para custodiar los hechos verificados de una empresa, y bajo qué responsabilidad, sigue abierta. Esa pregunta hay que responderla investigando cómo piensan realmente los equipos de cumplimiento de los bancos sobre la certificación por terceros, no diseñando alrededor de ella.

Cómo se conecta esto con el trabajo

Esta radiografía sigue la misma separación que usé en el sistema de reservas de carga que oculta la capa de coordinación bajo un botón y en el sistema de calificación de licitaciones públicas construido alrededor del propio expediente de capacidad de una empresa: encontrar la capa que es genuinamente propietaria, y dejar de reconstruir todo lo demás a su alrededor.

Si una versión de este patrón de reconstruir expedientes ya existe en tu empresa como PDFs y portales, describe el cuello de botella. Si solo quieres la próxima radiografía, la newsletter basta.

Resumen

El expediente de préstamo para pymes se reconstruye en cada banco porque cada entidad es responsable de su propia exposición regulatoria, no porque los hechos subyacentes hayan cambiado. Separar hechos, interpretación y política lo hace visible: se supone que solo la tercera capa debería diferir entre prestamistas, y hoy las tres se reconstruyen de todos modos. Un sistema que recopila los hechos una vez, los mantiene fechados y trazados, y deja que la empresa conceda acceso limitado por banco elimina el trabajo repetitivo sin tocar la parte que debe seguir siendo criterio propio del banco.