La Soberanía Financiera Requiere Infraestructura Soberana: Por Qué el Fintech Europeo Necesita Banca Central Construida en Europa
La soberanía financiera requiere independencia a nivel de infraestructura. Un ledger alojado en infraestructura de nube estadounidense, enrutando pagos a través de redes controladas por Estados Unidos, gobernado por capital liderado desde Estados Unidos, no es soberano independientemente de dónde esté constituido el banco.
La dependencia es medible. El 63% de la infraestructura de nube europea opera en proveedores controlados por Estados Unidos. Más del 90% de las transacciones con tarjeta en Europa se enrutan a través de Visa y Mastercard. Cada ronda de financiación de más de mil millones de euros en fintech europeo en 2025 fue liderada por inversores estadounidenses. Desaparecerían 9.000 millones de euros en financiación anual si el capital estadounidense se retirara del fintech europeo. La dependencia de infraestructura y la dependencia de capital no son problemas separados. Se refuerzan mutuamente. Los proveedores financiados por capital estadounidense están sujetos a presión regulatoria estadounidense, controles de exportación estadounidenses y jurisdicción de tribunales estadounidenses, independientemente de dónde estén ubicados sus servidores.
DORA transforma esto de una preferencia geopolítica en un requisito regulatorio.
Las Tres Capas de Dependencia
Las instituciones financieras europeas enfrentan dependencias de infraestructura en tres capas distintas. Cada capa tiene implicaciones legales diferentes, diferentes exposiciones a DORA y diferentes plazos de remediación.
Capa 1: Infraestructura de nube. AWS, Azure y Google Cloud proporcionan la mayor parte de la infraestructura de cómputo, almacenamiento y red para instituciones financieras europeas. Estos proveedores operan centros de datos en Europa, pero las entidades matrices son corporaciones estadounidenses sujetas a jurisdicción estadounidense. La Ley CLOUD (2018) permite a las autoridades de aplicación de la ley de Estados Unidos obligar a los proveedores de nube estadounidenses a divulgar datos almacenados en cualquier parte del mundo, incluidos centros de datos europeos, sin requerir un proceso legal europeo. La residencia de datos en Frankfurt no crea soberanía de datos si la matriz estadounidense del proveedor puede ser obligada a producirlos.
El Artículo 28 de DORA requiere que las entidades financieras evalúen y monitoreen los riesgos de terceros proveedores de ICT, incluido el riesgo de concentración. El Artículo 30 requiere acuerdos contractuales escritos con proveedores de ICT que incluyan derechos de auditoría, requisitos de ubicación de datos, disposiciones de estrategia de salida y el derecho a realizar pruebas de penetración. Para los proveedores de nube estadounidenses, el derecho de auditoría es real, pero lo que una institución europea encuentra cuando audita puede ser un sistema que no puede modificar, no puede migrar rápidamente y no puede evaluar completamente porque la arquitectura interna del proveedor es propietaria.
Capa 2: Redes de pago. Visa y Mastercard procesan más del 90% de las transacciones con tarjeta en Europa. Ambas son corporaciones estadounidenses. SWIFT, que enruta mensajería interbancaria, está constituida en Bélgica pero gobernada por una junta con participación significativa estadounidense y históricamente sujeta a presión del gobierno estadounidense. En 2012, el Departamento del Tesoro de Estados Unidos obligó a SWIFT a cortar a Irán de su red, afectando la capacidad de los bancos europeos de procesar transacciones legítimas con contrapartes iraníes.
SEPA proporciona infraestructura operada por europeos para transferencias de crédito y domiciliaciones. El Banco Central Europeo opera TARGET2 (y su sucesor T2) para pagos de alto valor en euros. Pero los pagos con tarjeta, que representan la mayoría del volumen de transacciones de consumo, no tienen una alternativa operada por europeos con volumen comparable. La EPI (European Payments Initiative) está construyendo Wero como alternativa de pago con tarjeta, pero cubre una fracción del volumen actual de Visa/Mastercard a mediados de 2026.
Capa 3: Capital y gobernanza. Los proveedores de infraestructura están sujetos a las prioridades de gobernanza de sus proveedores de capital. Un fintech europeo financiado principalmente por capital de riesgo estadounidense enfrentará presión para expandirse a mercados estadounidenses, adoptar valores predeterminados de infraestructura estadounidenses y aceptar términos contractuales estándar estadounidenses, incluidos términos de datos que pueden entrar en conflicto con GDPR y DORA.
El informe State of European FinTech 2026 de Finch Capital cuantifica la brecha de capital: podrían desbloquearse 37.500 millones de euros al año si los fondos de pensiones europeos igualaran las tasas de asignación de fintech de sus contrapartes estadounidenses. Esa brecha no está cubierta. El resultado es una dominación de capital liderada por Estados Unidos continuada en la etapa de crecimiento, que se traduce en gobernanza orientada a Estados Unidos en las empresas que construyen la infraestructura financiera europea.
Qué Significa la Infraestructura Soberana Técnicamente
La soberanía no es una certificación ni una bandera en un centro de datos. A nivel de infraestructura, requiere cuatro propiedades específicas.
Residencia de datos con control jurisdiccional. Los datos deben almacenarse dentro de la UE/EEE bajo una entidad legal sujeta exclusivamente a jurisdicción de la UE. Esto significa que la empresa matriz del proveedor de nube, no solo la subsidiaria operativa, debe estar vinculada por los requisitos de protección de datos de la UE. La German Sovereign Cloud (operada por T-Systems y SAP en infraestructura Azure) intenta esto a través de un modelo donde Microsoft no tiene acceso a los datos sin aprobación del fiduciario alemán. Las ofertas de EU Sovereign Cloud de AWS y Google son arquitectónicamente similares. Cada modelo proporciona soberanía parcial: tecnología de origen estadounidense con superposición de gobernanza europea.
Acceso de auditoría sin control del proveedor. El Artículo 30(2)(d) de DORA requiere que la entidad financiera pueda auditar a su proveedor de ICT, directamente o a través de un tercero. Para infraestructura de caja negra donde el código fuente, la cadena de dependencias y el comportamiento en tiempo de ejecución son propietarios, este derecho de auditoría es nominal. Un auditor puede verificar que el sistema produce las salidas esperadas; no puede verificar cómo. Un sistema con código fuente publicado, cadena de dependencias documentada y comportamiento determinista puede ser auditado por completo. El derecho de auditoría es sustancial, no nominal.
Transparencia de la cadena de suministro. El Artículo 9 de DORA requiere la evaluación del riesgo de la cadena de suministro. Para un sistema de banca central, la cadena de suministro incluye cada biblioteca de la que depende el sistema, cada servicio de terceros que llama, y cada procesador de datos a través del cual enruta datos. Un sistema con 5.000 dependencias transitivas no puede tener su cadena de suministro auditada de manera significativa: el grafo de dependencias es demasiado grande para razonar sobre él. Un sistema con 30 dependencias transitivas en su núcleo financiero puede hacerlo.
Estrategia de salida con costo de migración acotado. El Artículo 28(7) de DORA requiere que el riesgo de concentración sea gestionado, lo que incluye la capacidad de salir de un proveedor de ICT crítico sin una interrupción operativa inaceptable. Para un sistema de banca central construido sobre la pila de un proveedor propietario (APIs personalizadas, formatos de datos propietarios, herramientas específicas del proveedor), el costo de salida se mide en años y decenas de millones de euros. Para un sistema con interfaces estándar (ISO 20022, APIs abiertas), formatos de datos abiertos y modelos de despliegue portables, el costo de salida está acotado.
Las Disposiciones de DORA sobre Riesgo de Concentración
El Artículo 28(5) de DORA aborda explícitamente el riesgo de concentración en dependencias de terceros proveedores de ICT. Las Autoridades Supervisadoras Europeas están facultadas para designar proveedores de servicios de terceros de ICT críticos (CTPPs) e imponer requisitos de supervisión adicionales, incluidas pruebas de resiliencia, planificación de salida e informes operativos.
Para instituciones financieras europeas, el análisis de riesgo de concentración tiene dos dimensiones. Primero, si algún proveedor de ICT individual representa una dependencia sistémica: si ese proveedor falla o se vuelve indisponible, ¿falla también la institución? Segundo, si el sector financiero de la UE en su conjunto tiene una concentración excesiva en algún proveedor o categoría de proveedor individual.
Las ESAs publicaron su primer análisis CTPP en 2025 y encontraron concentración significativa en nube y tecnología de banca central. La respuesta regulatoria no es mandatar el cambio de proveedor, sino exigir que las instituciones puedan demostrar que han evaluado el riesgo y tienen estrategias de salida plausibles. Una institución que no puede articular una ruta de migración a otro proveedor de banca central porque la arquitectura del proveedor actual es incompatible con cualquier alternativa tiene un riesgo de concentración que DORA exige que documente y aborde.
El Argumento de la Arquitectura Transparente
El argumento de soberanía no se trata principalmente de dónde está ubicada físicamente la infraestructura. Se trata de si la infraestructura puede ser auditada por completo, operada independientemente y migrada en una línea de tiempo definida.
Un sistema de banca central construido en Europa, ejecutándose en proveedores de nube europeos, con código fuente propietario y opaco proporciona garantías de soberanía más débiles que un sistema construido en cualquier lugar con arquitectura publicada, interfaces documentadas, dependencias externas mínimas y formatos de datos estándar. La jurisdicción de constitución es una propiedad legal. La auditabilidad de la arquitectura es una propiedad operativa. A los reguladores bajo DORA les importa la propiedad operativa.
La pregunta práctica para un CTO que evalúa infraestructura de banca central: ¿puede satisfacer los requisitos de acceso de auditoría, transparencia de cadena de suministro y estrategia de salida de DORA con su proveedor actual? Si la respuesta requiere confianza en las afirmaciones del proveedor en lugar de verificación de su propia auditoría, la arquitectura no satisface el requisito. El requisito es evidencia, no afirmación.
Compromisos
La soberanía de infraestructura tiene costos que son reales y no deben minimizarse.
Selección de proveedores más estrecha. Los proveedores de nube bajo jurisdicción europea tienen menos capacidad y menos regiones geográficas que los hyperscalers estadounidenses. Una estrategia de nube puramente europea puede significar aceptar costos de infraestructura de línea base más altos, menos ubicaciones de edge y servicios administrados menos maduros.
Complejidad de migración. Moverse de un proveedor de nube estadounidense establecido a una alternativa europea es un proyecto de varios trimestres que involucra evaluación servicio por servicio, renegociación de contratos de proveedor y validación operativa. Para instituciones con años de inversión en herramientas de nube estadounidenses, el costo de cambio es alto.
Las alternativas de red de pago están incompletas. Wero y otras iniciativas de pago europeas abordan parte de la dependencia de Visa/Mastercard, pero la cobertura es parcial a mediados de 2026. Una institución aún no puede construir una pila de infraestructura de pago completamente europea que iguale la aceptación y el volumen de las redes dominadas por Estados Unidos.
Incertidumbre regulatoria. El marco CTPP de las ESAs aún está siendo operacionalizado. Lo que constituye documentación de estrategia de salida suficiente, riesgo de concentración aceptable y acceso de auditoría adecuado no ha sido definido uniformemente entre jurisdicciones. Construir infraestructura para satisfacer un requisito regulatorio que aún se está escribiendo requiere diseño para flexibilidad, no para una especificación fija.
Fernel Context
El núcleo financiero de Fernel está construido en Zig con un recuento de dependencias de aproximadamente 30 dependencias transitivas. La arquitectura está publicada: tres capas estrictamente aisladas con interfaces documentadas, modelos de datos nativos ISO 20022 y contratos de API estándar que no son propietarios. El código fuente y el inventario de dependencias están disponibles para auditoría sin control del proveedor. El despliegue es portable entre proveedores de nube. No se requiere runtime de proveedor: ningún servicio administrado propietario, ningún entorno de ejecución de caja negra que la institución no pueda inspeccionar o reemplazar.
Leer más: Seguridad y Compliance | La Arquitectura de un Sistema Operativo Financiero | DORA para Proveedores de Infraestructura Financiera
Fuentes:
- Finch Capital, State of European FinTech 2026: datos de concentración de nube, análisis de brecha de capital, dependencia de financiación de 9.000 millones de euros
- DORA, Reglamento (UE) 2022/2554, Art. 28 (Gestión de Riesgos de Terceros Proveedores de ICT), Art. 28(5) (Riesgo de Concentración), Art. 28(7) (Estrategias de Salida), Art. 30 (Acuerdos Contractuales), Art. 9 (Riesgo de Cadena de Suministro)
- Ley CLOUD de Estados Unidos, Pub. L. 115-141 (2018), disposiciones de acceso a datos transfronterizos
- SWIFT y sanciones contra Irán: acción OFAC del Departamento del Tesoro de Estados Unidos, 2012, precedente para control extraterritorial de red de pagos
- European Payments Initiative (EPI), documentación del producto Wero (2025-2026)
- ESAs, Marco de Supervisión de Proveedores de Terceros de ICT Críticos (CTPP), análisis inicial de designación 2025
- ECB TARGET2 y consolidación T2: documentación operativa