Fraude en pagos (BEC): controles mínimos para finanzas sin frenar la operativa

El fraude por suplantación en correo orientado a pagos, conocido habitualmente como BEC, afecta de forma directa a caja, control interno y continuidad operativa. No hace falta un ataque sofisticado para que ocurra: basta con que una persona con capacidad para tramitar o aprobar pagos actúe sobre una instrucción falsa que parece legítima.

Desde negocio, el impacto suele aparecer en varios frentes a la vez:

• Pérdida directa de fondos. Una transferencia enviada a una cuenta incorrecta puede ser muy difícil de revertir, especialmente si pasan horas antes de detectarlo.
• Coste operativo de investigación. Finanzas, compras, TI, cumplimiento y dirección acaban dedicando tiempo a reconstruir hechos, revisar evidencias y coordinar con banco y proveedores.
• Ruptura de confianza con proveedores o clientes. Si se modifica indebidamente un IBAN o se bloquea un pago legítimo por una investigación, la relación comercial se resiente.
• Debilidad de control interno. Un incidente suele revelar fallos de diseño: demasiada confianza en el correo, cambios de datos sin verificación independiente o excepciones mal documentadas.
• Dependencia de personas concretas. Cuando el control real descansa en “quien detecta algo raro”, el proceso no es robusto ni escalable.

La conclusión práctica es simple: el correo puede ser el vehículo, pero el problema de fondo está en cómo se autoriza, verifica y ejecuta el pago.

Acciones recomendadas

1. Implantar verificación fuera de banda para cambios de IBAN o datos sensibles.

Cualquier solicitud de cambio de cuenta, modificación de beneficiario o actualización de instrucciones de pago debe verificarse por un canal distinto al correo, usando solo contactos ya registrados.

1. Establecer doble aprobación con límites y segregación de funciones.

Quien crea o modifica datos no debería ser la misma persona que aprueba y ejecuta el pago. Además, los importes y tipos de pago deben tener umbrales claros.

1. Crear un circuito formal de urgencias.

Las urgencias existen, pero no deben saltarse controles sin dejar rastro. Conviene definir quién autoriza, qué evidencias se exigen y cuándo caduca la excepción.

1. Revisar el proceso de alta y cambio de proveedor.

Debe quedar claro quién puede cambiar qué campos, con qué documentación y con qué validaciones previas.

1. Endurecer cuentas críticas de correo e identidad.

Activar MFA, revisar accesos, monitorizar reglas de reenvío y proteger especialmente cuentas de finanzas, compras y dirección reduce la probabilidad de suplantación efectiva.

1. Definir un protocolo de respuesta en las primeras horas.

Finanzas y TI deben saber a quién llamar en el banco, qué evidencias conservar y cómo escalar internamente sin improvisar.

Qué es el BEC y por qué un correo puede saltarse controles

BEC son las siglas de Business Email Compromise, un término usado para describir fraudes en los que el atacante utiliza el correo electrónico —o algo que parece correo legítimo— para inducir un pago indebido o cambiar instrucciones de pago.

No siempre implica que una cuenta esté comprometida técnicamente. A veces el atacante:

• suplanta una dirección parecida a la real,
• escribe desde un dominio muy similar,
• responde dentro de un hilo antiguo,
• imita el tono de un directivo o de un proveedor,
• o aprovecha información pública para que el mensaje parezca creíble.

El éxito del fraude no depende tanto de “engañar al filtro” como de encajar en una rutina de trabajo. Si una petición llega con contexto plausible, tono urgente y apariencia correcta, puede pasar por legítima, sobre todo en equipos con mucho volumen y presión de tiempos.

Por eso, confiar solo en “detectar correos sospechosos” es insuficiente. El control decisivo está en que el proceso exija una validación adicional antes de mover dinero o cambiar datos críticos.

Dónde suele romperse el proceso

Hay varios puntos donde el proceso de pago suele volverse más vulnerable.

1. Cambio de cuenta bancaria del proveedor

Es un escenario frecuente: llega un correo indicando que el proveedor ha cambiado de banco, que hay una reorganización administrativa o que la próxima factura debe abonarse a otro IBAN. Si ese cambio se tramita solo por correo, el riesgo aumenta notablemente.

2. Urgencias y pagos “fuera de circuito”

Cuando alguien pide acelerar un pago “porque si no se para el suministro”, “porque hay cierre hoy” o “porque dirección lo necesita ya”, los controles se relajan. El atacante explota precisamente esa presión.

3. Autoridad simulada

Un mensaje que aparenta venir de dirección general, del CFO o de un responsable comercial puede empujar a actuar sin cuestionar. El problema no es solo la suplantación, sino la cultura de no contradecir una petición urgente de alguien con autoridad.

4. Datos de contacto no gobernados

Si el teléfono usado para verificar un cambio se toma del propio correo recibido, la verificación deja de ser fiable. El control solo funciona si el contacto ya estaba registrado y validado previamente.

5. Concentración excesiva de permisos

Si una misma persona puede modificar datos de proveedor, aprobar el pago y lanzarlo, el proceso tiene demasiados puntos ciegos. Aunque esa persona actúe de buena fe, un error basta.

Controles de proceso: lo que decide negocio

Los controles más eficaces no siempre son los más complejos. Suelen ser los que obligan a introducir una segunda comprobación independiente justo antes de que el error se convierta en una transferencia.

Doble aprobación y segregación de funciones

Conviene separar, al menos, estas funciones:

• alta o modificación de proveedor,
• validación del cambio,
• aprobación del pago,
• ejecución del pago.

No hace falta diseñar una burocracia excesiva, pero sí evitar que una sola persona cierre el ciclo completo sin contraste.

Además, los flujos deben tener límites por importe, tipo de pago o nivel de riesgo. Por ejemplo, un pago ordinario a proveedor conocido no debería tener el mismo tratamiento que un primer pago a una cuenta recién cambiada.

Verificación fuera de banda

Es el control clave para cambios sensibles. “Fuera de banda” significa verificar por un canal distinto al que originó la solicitud.

Buenas prácticas mínimas:

• usar un teléfono ya registrado en el maestro de proveedores,
• no usar números incluidos en el correo sospechoso,
• documentar fecha, hora, interlocutor y resultado,
• exigir esta validación para cambios de IBAN, beneficiario o instrucciones de pago.

La idea no es desconfiar de todo, sino asumir que el correo por sí solo no basta para validar cambios que afectan a tesorería.

Checklist anti-urgencia

Las urgencias deben pasar por una lista breve de validación. Si el proceso no incorpora esa pausa obligatoria, la presión del momento sustituye al control.

Preguntas útiles:

• ¿Es un cambio respecto al patrón habitual?
• ¿El contacto y el canal son los esperados?
• ¿Existe pedido, factura o soporte coherente?
• ¿Se ha verificado por canal independiente?
• ¿La urgencia está formalmente aprobada?

Circuito de excepción con trazabilidad

Hay situaciones reales que requieren rapidez. La solución no es prohibir excepciones, sino gobernarlas.

Un circuito de excepción debería definir:

• quién puede declararla,
• quién la aprueba,
• qué documentación mínima se exige,
• cómo se registra,
• y cuándo se revisa a posteriori.

Así se preserva velocidad sin convertir la excepción en una puerta trasera permanente.

Gobierno del dato de proveedor

Cuanto mejor esté definido el onboarding de proveedores, menos espacio hay para el fraude. El alta inicial debe incluir:

• datos bancarios verificados,
• contactos administrativos validados,
• restricciones sobre quién puede solicitar cambios,
• y evidencia conservada de cada modificación.

Un maestro de proveedores bien gobernado reduce dependencias personales y discusiones posteriores.

Controles técnicos mínimos: lo que habilita TI

Los controles técnicos no sustituyen a los de proceso, pero reducen la superficie de ataque y dificultan la suplantación o el uso indebido de cuentas reales.

MFA en cuentas críticas

Las cuentas de finanzas, compras, dirección y administración deben tener autenticación multifactor. Esto no elimina el riesgo por completo, pero eleva de forma clara la dificultad para comprometer accesos.

Protección reforzada de cuentas privilegiadas o sensibles

Merece atención especial cualquier cuenta con capacidad de:

• aprobar pagos,
• modificar datos de proveedor,
• acceder a buzones compartidos de finanzas,
• o emitir instrucciones en nombre de directivos.

La revisión periódica de accesos, delegaciones y permisos es tan importante como el propio MFA.

Revisión de reglas de correo y reenvíos

Las reglas automáticas de reenvío o borrado pueden ocultar mensajes, desviar conversaciones o ayudar a que una intrusión pase desapercibida. Revisarlas de forma periódica en cuentas críticas es una medida básica y útil.

Autenticación de dominio

La configuración de mecanismos de autenticación del dominio de correo ayuda a reducir ciertas formas de suplantación. No garantiza que no vayan a llegar mensajes creíbles, pero sí mejora la base de protección y visibilidad.

Alertas y señales operativas sencillas

Sin entrar en herramientas concretas, resulta útil que TI pueda detectar señales como:

• accesos anómalos a cuentas críticas,
• creación de reglas sospechosas,
• reenvíos externos no habituales,
• o cambios de permisos en buzones sensibles.

No hace falta buscar una detección perfecta; se trata de ganar capacidad de respuesta.

Qué hacer si sospechas fraude: las primeras 2 horas

Cuando hay sospecha razonable, la prioridad es contener y escalar rápido. El tiempo importa.

1. Contactar de inmediato con el banco

Si el pago ya salió o está en curso, hay que activar el procedimiento bancario interno cuanto antes. Para eso conviene tener preparado:

• contacto principal y alternativo,
• números de cuenta implicados,
• referencia del pago,
• hora aproximada de emisión,
• y persona responsable de la gestión.

2. Preservar evidencias

No conviene borrar correos, modificar buzones ni reenviar sin control. Es mejor conservar:

• mensaje original y cabeceras si están disponibles,
• justificantes de pago,
• registros de aprobación,
• datos del proveedor en el momento del incidente,
• capturas o exportes del flujo interno.

3. Escalar internamente

Deben notificarse al menos:

• finanzas/tesorería,
• responsable de compras si afecta a proveedor,
• TI o seguridad de correo/identidad,
• y control interno, compliance o dirección según el impacto.

4. Bloquear cambios adicionales

Si hay sospecha sobre una cuenta o un proveedor, conviene congelar temporalmente nuevas modificaciones relacionadas hasta completar una revisión mínima.

5. Verificar si hay compromiso de cuenta

TI debe revisar si hubo accesos extraños, reglas de reenvío, delegaciones no autorizadas o actividad inusual en el buzón implicado.

6. Informar al proveedor real

Si el incidente afecta a una relación comercial legítima, el proveedor debe ser informado por un canal fiable para evitar nuevos errores y alinear hechos.

Errores comunes

Confiar solo en filtros de correo

Los filtros ayudan, pero no están diseñados para sustituir decisiones de control interno. Un correo convincente puede no parecer técnicamente malicioso.

Aceptar urgencias sin una vía formal

Cuando la urgencia se gestiona “por favor, hazlo y luego regularizamos”, el proceso deja de proteger a la empresa y también a la persona que ejecuta.

Verificar con teléfonos no confirmados

Llamar al número que aparece en el propio correo sospechoso no es verificación independiente.

Pensar que el problema es solo de TI

La raíz suele estar en un cruce entre proceso, permisos, cultura de aprobación y uso del correo. Si negocio no diseña el control, TI no puede compensarlo solo.

No revisar el maestro de proveedores

Un alta débil o cambios mal documentados generan una base de datos que facilita el fraude y complica cualquier investigación posterior.

Plantilla: checklist de verificación de pago

Antes de aprobar o ejecutar un pago sensible, este checklist puede servir como control operativo mínimo:

• [ ] ¿El proveedor ya existe y está correctamente dado de alta?
• [ ] ¿Ha habido cambio reciente de IBAN, beneficiario o instrucciones?
• [ ] ¿Ese cambio está documentado y validado?
• [ ] ¿La verificación se ha hecho por un canal distinto al correo?
• [ ] ¿Se ha usado un contacto previamente registrado?
• [ ] ¿Existe soporte comercial o contractual coherente?
• [ ] ¿El importe y el tipo de pago encajan con el patrón habitual?
• [ ] ¿Se requiere segunda aprobación por importe o excepción?
• [ ] ¿La urgencia, si existe, está autorizada y registrada?
• [ ] ¿Queda trazabilidad suficiente para auditoría posterior?

Si una o varias respuestas son negativas, el pago debería pasar a revisión adicional.

Plantilla: guion de llamada de verificación (call-back) para cambios de IBAN

Un guion simple ayuda a evitar validaciones ambiguas.

Antes de llamar

• Recuperar el teléfono del maestro de proveedores, no del correo recibido.
• Tener a mano la referencia del proveedor y la solicitud de cambio.
• Definir qué dato se necesita confirmar exactamente.

Guion sugerido

1. “Hola, te llamo de [empresa] para validar una solicitud de cambio de datos de pago.”
2. “Por seguridad, necesito confirmar que hablo con la persona autorizada registrada para temas administrativos.”
3. “¿Podéis confirmar si habéis solicitado un cambio de cuenta bancaria?”
4. “No necesito que me enviéis datos por este canal si no corresponde; solo confirmar si la solicitud es legítima y quién debe remitir la documentación válida.”
5. “Vamos a registrar esta validación con fecha y hora antes de aplicar cualquier cambio.”

Después de la llamada

• Registrar quién atendió, desde qué número, a qué hora y qué confirmó.
• Si hay dudas o incoherencias, no ejecutar el cambio.
• Escalar si el proveedor dice no haber solicitado ninguna modificación.

La idea clave: proteger el proceso, no solo el correo

El BEC se aprovecha de una realidad muy simple: los pagos se mueven rápido y el correo sigue siendo un canal cotidiano de instrucción y coordinación. Por eso, el objetivo no debe ser construir una promesa de “riesgo cero”, sino impedir que una petición engañosa atraviese todo el circuito sin una verificación independiente.

La buena noticia es que esto puede hacerse sin frenar la operativa. Un diseño razonable combina tres capas:

• proceso claro, para que nadie tenga que improvisar;
• controles técnicos mínimos, para reducir exposición;
• excepciones gobernadas, para mantener velocidad con trazabilidad.

Cuando ese diseño existe, la empresa depende menos del olfato individual y más de un sistema que pone fricción solo donde realmente importa: justo antes de mover dinero.