El 12 de septiembre de 2026, la empresa fintech Revolut confirmó lo que describió como una sofisticada estafa de suplantación externa: una parte no autorizada utilizó un correo electrónico en el dominio legítimo de una agencia gubernamental para enviar solicitudes fraudulentas de información de clientes. Las solicitudes se atendieron antes de que se detectara el engaño.

Lo que hace que este incidente merezca su atención es que no contiene ninguna brecha en el sentido habitual. Ninguna vulnerabilidad de software, ninguna contraseña filtrada, ningún malware. La propia Revolut afirmó que sus sistemas y los fondos de sus clientes no se vieron afectados. Alguien pidió los datos de la forma correcta, por el canal correcto, y los recibió. Precisamente por eso esto importa a toda empresa que guarde registros de clientes, no solo a los bancos.

Qué está realmente confirmado

Nos limitamos a lo que anunció la empresa y a lo que informaron medios especializados, porque la investigación sigue en curso y gran parte aún no se ha revelado:

  • El método: correo enviado desde una cuenta no autorizada dentro de un dominio que pertenece a una agencia gubernamental real, con la apariencia de una solicitud oficial de información.
  • Los datos: datos de identidad y de contacto, incluidos fecha de nacimiento, dirección postal, correo electrónico y número de teléfono, además de copias de documentos de identidad como pasaportes y permisos de conducir, junto con las imágenes de verificación facial recopiladas durante los controles de conocimiento del cliente (KYC).
  • La escala: la empresa habló de un número limitado de clientes y no publicó ninguna cifra.
  • La agencia: Revolut se negó a nombrar el organismo gubernamental cuyo dominio se utilizó, alegando la investigación en curso.
  • La respuesta: se bloqueó la dirección, se notificó directamente a los clientes afectados y la empresa alertó a la agencia gubernamental correspondiente, a las fuerzas del orden, a los reguladores financieros y a las autoridades de protección de datos.

Un investigador de seguridad cripto conocido como ZachXBT evaluó que los objetivos parecían ser clientes de alto patrimonio, lo que sugiere la construcción de perfiles detallados más que una recopilación indiscriminada. Se trata de la valoración de un investigador, no de una declaración de la empresa, y la citamos como tal.

Por qué funcionó la solicitud: autenticación no es autorización

La mayoría de los sistemas de correo corporativo se basan en controles técnicos que confirman que un mensaje procede realmente del dominio que afirma. Esos controles funcionan bien contra la falsificación común: quien suplanta un dominio que no controla es rechazado. Pero se diseñaron para responder exactamente a una pregunta: ¿salió este mensaje de ese dominio?

Esa no es la pregunta que usted necesita responder. Su pregunta es si la persona que escribió el mensaje está autorizada a pedir lo que pide. Ningún control de correo responde a eso. La distancia entre ambas preguntas es la distancia entre autenticación y autorización, y es la brecha por la que pasó toda esta operación. Cuando la cuenta remitente está dentro del dominio auténtico, ya sea comprometida o mal aprovisionada, todos los indicadores de confianza que su equipo puede ver estarán en verde.

La consecuencia práctica: el trabajo de su pasarela de correo termina al entregar la solicitud intacta. Juzgar la solicitud es trabajo humano, y requiere un procedimiento escrito en lugar del instinto individual.

Su empresa recibe la misma solicitud en una forma más sencilla

Es fácil archivar esto como una historia lejana de una fintech europea. Pero las solicitudes que llegan cada día a las empresas saudíes son lo mismo con ropa más sencilla: un correo que pide el estado de cuenta de un cliente, un mensaje que solicita datos de empleados con un fin regulatorio, una llamada que le pide confirmar los detalles de un contrato, una comunicación desde una dirección con un nombre oficial conocido que pide documentos para completar un trámite.

En la mayoría de las pequeñas y medianas empresas esa solicitud se gestiona así: llega a un empleado, el remitente parece oficial, negarse ante un organismo oficial parece más arriesgado que cumplir, y se envía el archivo. No queda registro de quién lo pidió, qué se envió ni cuándo. No hay ningún paso de verificación independiente. Cuando el problema sale a la luz más tarde, la empresa no tiene nada con qué reconstruir los hechos.

Fíjese también en la presión que se aplica. La urgencia y la autoridad oficial juntas son lo que desactiva la verificación. Un empleado que teme que lo culpen de obstaculizar un trámite gubernamental se saltará la llamada de confirmación, y ese es el efecto buscado del método, no un efecto secundario.

Qué le exige la ley saudí

La Ley de Protección de Datos Personales (PDPL) no deja esto abierto. Impone a su empresa una doble obligación: divulgar solo cuando esté permitido e informar cuando se equivoque.

  • El artículo 15 establece los casos en que pueden divulgarse datos personales, incluido cuando la parte solicitante es una entidad pública y la solicitud persigue un fin de seguridad, aplica otra ley o cumple requisitos judiciales, según lo especificado en el reglamento.
  • El artículo 16 regula los casos en que debe denegarse la divulgación, incluido cuando afectaría a la seguridad nacional, pondría en peligro la seguridad de las personas o interferiría en una investigación en curso.
  • El artículo 20 obliga al responsable del tratamiento a notificar a la autoridad competente y a los titulares de los datos cualquier brecha o divulgación ilícita. El reglamento de aplicación fija un plazo de 72 horas para notificar a la autoridad competente a través de la Plataforma Nacional de Gobernanza de Datos.

Si se leen los tres juntos, surge el punto decisivo: la ley concede el derecho a la entidad pública, no al correo electrónico. Que una solicitud llegue desde el dominio de una entidad pública no la convierte en una solicitud de esa entidad. La obligación legal de verificar sigue recayendo en usted como responsable del tratamiento, y no se transfiere a un remitente solo porque parecía oficial.

La visión de Origami

Origami es una empresa tecnológica que desarrolla sistemas para empresas saudíes, y un patrón que vemos una y otra vez es que casi toda la inversión en seguridad se destina a impedir el acceso no autorizado: contraseñas, autenticación de dos factores, cortafuegos. Son necesarios, pero vigilan una sola puerta. El incidente del que hablamos nunca entró por la puerta. Llamó, pidió los datos y se los entregaron. Ninguna configuración técnica impide que un empleado autorizado envíe un archivo a alguien que lo pidió de una forma que parecía correcta.

Por eso tratamos la salida de datos de la empresa como un procedimiento integrado en el sistema y no como una pauta escrita en un manual: quién tiene permiso para exportar datos de clientes, si cada exportación queda registrada con quién la hizo, cuándo y por qué, y si las solicitudes de terceros siguen un circuito de aprobación. Una empresa que puede responder en un minuto qué datos salieron de aquí el mes pasado y por qué tiene algo con lo que defenderse. Una empresa que no puede descubrirá la brecha el día en que necesite la respuesta.

Un procedimiento de una página para adoptar esta semana

Esto no necesita un proyecto ni un presupuesto. Necesita una regla escrita y publicada que proteja a su empleado de tener que decidir solo y bajo presión:

  • Ningún dato de clientes o empleados sale solo con base en un mensaje entrante. El mensaje abre la solicitud; no la ejecuta, por muy oficial que parezca el remitente y por muy urgente que sea el tono.
  • Verifique por un canal independiente. No responda al mensaje y no llame a un número escrito dentro de él. Llame al número publicado en el sitio web oficial de la entidad. Ese único paso habría detenido toda esta operación.
  • Un aprobador designado. Una persona autorizada para entregar datos a una parte externa, con un suplente designado para las ausencias. Repartir el permiso entre todos significa que nadie rinde cuentas.
  • Un registro escrito de cada solicitud. Quién lo pidió, en calidad de qué, qué datos, quién lo aprobó, cómo se verificó y la fecha. Basta una fila en una hoja de cálculo, y su valor se nota un año después, no hoy.
  • Envíe lo mínimo. Si la solicitud es legítima, envíe exactamente lo que se pidió, no el expediente completo ni la tabla entera. El volumen que envía es el tamaño del daño si la solicitud resulta ser fraudulenta.
  • Conozca la vía de notificación antes de necesitarla. Quién notifica a la Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA) dentro de las 72 horas, a través de qué plataforma y con qué detalles. El tiempo dedicado a buscar el procedimiento se descuenta directamente del plazo.

El principio que sostiene todo esto es que verificar no es obstaculizar. Un organismo oficial auténtico no pondrá objeciones a una llamada de confirmación a su propio número publicado, y quien se opone a ser verificado es exactamente quien debe ser verificado. Póngalo por escrito para su equipo, de modo que rechazar una solicitud nunca sea un riesgo personal que un solo empleado tenga que cargar.

Fuentes

  • TechCrunch: la confirmación del incidente por parte de Revolut el 12 de septiembre de 2026, su comunicado y las categorías de datos divulgados.
  • Bloomberg: la revelación de la empresa de que un número limitado de clientes se vio afectado mediante una estafa por correo electrónico.
  • Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA): la autoridad competente para la Ley de Protección de Datos Personales (PDPL), su reglamento de aplicación y la Plataforma Nacional de Gobernanza de Datos.
  • Ley de Protección de Datos Personales (PDPL): el texto oficial, incluidos los artículos sobre divulgación permitida, divulgación prohibida y notificación de brechas.
  • Autoridad Nacional de Ciberseguridad (NCA): controles que abarcan la protección de datos y la gestión de incidentes cibernéticos en las organizaciones.