PRESION REGULATORIA
El Regulador No Perdona: PSD2, DORA y el Coste del Incumplimiento
El sector fintech europeo opera bajo una presión regulatoria sin precedentes. No es hipotética — es calendario.
DORA: el reloj ya ha sonado
El Reglamento de Resiliencia Operativa Digital (DORA) es de obligado cumplimiento desde el 17 de enero de 2025. No es una directiva que requiera transposición — es un reglamento europeo de aplicación directa. Exige que toda entidad financiera (incluidas fintechs con licencia de pago o dinero electrónico) mantenga un inventario actualizado de activos TIC, realice pruebas de resiliencia periódicas y gestione activamente los riesgos de terceros tecnológicos, incluidos proveedores cloud. Las sanciones son proporcionales pero disuasorias: las autoridades competentes pueden imponer multas periódicas de hasta el 1% de la facturación media diaria global por cada día de incumplimiento.
PSD2 y SCA: la autenticación que no puedes fallar
PSD2 exige Strong Customer Authentication en prácticamente todas las transacciones electrónicas desde 2021. Pero la implementación técnica sigue siendo un campo de minas: flujos de fallback que omiten el segundo factor, tokens de autenticación con TTL de horas en lugar de minutos, y vinculación dinámica (dynamic linking) mal implementada que no asocia el código de autorización al importe y beneficiario específicos. Cada uno de estos fallos es una vulnerabilidad explotable Y una infracción regulatoria. Las sanciones varían por estado miembro, pero en jurisdicciones como Alemania o Francia pueden superar los 5 millones de euros.
Auditoría PSD2-SCA — Flujo de Pago3 Hallazgos Críticos
1. Autenticación Fuerte (SCA)
Token de autorización sin dynamic linking
PSD2 Art.97Access token TTL: 3600s (max recomendado: 300s)
EBA GL 2018/04Refresh token sin rotación automática
OAuth 2.1 BCP2. Flujo de Fallback
Endpoint /v1/payments acepta auth sin 2FA
BYPASS SCAExemptions (TRA) correctamente implementadas
Art.18 RTSRecomendación: implementar dynamic linking vinculando código de autorización al importe y IBAN del beneficiario. Reducir TTL de access tokens a 300 segundos.
APIs COMO VECTOR
Open Banking Abrió las APIs. También Abrió la Superficie de Ataque.
PSD2 obligó a los bancos a abrir sus APIs a terceros. Eso creó un ecosistema de innovación — y el mayor vector de ataque del sector financiero europeo.
El problema no es tener APIs. Es cuántas y quién las consume.
Una fintech media expone decenas de endpoints a Third Party Providers (TPPs): Account Information Service Providers (AISPs) que consultan saldos, Payment Initiation Service Providers (PISPs) que inician transferencias, y agregadores que combinan ambos. Cada integración es una superficie de ataque. Según datos del sector, más del 60% de las brechas en servicios financieros involucran vulnerabilidades en APIs. No es sorpresa: las APIs financieras combinan datos de alto valor con acceso de terceros en un entorno de alta complejidad.
OWASP API Top 10 en contexto fintech
| Vulnerabilidad | Impacto en fintech | Ejemplo real |
|---|---|---|
| BOLA (API1) | Acceso a saldos y movimientos de otros usuarios | GET /accounts/{id} sin validar que el ID pertenece al usuario autenticado |
| Broken Auth (API2) | Bypass de SCA, session hijacking en flujos OAuth | Token de acceso sin audience claim permite usarlo en otro servicio |
| Excessive Data (API3) | API devuelve PAN completo o datos KYC en respuestas | Endpoint de perfil retorna IBAN, DNI y fecha de nacimiento sin filtrar campos |
| BFLA (API5) | Un usuario con rol "viewer" ejecuta transferencias | POST /transfers acepta tokens sin verificar el scope de permisos |
| SSRF (API7) | Acceso a metadatos cloud desde la API de webhooks | Callback URL apunta a 169.254.169.254 y extrae credenciales IAM |
Por qué un WAF no es suficiente
Los WAFs tradicionales filtran payloads conocidos (SQLi, XSS), pero las vulnerabilidades más peligrosas en APIs financieras son lógicas, no sintácticas. Un BOLA es una petición HTTP perfectamente formada — solo que con un ID que no pertenece al usuario. Un WAF no puede distinguir entre una consulta legítima de saldo y una consulta al saldo de otra persona. Para eso necesitas DAST autenticado que entienda el contexto de autorización de cada endpoint.
CLOUD COMPLIANCE
Tu Cloud Financiero Tiene Reglas Diferentes
La infraestructura cloud de una fintech no es como la de un SaaS cualquiera. Procesa pagos, almacena datos regulados y está sujeta a requisitos de cifrado, segmentación y auditoría que el modelo de responsabilidad compartida no resuelve solo.
El modelo de responsabilidad compartida tiene letra pequeña
AWS, GCP y Azure protegen su infraestructura. Tú proteges lo que pones encima. En el contexto de PCI-DSS, esto significa que el proveedor cloud puede tener su certificación — pero tu scope sigue incluyendo todo servicio que toque, procese o almacene datos de tarjeta. Un RDS sin cifrado en reposo que almacena números PAN es tu responsabilidad, no la de AWS. Un rol Lambda con permisos de administrador que procesa pagos es tu riesgo, no el de tu proveedor. CSPM automatiza la verificación continua de estas configuraciones para que no dependas de revisiones manuales trimestrales que siempre llegan tarde.
Las misconfiguraciones que vemos en fintechs reales
Después de auditar decenas de infraestructuras fintech, los patrones se repiten: bases de datos RDS en subnets públicas "porque el equipo de datos necesita acceso directo", buckets S3 con documentos KYC (DNI, selfies, justificantes de domicilio) sin cifrado del lado del servidor, funciones Lambda con roles IAM que pueden leer y escribir en cualquier tabla DynamoDB del entorno (incluidas las de producción con datos de transacciones), y security groups que permiten tráfico SSH desde 0.0.0.0/0 "temporalmente" desde hace seis meses. Cada una de estas configuraciones es un hallazgo de auditoría y un vector de ataque real.
Auditoría CSPM — Cloud Financiero
12 Hallazgos4 Críticos
Scope PCI-DSS (CDE)
RDS payments-db: cifrado en reposo DESACTIVADO
PCI 3.4S3 kyc-documents-prod: sin SSE, acceso público
PCI 3.4Lambda payment-processor: IAM admin en cuenta
PCI 7.1VPC payments-vpc: no segmenta CDE de non-CDE
PCI 1.3CloudTrail: log file validation desactivado
PCI 10.5Scope real detectado: 14 servicios tocan datos PAN (vs. 6 declarados en SAQ). Recomendación: aislar CDE en subnet dedicada y aplicar cifrado KMS a RDS y S3.
EL ANGULO MUERTO
De Sandbox a Producción: El Punto Ciego que los Reguladores Ya Conocen
Los entornos de sandbox son imprescindibles para desarrollar y testear APIs de pago. Pero cuando se gestionan mal, se convierten en la puerta trasera más obvia de tu infraestructura.
Datos reales en entornos de prueba: un clásico fintech
El patrón es predecible: el equipo de desarrollo necesita datos "realistas" para probar flujos de pago complejos. Alguien clona la base de datos de producción al entorno de staging. Las IBANs, los DNIs, las direcciones y los historiales de transacciones de clientes reales ahora viven en un entorno con controles de seguridad mínimos. Sin cifrado en reposo (porque "es solo staging"). Sin autenticación fuerte (porque "es para uso interno"). Accesible desde internet (porque "el equipo remoto necesita acceder"). Este escenario no es hipotético — la AEPD (Agencia Española de Protección de Datos) ha sancionado a empresas españolas por tratar datos personales reales en entornos de desarrollo sin las medidas técnicas adecuadas.
API keys de test con permisos de producción
Otro patrón recurrente: las API keys etiquetadas como "sandbox" que en realidad tienen permisos sobre recursos de producción. Ocurre cuando los entornos comparten el mismo proveedor de identidad o cuando los roles IAM no están correctamente segmentados entre cuentas. Un atacante que compromete una API key "de test" descubre que puede listar clientes reales, consultar saldos reales o — en el peor caso — iniciar transacciones reales. Lo hemos visto. Más de una vez.
Cómo Vulnerabbit cierra esta brecha
Nuestro módulo ASM descubre automáticamente subdominios de staging y sandbox expuestos a internet (sandbox.tufintech.com, api-staging.tufintech.com, dev.tufintech.com) y verifica si requieren autenticación. CSPM audita que los entornos de test tengan el mismo nivel de cifrado y control de acceso que producción cuando contienen datos sensibles. Y DAST compara los permisos efectivos de API keys de test contra los de producción para detectar solapamientos peligrosos. El resultado: visibilidad completa sobre un riesgo que la mayoría de fintechs ni siquiera saben que tienen.
El Coste de No Actuar
Los números del sector financiero no dejan margen para la complacencia.
~5,4M €
Coste medio global de una brecha de datos en servicios financieros (IBM Cost of a Data Breach 2024). Un 22% más alto que la media intersectorial.
204 días
Tiempo medio para identificar una brecha en el sector financiero. Los atacantes tienen casi 7 meses antes de ser detectados.
Ene 2025
DORA es de obligado cumplimiento. Las entidades que no tengan inventario de activos TIC, pruebas de resiliencia y gestión de riesgos de terceros están en incumplimiento hoy.
Tu Fintech Necesita Seguridad que Entienda tu Regulación
No un escáner genérico. Una plataforma que habla PSD2, DORA y PCI-DSS — y te genera las evidencias que el regulador va a pedir.
Primeros resultados en menos de una hora. Sin compromiso.