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 tramitó 8.435 expedientes sobre tarjetas —el 15 % de todas las reclamaciones, y un 12,6 % menos que en 2023—, en los que «predominan las reclamaciones derivadas de operaciones de pago realizadas mediante tarjeta en un contexto de fraude o engaño al usuario» (Memoria de Reclamaciones 2024, cuadro 1.1 y cap. 1). El fraude concentra el 14 % de las materias reclamadas. Conviene leer bien esa caída: no significa que haya menos fraude, sino que el volumen total se disparó por las reclamaciones de gastos hipotecarios (+538 %). Y la Memoria clasifica por producto y por motivo, no por la técnica con la que se cometió el fraude: no hay un reparto oficial entre troyanos bancarios, phishing y SIM swapping. Lo que sí tienen en común todas ellas es el punto donde encalla la reclamación: la víctima nunca autorizó la transferencia, y el banco responde que «el código 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 artículo 43 del RDL 19/2018 establece que el usuario debe notificar al banco las operaciones no autorizadas en un plazo máximo 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 informático para preservar la evidencia digital antes de que se pierda.
Qué 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 regulación del sector financiero europeo.
En España, 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 reclamación bancaria por operaciones no autorizadas en territorio español.
Elementos clave de la PSD2:
| Aspecto | Descripción |
|---|---|
| Base jurídica | Directiva (UE) 2015/2366 (DOUE L 337, 23.12.2015) |
| Transposición española | Real Decreto-ley 19/2018, de 23 de noviembre |
| Ámbito | Servicios de pago en el EEE (Espacio Económico Europeo) |
| Objetivo principal | Protección del usuario + innovación en servicios de pago |
| Autenticación | SCA obligatoria (Strong Customer Authentication) |
| Responsabilidad | Banco responde salvo negligencia grave del usuario |
| Plazo reclamación | 13 meses desde la fecha de la operación |
| Supervisor en España | Banco de España |
La PSD2 aborda tres ejes fundamentales: la protección del usuario ante operaciones no autorizadas, la autenticación 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 más relevantes de la PSD2 para víctimas de fraude bancario digital es la clara distribución 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 |
| Notificación de operaciones | Notificar sin demora indebida al banco las operaciones no autorizadas (máximo 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 |
| Autenticación | Completar los pasos de autenticación requeridos | Implementar SCA con al menos dos factores independientes |
| Prueba de autorización | No tiene carga de la prueba | Demostrar que la operación fue autenticada, registrada y contabilizada (Art. 44.1 RDL 19/2018) |
| Reembolso | Cooperar en la investigación del fraude | Reembolsar en D+1 tras la notificación, salvo sospecha fundada de fraude del usuario |
| Malware/phishing | No se considera negligencia si el engaño fue sofisticado | Asumir pérdidas si no puede demostrar negligencia grave |
La carga de la prueba recae en el banco
El artículo 44.1 del RDL 19/2018 es inequívoco: “Cuando un usuario de servicios de pago niegue haber autorizado una operación de pago ya ejecutada, correspondera al proveedor de servicios de pago demostrar que la operación fue autenticada, registrada con exactitud y contabilizada”. El banco debe probar la negligencia grave del usuario; no al reves.
Autenticación 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 Comisión Europea. Exige que toda operación de pago electrónico se autentique con al menos dos de los tres factores siguientes:
| Factor | Tipo | Ejemplos |
|---|---|---|
| Algo que el usuario sabe | Conocimiento | PIN, contraseña, patron de desbloqueo |
| Algo que el usuario posee | Posesión | Teléfono móvil, tarjeta física, 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 autenticación 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) + Posesión (intercepta SMS OTP en el mismo dispositivo) | No: ambos factores comprometidos en el mismo dispositivo |
| SIM swapping | Posesión (SIM duplicada) permite interceptar SMS OTP | No: el factor posesión (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 engaño | Posesión (el usuario aprueba la push sin saberlo tras ingeniería social) | Cuestionable: el usuario “autorizo” pero bajo engaño |
Cuando la autenticación 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 excepción 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 española ha ido acotando estrictamente este concepto.
Qué constituye negligencia grave (y que no)
| Conducta | Negligencia grave | Explicación |
|---|---|---|
| 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 | La negligencia grave exige algo más que ser engañado: el engaño verosímil no la constituye por sí solo |
| Instalar un APK malicioso recibido por WhatsApp | No | El troyano bancario actua sin conocimiento del usuario; la infección no equivale a “entregar” credenciales |
| No tener antivirus en el móvil | No | No existe obligación contractual ni legal de instalar antivirus |
| Aprobar una push notification tras ingeniería social | Discutible | Depende de la sofisticación del engaño (caso por caso) |
| Entregar datos en una web clonada del banco (phishing) | No | Si la web es indistinguible de la legítima, el usuario no ha omitido ninguna cautela exigible |
| Ignorar SMS de alerta del banco durante horas | Discutible | Podría interpretarse como falta de diligencia en la notificación |
| Caer en vishing (llamada telefónica simulando ser el banco) | No | Con caller ID spoofing la llamada muestra el número real del banco: no hay señal que el usuario pudiera advertir |
El banco no puede presumir negligencia
El principio lo fijan los arts. 45 y 46 del RDL 19/2018, que trasladan la carga: la entidad devuelve el importe de las operaciones no autorizadas (art. 45) salvo que pruebe actuación fraudulenta, incumplimiento deliberado o negligencia grave del usuario (art. 46). Y el Tribunal Supremo lo ha confirmado en la STS 571/2025, de 9 de abril (Sala de lo Civil — ROJ STS 1671/2025 · ECLI:ES:TS:2025:1671), que describe el régimen como de responsabilidad cuasi objetiva del proveedor de servicios de pago.
Traducido: que la operación se autenticara correctamente no prueba que la autorizara el cliente, y demostrar la negligencia grave le incumbe al banco, no al usuario demostrar su diligencia.
Proceso de reclamación bancaria bajo la PSD2
Detección y notificación inmediata al banco
En cuanto detectes operaciones no autorizadas, contacta con el servicio de atención al cliente de tu banco. Hazlo por un canal que genere constancia escrita: formulario web, email o burofax. Solicita expresamente el reembolso invocando el artículo 45 del RDL 19/2018. El banco debe reembolsar el importe a más tardar al final del día hábil siguiente a la notificación, salvo que tenga motivos razonables para sospechar fraude del usuario.
Preservación de evidencia digital
Antes de restaurar el teléfono, eliminar apps o cambiar configuraciones, contacta con un perito informático forense. La evidencia del malware, los logs de conexion del troyano, los SMS interceptados y los artefactos forenses son pruebas críticas. Un factory reset destruye esta evidencia de forma irreversible.
Denuncia ante policía
Presenta denuncia ante la Policía Nacional o la Guardia Civil, en cualquier comisaría o puesto. La denuncia policial refuerza la reclamación y es necesaria para que el banco inicie su investigación interna.
Reclamación formal al Servicio de Atención al Cliente
Si el banco no reembolsa en D+1, presenta reclamación formal por escrito al SAC (Servicio de Atención al Cliente) de la entidad. El banco tiene 15 días hábiles 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.
Reclamación al Banco de España
Si el SAC rechaza la reclamación o no responde en plazo, eleva la reclamación al Servicio de Reclamaciones del Banco de España. Requisito previo: haber agotado la via del SAC. El Banco de España emite un informe no vinculante pero con enorme peso en via judicial. En 2024, el 79 % de las reclamaciones resueltas acabó en rectificación a favor del reclamante —informe favorable, allanamiento de la entidad o desistimiento tras rectificar—, en línea con la media del 80 % del último trienio (Memoria de Reclamaciones 2024 del Banco de España).
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 informático es la pieza clave: demuestra técnicamente que la operación fue ejecutada por malware, phishing o SIM swapping, no por el usuario. La jurisprudencia española de 2023-2026 viene siendo favorable al consumidor, aunque no hay estadística de tasas de éxito: nadie publica cuántas demandas prosperan según el tipo de prueba aportada. Lo que decide es el art. 44 del RD-ley 19/2018, que pone sobre la entidad la carga de acreditar que la operación se autenticó correctamente.
Caso práctico: reclamación por troyano Anatsa
Nota: El siguiente caso es un ejemplo compuesto y anonimizado basado en tipologias reales de peritaje informático. Los datos específicos (nombres, entidades, cantidades exactas) han sido modificados para proteger la confidencialidad, preservando únicamente los aspectos técnicos relevantes para fines educativos.
Contexto: Una profesional autónoma 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”.
Investigación forense:
Análisis del dispositivo: El perito extrajo imagen forense del smartphone Android de la afectada. El análisis revelo la presencia del troyano bancario Anatsa (también conocido como TeaBot), instalado 72 horas antes de las transferencias a traves de una app de escáner 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 abría la app del banco, Anatsa superponia una pantalla idéntica que capturaba sus credenciales. Simultáneamente, interceptaba los SMS OTP antes de que llegaran a la bandeja de entrada.
Timeline forense reconstruido:
| Hora | Evento | Evidencia |
|---|---|---|
| Martes 09:15 | Instalación app escáner (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 | Tráfico 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 (contraseña + 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 cuantía 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 más 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 instalación de una aplicación 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 informático es, en la practica, la pieza procesal que inclina la balanza en las reclamaciones bancarias bajo la PSD2. Su función es demostrar técnicamente que ocurrio, como ocurrio y por que no fue culpa del usuario.
Qué debe acreditar el informe pericial
| Elemento | Contenido técnico | Relevancia jurídica |
|---|---|---|
| Existencia de malware | Identificación de la familia de malware, hash SHA-256 del APK, fecha de instalación, permisos abusados | Demuestra que la operación fue ejecutada por un tercero, no por el usuario |
| Mecanismo del ataque | Overlay attack, interceptación OTP, keylogging, VNC remoto | Demuestra que las credenciales del usuario fueron capturadas sin su conocimiento |
| Timeline forense | Correlación temporal precisa: instalación del malware, activacion del overlay, captura de credenciales, ejecución de transferencias | Demuestra la causalidad directa entre el malware y las operaciones no autorizadas |
| Incumplimiento de SCA | Análisis de si los factores de autenticación 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 detección de patrones anómalos | Demuestra que el banco fallo en sus obligaciones de monitorización |
Coste del peritaje vs recuperación
Inversión en peritaje PSD2:
- Extracción forense del dispositivo: 800-1.200 EUR
- Análisis del malware e informe: 600-1.000 EUR
- Ratificación judicial: 300-600 EUR
- Total típico: 1.700-2.800 EUR
Recuperación típica: 5.000-50.000 EUR (importe de las operaciones no autorizadas). El informe pericial no garantiza un resultado —depende de la valoración judicial o bancaria—, pero traslada al proveedor de pago la carga de acreditar la autenticación y la diligencia (art. 44 del Real Decreto-ley 19/2018).
Marco legal completo
Normativa europea
- Directiva (UE) 2015/2366 (PSD2): Marco general de servicios de pago, autenticación reforzada y responsabilidad ante operaciones no autorizadas
- Reglamento Delegado (UE) 2018/389: Normas técnicas de regulación para la SCA y los estándares de comunicación abiertos y seguros
- Propuesta de PSD3 — COM(2023) 366 final, de 28 de junio de 2023: la tercera Directiva de Servicios de Pago sigue en tramitación. No está publicada en el Diario Oficial de la Unión Europea, de modo que no tiene número de directiva ni plazo de transposición. Hasta que se publique, la norma aplicable sigue siendo la PSD2
Normativa española
- Real Decreto-ley 19/2018, de 23 de noviembre: Transposición de la PSD2 en España. Artículos clave: 36 (obligaciones del usuario), 41 (notificación), 43 (plazo 13 meses), 44 (prueba autenticación), 45 (responsabilidad reembolso), 46 (negligencia grave)
- Código Penal: Art. 248 (estafa informática), Art. 197 bis (acceso ilícito a sistemas de información), Art. 264 (daños informáticos)
- Ley 7/2017: Resolución alternativa de litigios en materia de consumo (via reclamación extrajudicial)
Jurisprudencia relevante
- STS 571/2025, de 9 de abril (Sala de lo Civil — ROJ STS 1671/2025 · ECLI:ES:TS:2025:1671): responsabilidad cuasi objetiva del proveedor de servicios de pago ante operaciones no autorizadas; la prueba de la negligencia grave incumbe a la entidad
- Banco de España, Memoria de Reclamaciones 2024: 79 % de rectificaciones a favor del reclamante; 8.435 expedientes sobre tarjetas, con predominio de operaciones en contexto de fraude o engaño
Conceptos relacionados
- Troyano bancario - Malware especializado que intercepta credenciales bancarias, principal vector de fraude bancario reclamable bajo PSD2
- Overlay attack - Técnica utilizada por troyanos bancarios para superponer pantallas falsas y capturar credenciales
- BEC (Business Email Compromise) - Fraude por compromiso de correo empresarial, donde la PSD2 también 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 víctimas están protegidas por la PSD2 salvo negligencia grave
Preguntas frecuentes
Qué 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 España por el RDL 19/2018. Su protección principal es clara: si se ejecuta una operación de pago no autorizada (por troyano bancario, phishing, SIM swapping u otro método), el banco debe devolver el dinero a más tardar al final del día hábil siguiente a la notificación. La única excepción 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 informático 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 española reciente es abrumadoramente favorable: la instalación de malware no se considera negligencia del usuario.
Qué plazo tengo para reclamar al banco bajo PSD2
Tienes un plazo máximo de 13 meses desde la fecha de la operación no autorizada para notificarla al banco (Art. 43 RDL 19/2018). Pasado ese plazo, pierdes el derecho al reembolso. Sin embargo, la notificación debe realizarse “sin demora indebida” una vez tengas conocimiento de la operación. 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.
Qué ocurre si el banco rechaza mi reclamación
Si el banco rechaza el reembolso, tienes tres vias progresivas. Primera: reclamación al SAC del banco (15 días hábiles para responder). Segunda: reclamación al Servicio de Reclamaciones del Banco de España (informe no vinculante pero de gran peso). Tercera: demanda judicial ante el Juzgado de Primera Instancia. En via judicial, un informe pericial informático que acredite el mecanismo del fraude y la ausencia de negligencia del usuario es la prueba clave. No existe estadística de tasas de éxito; lo que aporta el informe es acreditar el mecanismo del fraude, que es lo que impide al banco sostener que hubo negligencia grave del usuario.
La PSD3 cambiara algo respecto a la protección actual
Todavía no cambia nada: la PSD3 no está aprobada. Lo que existe es una propuesta de la Comisión Europea —COM(2023) 366 final, de 28 de junio de 2023—, acompañada de una propuesta de Reglamento de Servicios de Pago (PSR), y sigue en tramitación legislativa. Mientras no se publique en el Diario Oficial de la Unión Europea no hay número de directiva, no corre plazo de transposición y la norma aplicable en España es la PSD2 a través del Real Decreto-ley 19/2018.
Lo que el paquete propone —y por tanto lo que conviene vigilar, no invocar todavía ante un banco— es ampliar la responsabilidad de las entidades a supuestos de fraude por suplantación en los que hoy no responden, reforzar la comprobación de que el nombre del beneficiario coincide con el IBAN y endurecer los sistemas de detección de operaciones sospechosas. Nada de eso es exigible hasta su publicación y posterior transposición.
¿Te ha ocurrido y necesitas probarlo?
El rastro de un fraude digital se borra solo: los registros caducan y las cuentas se cierran. Cuanto antes se preserve, más queda que analizar.
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 (transposición PSD2). boe.es
Reglamento Delegado (UE) 2018/389 de la Comisión, por el que se complementa la Directiva (UE) 2015/2366 en lo relativo a las normas técnicas de regulación para la autenticación reforzada del cliente (SCA). eur-lex.europa.eu
Banco de España - “Memoria de Reclamaciones 2024”. Servicio de Reclamaciones. bde.es
Tribunal Supremo, STS 571/2025, de 9 de abril (Sala de lo Civil, ponente Manuel Almenar Belenguer, rec. 1151/2023) — ROJ STS 1671/2025 · ECLI:ES:TS:2025:1671. Responsabilidad del proveedor de servicios de pago por operaciones no autorizadas.
Comisión Europea. Propuesta de Directiva del Parlamento Europeo y del Consejo sobre servicios de pago y servicios de dinero electrónico en el mercado interior (PSD3), COM(2023) 366 final, de 28 de junio de 2023 — en tramitación. eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:52023PC0366
INCIBE — Balance de ciberseguridad 2025: 122.223 incidentes gestionados, de los que 45.445 fueron fraude online (+19 %) y 25.133 phishing. El Balance no desglosa el fraude bancario como categoría propia: la reclamación bajo PSD2 se apoya en la normativa y en la prueba del caso concreto, no en una estadística sectorial. Nota de prensa
Europol — Steal, deal and repeat: How cybercriminals trade and exploit your data, Internet Organised Crime Threat Assessment (IOCTA) 2025. europol.europa.eu
ThreatFabric. Anatsa Trojan Returns: Targeting Europe and Expanding Its Reach — análisis del troyano bancario y de su cadena de distribución.
Disclaimer: Este contenido tiene finalidad informativa y educativa. No constituye asesoramiento jurídico. Los casos descritos son ejemplos compuestos y anonimizados basados en tipologias reales de peritaje informático. Para reclamaciones bancarias concretas, consulte con un abogado especializado y solicite un informe pericial informático adaptado a su caso.
Última actualización: 16 de febrero de 2026 Autor: Jonathan Izquierdo, ex-CTO y 5x AWS Certified, perito informático forense Categoría: Marco Legal (LEG-031) Nivel técnico: 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