Estudio de desarrollo fintech: qué verificar en KYC, PSD3 y DORA

Un estudio de desarrollo fintech es un equipo de producto que diseña y construye software financiero regulado llevando las exigencias de cumplimiento (verificación de identidad, permisos de pago, resiliencia operativa, accesibilidad) dentro de la interfaz y del código, en lugar de añadirlas en una revisión previa al lanzamiento. La distinción importa en 2026 porque las reglas europeas bajo las que opera una fintech se están reescribiendo en cinco calendarios distintos, y tres llegan después de que salga un producto empezado este año.

Esto es una guía para quien contrata. Cubre qué cambió entre 2025 y 2028, las cuatro preguntas que conviene hacer antes de firmar, y dónde está la frontera entre quien desarrolla, la entidad autorizada y los abogados que hacen falta igualmente.

Qué hace un estudio fintech que no hace uno generalista

Un panel, un registro y un cobro con tarjeta los desarrolla cualquier estudio solvente. Un producto financiero regulado añade tres obligaciones que cambian la forma del software: hay que verificar y volver a verificar la identidad del usuario, el movimiento de dinero tiene que apoyarse en la licencia de alguien, y el sistema entero tiene que aguantar a un supervisor que pide pruebas documentadas, no capturas de pantalla.

Esas obligaciones mueven decisiones corrientes. El registro deja de ser un formulario de tres campos y pasa a ser una máquina de estados con una cola de revisión manual detrás. La base de datos deja de ser un único esquema y suma un libro mayor de solo adición, donde nadie actualiza una fila existente. El canal de incidencias deja de ser un hilo de Slack y pasa a ser una obligación de notificación con un reloj encima. Quien nunca ha trabajado con estas restricciones presupuesta bien el panel y se encuentra el resto en el tercer mes.

Qué cambió en Europa entre 2025 y 2028

El marco lo fijan cinco fechas. Dos ya pasaron, y dos de las tres restantes llegan cuando los productos empezados en 2026 ya estén en línea: por eso entran hoy en la conversación de arquitectura.

• DORA se aplica desde el 17 de enero de 2025. Las entidades financieras deben gobernar el riesgo de sus proveedores TIC, mantener un registro de información de cada acuerdo, clasificar y notificar incidentes y tener planes de salida para los proveedores de los que dependen. En noviembre de 2025 las autoridades europeas de supervisión publicaron la primera lista de proveedores TIC designados como críticos, y el régimen pasó de la orientación a la supervisión efectiva (EIOPA, DORA).
• La Ley Europea de Accesibilidad se aplica desde el 28 de junio de 2025. Entran los servicios bancarios para consumidores, los terminales de pago y el comercio electrónico financiero: es decir, la app, la web, los extractos, la atención al cliente y el proceso de baja (Bird & Bird). La vía práctica hacia la conformidad es la norma EN 301 549 v3.2.1, que recoge íntegras las WCAG 2.1 nivel AA y añade requisitos de hardware, documentación y software no web (ETSI EN 301 549 v3.2.1).
• Las reglas europeas contra el blanqueo se aplican desde el 10 de julio de 2027. Un solo reglamento sustituye las transposiciones nacionales divergentes que hoy se revisan país por país. La Autoridad europea contra el blanqueo funciona desde Fráncfort desde el 1 de julio de 2025 y a partir de enero de 2028 supervisa directamente hasta 40 grupos transfronterizos, seleccionados durante 2027 (AMLA).
• La PSD3 y el reglamento de servicios de pago cerraron la negociación. Parlamento y Consejo alcanzaron el acuerdo provisional en noviembre de 2025 y el Coreper respaldó los textos en abril de 2026. La publicación en el Diario Oficial se espera en la segunda mitad de 2026 y las reglas de fondo apuntan a aplicarse hacia 2028, cuando venza el plazo de transposición de la directiva (Norton Rose Fulbright).
• Las carteras de identidad digital europeas deben ofrecerse antes del 24 de diciembre de 2026. Bancos, entidades de pago y entidades de dinero electrónico tendrán que aceptarlas como medio de identificación y de autenticación reforzada aproximadamente un año después. En agosto de 2026 varias carteras nacionales iban con retraso, y Alemania fijó el 2 de enero de 2027 para la suya (Forbes).

Cómo se comprueba que un estudio tiene experiencia fintech real

Cuatro preguntas separan a quien ha lanzado un producto regulado de quien ha leído sobre ello. Hazlas en una llamada, no dentro de un pliego, y escucha cuánta concreción traen las respuestas.

1. Sobre qué licencia funciona el producto

Hay dos formas. En el modelo de agente distribuyes los permisos de una entidad ya autorizada: la responsabilidad de la actividad regulada se queda en el principal y no puedes ofrecer nada fuera de su alcance, y por eso esta vía sale en semanas. En el modelo directo eres tú quien obtiene la licencia de entidad de pago o de dinero electrónico, y el calendario cambia por completo. Las guías de licencias sitúan la tramitación en torno a tres o seis meses en Lituania y entre doce y dieciocho meses ante el regulador británico, antes incluso de que empiece el desarrollo (Crassula, guía de licencia EMI).

Un estudio que no sepa decirte en cuál de las dos formas encaja tu producto, y qué implica cada una en el alta de usuarios, no ha hecho ninguno. Los dos modelos dan altas distintas, plazos de conservación distintos, conciliaciones distintas y estados de error distintos.

2. Si el KYC es una pantalla o un sistema de decisión

Las demos de los proveedores enseñan siempre el camino limpio: solicitante en regla, foto nítida del documento, marca verde en once segundos. La ingeniería está en los demás estados. Un perfil con muy poco historial verificable. Un documento que se lee mal desde un móvil viejo con poca luz. Un nombre que aparece en una lista de sanciones o de personas expuestas políticamente y exige una decisión humana. Un rechazo que hay que comunicar sin detallar el motivo.

Pide al estudio que te recorra esos cuatro estados y el ciclo de revisión del analista, no la integración del SDK. En un producto regulado, la conversión del alta se decide casi entera en los estados feos, que son los que nadie prototipa.

3. Qué aspecto tiene la trazabilidad

DORA convirtió la gestión de proveedores y de incidentes en deberes documentados con artefactos de nombre propio: registro de información, derechos contractuales de auditoría y de salida, clasificación de incidentes frente a las ventanas de notificación. Traducido a producto: cada cambio de estado necesita un evento duradero con actor, momento y motivo, y la base de datos de la aplicación no es el libro de la verdad del dinero.

Añadir un registro de eventos a una aplicación CRUD después del lanzamiento es una reescritura, no un sprint. Pide ver cómo modeló el estudio los eventos y el libro mayor en un proyecto ya entregado. Si la respuesta es updated_at, ya lo sabes.

4. Dónde vive la accesibilidad

Desde junio de 2025 las reglas de accesibilidad cubren toda la parte de los servicios bancarios dirigida al consumidor, y los trozos que los equipos olvidan son los extractos, el terminal, la atención y la baja. Pregunta qué vía de conformidad sigue el estudio, quién ejecuta las pruebas y si el contraste, el orden de foco y el tamaño de los objetivos se deciden una vez en el design system o se vuelven a decidir en cada pantalla. Lo contamos en diseño accesible tras la EU Accessibility Act.

Qué no debe venderte un estudio fintech

Un estudio no es un despacho de abogados, no es una consultora de cumplimiento y no es una licencia. Quien ofrece el visto bueno regulatorio junto con el desarrollo está vendiendo algo que no le pertenece, y las consecuencias se quedan con quien contrata.

El reparto que aguanta es este: la interpretación de las reglas corresponde a tus abogados y a tu responsable de cumplimiento, los permisos a la entidad autorizada, y el producto que tiene que satisfacer a ambos (más las pruebas que lo demuestran) al estudio. La interpretación se pide por escrito a quien está cualificado para darla y luego se entrega al equipo de desarrollo como restricciones con criterios de aceptación. Es además la manera más barata de mantener honesto el alcance, como contamos en cómo redactar el brief para una agencia de desarrollo.

Las piezas del stack de 2026 que sostienen las restricciones

Las elecciones técnicas de un proyecto regulado no tienen nada de exótico. Lo que cambia es qué decisiones aguantan peso.

• Identidad a través de un proveedor en la nube, detrás de una interfaz propia. El proveedor se cambia al menos una vez, por cobertura geográfica, por precio o por un requisito de residencia de datos. La lógica de decisión y los estados del solicitante viven en tu código, no en el panel del proveedor.
• Un libro mayor separado del esquema de la aplicación. De solo adición, por partida doble, conciliado con los extractos de la entidad en fechas fijas. Los saldos se calculan, no se guardan en una columna modificable.
• Autorización a nivel de fila en la base de datos, no solo en la API. La row-level security de Postgres sostiene la frontera entre inquilinos y roles incluso cuando un endpoint está mal escrito, y sigue rápida si las políticas se escriben pensando en el planificador (siete patrones que usamos).
• La jurisdicción como configuración. Requisitos de verificación, plazos de conservación y textos informativos cambian de un país a otro. Cuando se convierten en ramas del código, el segundo mercado cuesta lo mismo que el primero.
• Un design system que se queda con los valores accesibles por defecto. Contraste, foco, textos de error y tamaño de los objetivos se deciden una vez y cada pantalla los hereda.

Cuándo basta un estudio generalista

No todos los productos del sector necesitan esto. Un prototipo previo a la licencia para levantar una ronda, una herramienta B2B de análisis que lee datos bancarios a través de un proveedor y nunca toca el dinero, una consola interna para una entidad que ya tiene sus controles: son proyectos de software normales, y pagar por ellos el sobreprecio de lo regulado es desperdicio.

Las restricciones empiezan a apretar cuando se mueve dinero de consumidores, cuando la identidad hay que probarla y conservarla, y cuando un supervisor puede pedir las pruebas después. Si se cumplen dos de esas tres condiciones, elige estudio por la restricción. Si no se cumple ninguna, elige por el producto.