Fraude en pagos: por qué el registro de la operación no prueba que el cliente la autorizó

La regla de reparto de la prueba

El Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago —texto consolidado, vigente— establece un reparto de la carga de la prueba que no es el ordinario, y conviene leerlo despacio porque de él depende todo lo demás.

El artículo 44.1 dispone que cuando un usuario «niegue haber autorizado una operación de pago ya ejecutada o alegue que ésta se ejecutó de manera incorrecta, corresponderá al proveedor de servicios de pago demostrar que la operación de pago fue autenticada, registrada con exactitud y contabilizada, y que no se vio afectada por un fallo técnico u otra deficiencia del servicio prestado».

El artículo 44.3 añade que corresponde al proveedor «probar que el usuario del servicio de pago cometió fraude o negligencia grave».

Y el artículo 45.1 ordena la devolución inmediata del importe de la operación no autorizada, salvo que el proveedor tenga motivos razonables para sospechar fraude.

Es decir: no es el cliente quien debe probar que no autorizó, es la entidad quien debe probar que la operación fue autenticada y que, si hubo incumplimiento, fue por fraude o negligencia grave del usuario.

El apartado que casi nunca se cita

Entre esos dos preceptos hay un tercero que rara vez aparece en los escritos y que es el más útil. El artículo 44.2 dice, literalmente:

«A los efectos de lo establecido en el apartado anterior, el registro por el proveedor de servicios de pago, incluido, en su caso, el proveedor de servicios de iniciación de pagos, de la utilización del instrumento de pago no bastará, necesariamente, para demostrar que la operación de pago fue autorizada por el ordenante, ni que éste ha actuado de manera fraudulenta o incumplido deliberadamente o por negligencia grave una o varias de sus obligaciones con arreglo al artículo 41.»

La norma anticipa el argumento que la entidad va a emplear y lo desactiva de antemano. Aportar el log que dice «SCA completada, OTP validado a las 14:32» acredita que el sistema registró una autenticación. No acredita, por sí solo, ni que quien la completó fuera el titular ni que el titular fuese negligente.

Lo que queda por determinar después de ese registro es una cuestión técnica. Y ahí es donde un informe pericial tiene algo que decir.

Qué significa «reforzada», en términos verificables

El artículo 3.5 del mismo texto define la autenticación reforzada de cliente como la basada en dos o más elementos de las categorías conocimiento, posesión e inherencia,

«que son independientes –es decir, que la vulneración de uno no compromete la fiabilidad de los demás–, y concebida de manera que se proteja la confidencialidad de los datos de identificación».

Esa cláusula entre guiones es un requisito, no una descripción. Y es comprobable.

Cuando la contraseña se introduce en el navegador de un teléfono y el código de un solo uso llega por SMS a ese mismo teléfono, y el teléfono está comprometido, la vulneración de un elemento sí ha comprometido la fiabilidad del otro. Los dos factores existían formalmente y se registraron como completados, pero no eran independientes en el sentido del artículo 3.5. Lo mismo ocurre en un duplicado fraudulento de tarjeta SIM: el factor de posesión no estaba en poder del usuario, aunque el registro diga que sí.

Esto no es una interpretación forzada de la norma. Es la lectura literal de una definición que exige independencia, aplicada a un escenario en que la independencia no se dio.

La vinculación dinámica

El artículo 68.1 determina cuándo debe aplicarse autenticación reforzada: al acceder a la cuenta en línea, al iniciar una operación de pago electrónico y al realizar por canal remoto cualquier acción que pueda entrañar riesgo de fraude.

El artículo 68.2 añade un requisito específico para los pagos remotos: la autenticación debe incluir «elementos que asocien dinámicamente la operación a un importe y un beneficiario determinados».

Este requisito se incumple con frecuencia en los fraudes que operan como intermediario en tiempo real, en los que la víctima interactúa con una réplica del sitio de la entidad que retransmite sus credenciales. Si lo que el usuario vio y confirmó en la pantalla de autorización no era el importe y el beneficiario de la operación que finalmente se ejecutó, la vinculación dinámica falló. Y si falló, la operación no fue autenticada en la forma que exige el artículo 68.2.

Determinar qué vio exactamente el usuario, y si coincide con lo ejecutado, es trabajo pericial: está en los registros del dispositivo, en el historial del navegador, en las notificaciones recibidas y en los mensajes conservados.

Qué puede establecer un informe pericial

Con acceso al dispositivo del cliente, a los mensajes recibidos y a la documentación que la entidad aporte, un dictamen puede pronunciarse sobre:

• La vía de entrada. Si hubo un mensaje o una llamada previa, qué pedía, desde qué número o dominio, y si el enlace conducía a un dominio distinto del de la entidad. Los encabezados completos del correo y los metadatos del mensaje lo documentan, y es el objeto propio del peritaje de correo electrónico y phishing.
• La independencia real de los factores. Por qué canal llegó cada elemento de autenticación y si ambos pasaron por un mismo punto comprometido.
• La presencia de software de control remoto o de superposición de pantalla en el dispositivo en la fecha de la operación, que explicaría cómo se completó una autenticación sin intervención consciente del titular.
• El duplicado de línea. Si hubo un cambio de tarjeta SIM o una portabilidad no solicitada en las horas previas, y si el terminal perdió cobertura en ese intervalo.
• La correspondencia entre lo autorizado y lo ejecutado, a efectos del artículo 68.2.
• La coherencia interna de lo que aporta la entidad. Si el registro identifica dispositivo, dirección IP o huella de navegador, si esos datos corresponden al cliente, y si el propio registro es verificable o es una manifestación sin soporte.

Y qué no puede establecer

Conviene decirlo con la misma claridad. Un perito no puede identificar a quién estaba detrás del fraude: eso requiere diligencias que solo el órgano judicial puede acordar frente a operadores y entidades. Tampoco puede afirmar que no existió negligencia: puede describir qué ocurrió técnicamente y con qué grado de sofisticación, y es el tribunal quien valora si la conducta del usuario fue o no gravemente negligente. Y no siempre hay rastro: si el dispositivo se ha restaurado, se ha cambiado o se han borrado los mensajes, hay conclusiones que ya no pueden sostenerse.

La ausencia de rastro, eso sí, también es un dato: si la entidad sostiene que hubo negligencia grave del usuario y no hay indicio técnico alguno que lo respalde, quien tenía la carga de probarlo no la ha levantado.

Qué conservar

Si el fraude es reciente, el valor de la prueba se decide en las primeras horas:

• No restaure el teléfono ni el ordenador, y no lo lleve a reparar. Una restauración de fábrica elimina precisamente lo que hay que documentar.
• No borre los mensajes ni los correos, por incómodos que resulten, y no los reenvíe: reenviar altera los encabezados que identifican el origen.
• Solicite por escrito a la entidad el detalle de la operación y del procedimiento de autenticación aplicado. Lo que entregue, y lo que no entregue, forma parte del material a analizar.
• Pida a su operador de telefonía el registro de cambios de SIM y de portabilidades del periodo.
• Anote la hora en que detectó el cargo y en que recibió cada mensaje. Las horas son la columna vertebral del análisis.

La adquisición forense del dispositivo se documenta conforme a UNE-EN ISO/IEC 27037:2016 y el dictamen se estructura según UNE 197001:2019, de modo que el método quede descrito con detalle suficiente para que otro perito pueda repetirlo y obtener el mismo resultado.