Apps FinTech e InsurTech en 2026: cómo cumplir DORA, PSD3 y AI Act sin frenar el roadmap
Si construyes una app financiera o de seguros para el mercado europeo, en 2026 el cumplimiento dejó de ser un anexo legal para convertirse en requisitos de arquitectura. Tres marcos convergen sobre tu producto —DORA, PSD3 y el AI Act— y buena parte de sus exigencias se traducen en decisiones de ingeniería que es mucho más barato tomar al diseñar que al parchear. Esta es la lectura para CTOs y responsables de producto, sin humo legal.
Qué cambia, en una frase por marco
- DORA (en vigor desde el 17 de enero de 2025): resiliencia operativa digital. Tu software suele ser un "tercero ICT" para la entidad financiera que lo usa, y eso te llega por contrato.
- PSD3: endurece la autenticación del cliente y ordena el intercambio seguro de datos entre bancos, proveedores de pago y terceros.
- AI Act: obligaciones de transparencia sobre contenido e interacciones generadas por IA, plenamente exigibles desde agosto de 2026.
La dificultad no es cada marco por separado, sino su convergencia: una misma funcionalidad puede tocar los tres a la vez.
DORA: tu app es el "tercero ICT"
Aquí está el matiz que muchos equipos de desarrollo pasan por alto. DORA no impone obligaciones directas a proveedores de software: se las impone a las entidades financieras, que te las trasladan por contrato. Si vendes a un banco o aseguradora, vas a firmar cláusulas del Artículo 30 sobre ubicación de datos, derechos de auditoría y estrategias de salida.
Qué implica en la práctica de ingeniería:
- Registro de terceros ICT: tu cliente debe declarar tu servicio en su Register of Information, en formato EBA, que las autoridades consolidan y remiten a las ESAs antes del 31 de marzo de cada año. Necesitas darle datos limpios: subprocesadores, regiones, dependencias cloud.
- Testing: los sistemas ICT críticos exigen evaluación de vulnerabilidades al menos anual; y si entras en el alcance de Threat-Led Penetration Testing (TLPT), un test certificado TIBER-EU cada tres años.
- Cadena de dependencias: en noviembre de 2025 las ESAs designaron a los primeros 19 Proveedores Críticos (CTPPs) —AWS, Google Cloud, Microsoft, Oracle, SAP, entre otros— bajo supervisión directa de la UE. Saber sobre qué CTPP corres deja de ser un detalle de infraestructura.
PSD3: autenticación y datos, de nuevo bajo el foco
PSD3 aprieta la Autenticación Reforzada de Cliente (SCA) y el intercambio de datos con terceros. Para el equipo de producto esto significa revisar flujos de login, pago y consentimiento: menos fricción innecesaria donde la norma lo permite, pero trazabilidad completa donde la exige. Hay una paradoja que conviene tener presente: PSD3 refuerza la protección antifraude justo cuando la IA generativa facilita estafas hiperpersonalizadas, así que la defensa antifraude basada en IA pasa de "nice to have" a expectativa regulatoria.
AI Act en finanzas: transparencia por diseño
Si tu app usa un chatbot, scoring, o cualquier salida generada por IA de cara al usuario, el Artículo 50 te obliga a que la persona sepa que está interactuando con una IA y a marcar el contenido generado. Bien resuelto, esto es una capa de UX y de logging, no un freno: chatbots que generan automáticamente trazas de auditoría, resúmenes de transacción compatibles con PSD3, y que marcan las interacciones que necesitan revisión humana bajo el Artículo 22 del RGPD.
De regulación a backlog: qué implementas
| Marco | Qué exige | Qué construyes |
|---|---|---|
| DORA | Resiliencia y control de terceros ICT | Logs de incidentes exportables, datos de subprocesadores, pruebas de vulnerabilidad periódicas, estrategia de salida documentada |
| PSD3 | SCA y acceso seguro a datos | Flujos de autenticación robustos, consentimiento auditable, antifraude |
| AI Act | Transparencia de IA | Aviso de interacción con IA, marcado de contenido, trazas y ruta de revisión humana |
Cuándo NO sobre-ingenierizar
Cumplir no es blindar todo por igual. Si no vendes a entidades financieras reguladas, DORA no te llega directamente —y montar un aparato de resiliencia de nivel bancario en una app que no lo necesita es quemar presupuesto. Igual con el AI Act: las obligaciones más duras recaen sobre sistemas de alto riesgo y modelos de propósito general; una funcionalidad de IA acotada y transparente rara vez cae ahí. La regla es proporcionalidad: clasifica primero tu exposición real y dimensiona el esfuerzo a esa exposición, no al titular más alarmista.
Cómo lo abordamos en Dribba
Construimos producto desde 2011 y trabajamos con clientes en verticales financieros y de comparación, donde el cumplimiento y el time-to-market tiran en direcciones opuestas. Nuestra postura es de compliance-by-design: meter estos requisitos en la arquitectura desde el discovery —no como una auditoría de última hora— para que la conformidad salga casi gratis del buen diseño. Si ya cubrimos qué cambia con el EU AI Act para tu app, esta es la capa financiera de la misma historia.
Conclusión
DORA, PSD3 y AI Act no son tres proyectos legales: son un conjunto de decisiones de arquitectura que, tomadas a tiempo, apenas cuestan y, tomadas tarde, duelen. La clave es clasificar tu exposición, diseñar para la conformidad y medir la proporcionalidad.
¿Estás construyendo una app FinTech o InsurTech para el mercado europeo? En Dribba integramos el cumplimiento en el producto sin frenar el roadmap. Hablemos.
