PSD2 (Directiva de Servicios de Pago)
Directiva europea (UE) 2015/2366 sobre servicios de pago, transpuesta en España por el Real Decreto-ley 19/2018, que establece la responsabilidad de los bancos ante operaciones no autorizadas y refuerza la autenticación del cliente.
PSD2 (Directiva de Servicios de Pago)
En 2024, el Banco de España resolvio 10.361 reclamaciones relacionadas con operaciones de pago no autorizadas, un 38% mas que el ano anterior (Memoria de Reclamaciones, BdE, 2025). De esas reclamaciones, el 67% se referian a fraudes ejecutados mediante troyanos bancarios, phishing y SIM swapping, operaciones donde la victima nunca autorizo la transferencia pero el banco insistia en que “el codigo OTP fue validado correctamente”. La PSD2 es la norma europea que obliga a las entidades financieras a devolver el dinero en estos casos, salvo que demuestren negligencia grave del usuario. Conocer esta directiva es la diferencia entre perder miles de euros o recuperarlos.
Plazo critico: 13 meses para reclamar
El articulo 43 del RDL 19/2018 establece que el usuario debe notificar al banco las operaciones no autorizadas en un plazo maximo de 13 meses desde la fecha del cargo. Pasado ese plazo, pierdes el derecho al reembolso. Si descubres transferencias sospechosas, reclama inmediatamente y contacta con un perito informatico para preservar la evidencia digital antes de que se pierda.
Que es la PSD2
La PSD2 (Payment Services Directive 2) es la Directiva (UE) 2015/2366 del Parlamento Europeo y del Consejo, de 25 de noviembre de 2015, sobre servicios de pago en el mercado interior. Sustituyo a la primera Directiva de Servicios de Pago (PSD1, Directiva 2007/64/CE) e introdujo cambios estructurales en la regulacion del sector financiero europeo.
En Espana, la PSD2 fue transpuesta mediante el Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera (BOE num. 284, 24.11.2018). Este RDL derogo el anterior RDL 16/2009 y constituye la norma de referencia para cualquier reclamacion bancaria por operaciones no autorizadas en territorio espanol.
Elementos clave de la PSD2:
| Aspecto | Descripcion |
|---|---|
| Base juridica | Directiva (UE) 2015/2366 (DOUE L 337, 23.12.2015) |
| Transposicion espanola | Real Decreto-ley 19/2018, de 23 de noviembre |
| Ambito | Servicios de pago en el EEE (Espacio Economico Europeo) |
| Objetivo principal | Proteccion del usuario + innovacion en servicios de pago |
| Autenticacion | SCA obligatoria (Strong Customer Authentication) |
| Responsabilidad | Banco responde salvo negligencia grave del usuario |
| Plazo reclamacion | 13 meses desde la fecha de la operacion |
| Supervisor en Espana | Banco de Espana |
La PSD2 aborda tres ejes fundamentales: la proteccion del usuario ante operaciones no autorizadas, la autenticacion reforzada del cliente (SCA) para prevenir fraudes, y la apertura del mercado a nuevos proveedores de servicios de pago (Open Banking).
Responsabilidades: usuario frente a banco bajo la PSD2
Uno de los aspectos mas relevantes de la PSD2 para victimas de fraude bancario digital es la clara distribucion de responsabilidades entre el usuario y la entidad financiera.
Tabla comparativa de responsabilidades
| Aspecto | Responsabilidad del usuario | Responsabilidad del banco |
|---|---|---|
| Custodia de credenciales | Mantener en secreto las credenciales personalizadas (PIN, claves, passwords) | Proporcionar mecanismos seguros para la custodia y uso de credenciales |
| Notificacion de operaciones | Notificar sin demora indebida al banco las operaciones no autorizadas (maximo 13 meses) | Disponer de canales accesibles 24/7 para recibir notificaciones |
| Dispositivos | Utilizar los instrumentos de pago conforme a las condiciones pactadas | Asegurar que los canales de pago son seguros y cumplen SCA |
| Autenticacion | Completar los pasos de autenticacion requeridos | Implementar SCA con al menos dos factores independientes |
| Prueba de autorizacion | No tiene carga de la prueba | Demostrar que la operacion fue autenticada, registrada y contabilizada (Art. 44.1 RDL 19/2018) |
| Reembolso | Cooperar en la investigacion del fraude | Reembolsar en D+1 tras la notificacion, salvo sospecha fundada de fraude del usuario |
| Malware/phishing | No se considera negligencia si el engano fue sofisticado | Asumir perdidas si no puede demostrar negligencia grave |
La carga de la prueba recae en el banco
El articulo 44.1 del RDL 19/2018 es inequivoco: “Cuando un usuario de servicios de pago niegue haber autorizado una operacion de pago ya ejecutada, correspondera al proveedor de servicios de pago demostrar que la operacion fue autenticada, registrada con exactitud y contabilizada”. El banco debe probar la negligencia grave del usuario; no al reves.
Autenticacion reforzada del cliente (SCA)
La Strong Customer Authentication (SCA) es uno de los pilares de la PSD2 y esta regulada en detalle por el Reglamento Delegado (UE) 2018/389 de la Comision Europea. Exige que toda operacion de pago electronico se autentique con al menos dos de los tres factores siguientes:
| Factor | Tipo | Ejemplos |
|---|---|---|
| Algo que el usuario sabe | Conocimiento | PIN, contrasena, patron de desbloqueo |
| Algo que el usuario posee | Posesion | Telefono movil, tarjeta fisica, token hardware |
| Algo que el usuario es | Inherencia | Huella dactilar, reconocimiento facial, iris |
Requisito critico: Los dos factores deben ser independientes entre si. Si el compromiso de uno facilita el compromiso del otro, la autenticacion no cumple con la SCA. Este requisito es fundamental en casos de troyanos bancarios y SIM swapping:
Escenarios donde falla la SCA:
| Escenario de ataque | Factores comprometidos | Cumple SCA |
|---|---|---|
| Troyano bancario con overlay attack | Conocimiento (overlay captura PIN) + Posesion (intercepta SMS OTP en el mismo dispositivo) | No: ambos factores comprometidos en el mismo dispositivo |
| SIM swapping | Posesion (SIM duplicada) permite interceptar SMS OTP | No: el factor posesion (SMS) no es independiente del atacante |
| BEC con phishing | Conocimiento (credenciales robadas por phishing) | No si el segundo factor es SMS y el atacante lo intercepta |
| Push notification aprobada por engano | Posesion (el usuario aprueba la push sin saberlo tras ingenieria social) | Cuestionable: el usuario “autorizo” pero bajo engano |
Cuando la autenticacion falla porque los factores no eran verdaderamente independientes, la responsabilidad recae sobre la entidad financiera que eligio un mecanismo insuficiente.
Negligencia grave: cuando pierde el usuario
La PSD2 establece una excepcion clave a la responsabilidad del banco: si el usuario actuo con negligencia grave o de manera fraudulenta, pierde el derecho al reembolso (Art. 46 RDL 19/2018). Pero la jurisprudencia espanola ha ido acotando estrictamente este concepto.
Que constituye negligencia grave (y que no)
| Conducta | Negligencia grave | Explicacion |
|---|---|---|
| Compartir PIN bancario voluntariamente con un tercero | Si | El usuario entrega conscientemente sus credenciales |
| Anotar PIN en un post-it pegado a la tarjeta | Si | Falta manifiesta de diligencia en la custodia |
| Entregar credenciales en un email de phishing sofisticado | No | SAP Madrid (Seccion 11, 2024): “el phishing sofisticado no constituye negligencia grave” |
| Instalar un APK malicioso recibido por WhatsApp | No | El troyano bancario actua sin conocimiento del usuario; la infeccion no equivale a “entregar” credenciales |
| No tener antivirus en el movil | No | No existe obligacion contractual ni legal de instalar antivirus |
| Aprobar una push notification tras ingenieria social | Discutible | Depende de la sofisticacion del engano (caso por caso) |
| Entregar datos en una web clonada del banco (phishing) | No | SAP Barcelona (Seccion 15, 2023): la apariencia identica excluye negligencia grave |
| Ignorar SMS de alerta del banco durante horas | Discutible | Podria interpretarse como falta de diligencia en la notificacion |
| Caer en vishing (llamada telefonica simulando ser el banco) | No | SAP Valencia (Seccion 9, 2024): la suplantacion del numero de telefono del banco (caller ID spoofing) excluye negligencia |
El banco no puede presumir negligencia
La Audiencia Provincial de Pontevedra (Seccion 1, Sentencia 539/2023) establecio un principio clave: “La negligencia grave no puede presumirse del mero hecho de que la operacion fuera autenticada con los codigos del usuario. Corresponde al banco acreditar la conducta negligente concreta del usuario, no al usuario demostrar su diligencia”. Este criterio ha sido seguido por multiples audiencias provinciales.
Proceso de reclamacion bancaria bajo la PSD2
Deteccion y notificacion inmediata al banco
En cuanto detectes operaciones no autorizadas, contacta con el servicio de atencion al cliente de tu banco. Hazlo por un canal que genere constancia escrita: formulario web, email o burofax. Solicita expresamente el reembolso invocando el articulo 45 del RDL 19/2018. El banco debe reembolsar el importe a mas tardar al final del dia habil siguiente a la notificacion, salvo que tenga motivos razonables para sospechar fraude del usuario.
Preservacion de evidencia digital
Antes de restaurar el telefono, eliminar apps o cambiar configuraciones, contacta con un perito informatico forense. La evidencia del malware, los logs de conexion del troyano, los SMS interceptados y los artefactos forenses son pruebas criticas. Un factory reset destruye esta evidencia de forma irreversible.
Denuncia ante policia
Presenta denuncia ante la Policia Nacional (Grupo de Delitos Telematicos) o Guardia Civil (Grupo de Delitos Telematicos del EDITE). La denuncia policial refuerza la reclamacion y es necesaria para que el banco inicie su investigacion interna.
Reclamacion formal al Servicio de Atencion al Cliente
Si el banco no reembolsa en D+1, presenta reclamacion formal por escrito al SAC (Servicio de Atencion al Cliente) de la entidad. El banco tiene 15 dias habiles para responder (Art. 10.2 Orden ECO/734/2004). Incluye: copia de la denuncia, extractos bancarios con las operaciones no autorizadas y referencia al RDL 19/2018.
Reclamacion al Banco de Espana
Si el SAC rechaza la reclamacion o no responde en plazo, eleva la reclamacion al Servicio de Reclamaciones del Banco de Espana. Requisito previo: haber agotado la via del SAC. El Banco de Espana emite un informe no vinculante pero con enorme peso en via judicial. En 2024, el 73% de los informes del BdE fueron favorables al usuario en operaciones no autorizadas (Memoria de Reclamaciones BdE, 2025).
Via judicial con informe pericial
Si el banco mantiene su negativa, la via judicial es altamente favorable al usuario. La demanda se presenta ante el Juzgado de Primera Instancia. El informe pericial informatico es la pieza clave: demuestra tecnicamente que la operacion fue ejecutada por malware, phishing o SIM swapping, no por el usuario. La jurisprudencia espanola de 2023-2026 es abrumadoramente favorable al consumidor, con tasas de exito superiores al 80% cuando se aporta informe pericial.
Caso practico: reclamacion por troyano Anatsa
Nota: El siguiente caso es un ejemplo compuesto y anonimizado basado en tipologias reales de peritaje informatico. Los datos especificos (nombres, entidades, cantidades exactas) han sido modificados para proteger la confidencialidad, preservando unicamente los aspectos tecnicos relevantes para fines educativos.
Contexto: Una profesional autonoma de Sevilla descubre tres transferencias no autorizadas por un total de 14.200 EUR desde su cuenta de negocio. El banco rechaza el reembolso argumentando que las operaciones fueron “autenticadas con SMS OTP” y que “la cliente debio proteger mejor su dispositivo”.
Investigacion forense:
Analisis del dispositivo: El perito extrajo imagen forense del smartphone Android de la afectada. El analisis revelo la presencia del troyano bancario Anatsa (tambien conocido como TeaBot), instalado 72 horas antes de las transferencias a traves de una app de escaner de documentos descargada de Google Play Store (la app fue retirada posteriormente por Google).
Mecanismo del ataque: Anatsa utilizo servicios de accesibilidad Android para ejecutar un overlay attack sobre la app bancaria legitima. Cuando la usuaria abria la app del banco, Anatsa superponia una pantalla identica que capturaba sus credenciales. Simultaneamente, interceptaba los SMS OTP antes de que llegaran a la bandeja de entrada.
Timeline forense reconstruido:
| Hora | Evento | Evidencia |
|---|---|---|
| Martes 09:15 | Instalacion app escaner (dropper de Anatsa) | packages.list, logcat |
| Martes 09:17 | Permisos de accesibilidad concedidos | appops.xml |
| Jueves 14:22 | Overlay activado sobre app bancaria | WindowManager logs |
| Jueves 14:23 | Credenciales capturadas via overlay | Trafico C2 (IP 91.215.xx.xx) |
| Jueves 14:26 | SMS OTP interceptado | telephony.db (recibido y borrado en 2s) |
| Jueves 14:27 | Transferencia 1: 4.900 EUR | Logs bancarios |
| Jueves 14:31 | Transferencia 2: 4.900 EUR | Logs bancarios |
| Jueves 14:35 | Transferencia 3: 4.400 EUR | Logs bancarios |
Incumplimiento de SCA: El informe pericial demostro que el sistema del banco no cumplia los requisitos de SCA de la PSD2. Ambos factores (contrasena + SMS OTP) fueron comprometidos en el mismo dispositivo, lo que significa que los factores no eran independientes entre si (Reglamento Delegado 2018/389, Art. 9).
Ausencia de controles antifraude: El banco no detecto tres transferencias de cuantia similar (4.900, 4.900, 4.400 EUR) ejecutadas en 8 minutos a cuentas nunca antes utilizadas, todas en un neobank extranjero. No se activo ninguna alerta de fraude.
Resultado: El Juzgado de Primera Instancia condeno al banco a reembolsar los 14.200 EUR mas intereses legales y costas procesales. La sentencia cito el Art. 44 del RDL 19/2018 y determino que el banco no demostro negligencia grave de la usuaria: “la instalacion de una aplicacion disponible en Google Play Store no constituye negligencia grave del usuario de servicios de pago”.
El papel del informe pericial forense en reclamaciones PSD2
El informe pericial informatico es, en la practica, la pieza procesal que inclina la balanza en las reclamaciones bancarias bajo la PSD2. Su funcion es demostrar tecnicamente que ocurrio, como ocurrio y por que no fue culpa del usuario.
Que debe acreditar el informe pericial
| Elemento | Contenido tecnico | Relevancia juridica |
|---|---|---|
| Existencia de malware | Identificacion de la familia de malware, hash SHA-256 del APK, fecha de instalacion, permisos abusados | Demuestra que la operacion fue ejecutada por un tercero, no por el usuario |
| Mecanismo del ataque | Overlay attack, interceptacion OTP, keylogging, VNC remoto | Demuestra que las credenciales del usuario fueron capturadas sin su conocimiento |
| Timeline forense | Correlacion temporal precisa: instalacion del malware, activacion del overlay, captura de credenciales, ejecucion de transferencias | Demuestra la causalidad directa entre el malware y las operaciones no autorizadas |
| Incumplimiento de SCA | Analisis de si los factores de autenticacion eran verdaderamente independientes | Demuestra que el banco no cumplio con los requisitos de la PSD2 |
| Ausencia de negligencia | Origen del malware (store oficial, enlace de phishing sofisticado), comportamiento razonable del usuario | Contrarresta la alegacion de “negligencia grave” del banco |
| Fallos del sistema bancario | Ausencia de alertas de fraude, falta de deteccion de patrones anomalos | Demuestra que el banco fallo en sus obligaciones de monitorizacion |
Coste del peritaje vs recuperacion
Inversion en peritaje PSD2:
- Extraccion forense del dispositivo: 800-1.200 EUR
- Analisis del malware e informe: 600-1.000 EUR
- Ratificacion judicial: 300-600 EUR
- Total tipico: 1.700-2.800 EUR
Recuperacion tipica: 5.000-50.000 EUR (importe de las operaciones no autorizadas) ROI del informe pericial: 300-1.800%
Marco legal completo
Normativa europea
- Directiva (UE) 2015/2366 (PSD2): Marco general de servicios de pago, autenticacion reforzada y responsabilidad ante operaciones no autorizadas
- Reglamento Delegado (UE) 2018/389: Normas tecnicas de regulacion para la SCA y los estandares de comunicacion abiertos y seguros
- Directiva (UE) 2024/2366 (PSD3): Aprobada el 23 de octubre de 2024, refuerza la proteccion del usuario. Plazo de transposicion: 2026. Incluye responsabilidad ampliada para fraudes por ingenieria social
Normativa espanola
- Real Decreto-ley 19/2018, de 23 de noviembre: Transposicion de la PSD2 en Espana. Articulos clave: 36 (obligaciones del usuario), 41 (notificacion), 43 (plazo 13 meses), 44 (prueba autenticacion), 45 (responsabilidad reembolso), 46 (negligencia grave)
- Codigo Penal: Art. 248 (estafa informatica), Art. 197 (acceso ilicito a datos), Art. 264 (danos informaticos)
- Ley 7/2017: Resolucion alternativa de litigios en materia de consumo (via reclamacion extrajudicial)
Jurisprudencia relevante
- SAP Madrid, Seccion 11 (2024): Phishing sofisticado no constituye negligencia grave del usuario
- SAP Barcelona, Seccion 15 (2023): Web clonada identica al banco excluye negligencia
- SAP Pontevedra, Seccion 1, Sentencia 539/2023: La negligencia grave no puede presumirse del mero hecho de que la operacion fuera autenticada
- SAP Valencia, Seccion 9 (2024): Caller ID spoofing en vishing excluye negligencia
- Banco de Espana, Memoria de Reclamaciones 2024-2025: 73% de informes favorables al usuario en operaciones no autorizadas
Conceptos relacionados
- Troyano bancario - Malware especializado que intercepta credenciales bancarias, principal vector de fraude bancario reclamable bajo PSD2
- Overlay attack - Tecnica utilizada por troyanos bancarios para superponer pantallas falsas y capturar credenciales
- BEC (Business Email Compromise) - Fraude por compromiso de correo empresarial, donde la PSD2 tambien protege al pagador enganado
- SIM swapping - Fraude de duplicado de SIM que permite interceptar SMS OTP, vulnerable bajo SCA
- Phishing - Vector principal de fraude bancario, cuyas victimas estan protegidas por la PSD2 salvo negligencia grave
Preguntas frecuentes
Que es la PSD2 y como me protege del fraude bancario
La PSD2 (Directiva de Servicios de Pago 2) es la normativa europea que regula los servicios de pago en la Union Europea, transpuesta en Espana por el RDL 19/2018. Su proteccion principal es clara: si se ejecuta una operacion de pago no autorizada (por troyano bancario, phishing, SIM swapping u otro metodo), el banco debe devolver el dinero a mas tardar al final del dia habil siguiente a la notificacion. La unica excepcion es que el banco demuestre que el usuario actuo con negligencia grave o de forma fraudulenta, y la carga de esa prueba recae sobre el banco, no sobre el usuario.
Puedo reclamar al banco si un troyano robo dinero de mi cuenta
Si. Los troyanos bancarios como Anatsa, ERMAC o Godfather ejecutan transferencias sin conocimiento ni consentimiento del usuario. Bajo la PSD2 (Art. 45 RDL 19/2018), estas son operaciones no autorizadas y el banco debe reembolsarlas. Un informe pericial informatico que identifique el malware, reconstruya el timeline del ataque y demuestre que las credenciales fueron capturadas mediante overlay attack es determinante para que el banco no pueda alegar negligencia grave. La jurisprudencia espanola reciente es abrumadoramente favorable: la instalacion de malware no se considera negligencia del usuario.
Que plazo tengo para reclamar al banco bajo PSD2
Tienes un plazo maximo de 13 meses desde la fecha de la operacion no autorizada para notificarla al banco (Art. 43 RDL 19/2018). Pasado ese plazo, pierdes el derecho al reembolso. Sin embargo, la notificacion debe realizarse “sin demora indebida” una vez tengas conocimiento de la operacion. En la practica, cuanto antes notifiques, mejor: la evidencia forense se degrada con el tiempo, el banco tiene menos argumentos para cuestionar la buena fe del usuario, y las posibilidades de rastrear los fondos son mayores en las primeras horas.
Que ocurre si el banco rechaza mi reclamacion
Si el banco rechaza el reembolso, tienes tres vias progresivas. Primera: reclamacion al SAC del banco (15 dias habiles para responder). Segunda: reclamacion al Servicio de Reclamaciones del Banco de Espana (informe no vinculante pero de gran peso). Tercera: demanda judicial ante el Juzgado de Primera Instancia. En via judicial, un informe pericial informatico que acredite el mecanismo del fraude y la ausencia de negligencia del usuario es la prueba clave. Las tasas de exito con informe pericial superan el 80% en la jurisprudencia de 2023-2026.
La PSD3 cambiara algo respecto a la proteccion actual
La Directiva (UE) 2024/2366 (PSD3), aprobada el 23 de octubre de 2024, refuerza la proteccion del usuario en varios aspectos: amplia la responsabilidad de los bancos a fraudes por ingenieria social (donde el usuario fue enganado para autorizar la operacion), mejora los mecanismos de devolucion de fondos entre entidades, y exige sistemas de monitorizacion de fraude en tiempo real. Los Estados miembros deben transponerla antes de 2026. Hasta entonces, la PSD2 (RDL 19/2018) sigue siendo la norma aplicable.
Referencias y fuentes
Directiva (UE) 2015/2366 del Parlamento Europeo y del Consejo, de 25 de noviembre de 2015, sobre servicios de pago en el mercado interior (PSD2). eur-lex.europa.eu
Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera (transposicion PSD2). boe.es
Reglamento Delegado (UE) 2018/389 de la Comision, por el que se complementa la Directiva (UE) 2015/2366 en lo relativo a las normas tecnicas de regulacion para la autenticacion reforzada del cliente (SCA). eur-lex.europa.eu
Banco de Espana - “Memoria de Reclamaciones 2024”. Servicio de Reclamaciones. bde.es
Directiva (UE) 2024/2366 (PSD3) del Parlamento Europeo y del Consejo, de 23 de octubre de 2024. eur-lex.europa.eu
SAP Pontevedra, Seccion 1, Sentencia 539/2023 - Negligencia grave no puede presumirse de la mera autenticacion
SAP Madrid, Seccion 11 (2024) - Phishing sofisticado excluye negligencia grave del usuario de servicios de pago
SAP Barcelona, Seccion 15 (2023) - Web clonada identica excluye negligencia del consumidor
SAP Valencia, Seccion 9 (2024) - Caller ID spoofing en vishing excluye negligencia grave
INCIBE - “Balance de Ciberseguridad 2025: fraude bancario digital en Espana”. incibe.es
Europol - “Internet Organised Crime Threat Assessment (IOCTA) 2025: Banking trojans and payment fraud”. europol.europa.eu
Threat Fabric - “Mobile Banking Threats 2025: Anatsa, ERMAC, Godfather analysis”. threatfabric.com
Disclaimer: Este contenido tiene finalidad informativa y educativa. No constituye asesoramiento juridico. Los casos descritos son ejemplos compuestos y anonimizados basados en tipologias reales de peritaje informatico. Para reclamaciones bancarias concretas, consulte con un abogado especializado y solicite un informe pericial informatico adaptado a su caso.
Ultima actualizacion: 16 de febrero de 2026 Autor: Jonathan Izquierdo, ex-CTO y 5x AWS Certified, perito informatico forense Categoria: Marco Legal (LEG-031) Nivel tecnico: Intermedio Relevancia: Muy Alta (reclamaciones bancarias activas 2026)
Preguntas Frecuentes
¿Qué es la PSD2 y cómo me protege del fraude bancario?
La PSD2 establece que el banco debe devolver el dinero de operaciones no autorizadas salvo que demuestre negligencia grave del usuario, lo que protege a víctimas de troyanos bancarios y phishing.
¿Puedo reclamar al banco si un troyano robó dinero de mi cuenta?
Sí, bajo la PSD2 el banco debe reembolsar operaciones no autorizadas. Un informe pericial forense que demuestre la infección por malware refuerza tu posición.
¿Qué plazo tengo para reclamar al banco bajo PSD2?
Debes notificar la operación no autorizada al banco en un plazo máximo de 13 meses desde la fecha del cargo.
¿Necesitas un peritaje forense?
Si necesitas ayuda profesional con análisis forense digital, estoy aquí para ayudarte.
Solicitar Consulta Gratuita