Ciberfraude a Flöid en Perú: 4 millones de soles, cheques de gerencia y bitcoin en minutos

Los ciberfraudes que más daño hacen a las empresas latinoamericanas no son los que salen en las películas. No hay un genio que rompe cifrados; hay alguien que consigue credenciales, alguien que conoce la operación desde adentro y una red de personas dispuestas a prestar su cuenta bancaria por una comisión. El caso de Flöid en Perú, investigado por la División de Investigación de Ciberdelincuencia (Dirincib) y el Departamento de Seguridad de Bancos de la Policía Nacional, y publicado por El Comercio e Infobae en agosto de 2026, reúne esos tres ingredientes con precisión de manual.

Según la cobertura periodística, la red habría desviado más de 4 millones de soles de la plataforma de pagos hacia cuentas personales en Lima, los habría retirado mediante cheques de gerencia en agencias de Miraflores y habría intentado convertirlos en bitcoin para hacerlos irrastreables. La policía intervino cuando el sistema bancario dio la alerta. Este artículo reconstruye la mecánica y la traduce a lo que una empresa mediana debe revisar en su propia operación de pagos, en la línea de lo que planteamos en ciberseguridad para PYMEs.

¿Qué pasó con Flöid y cuánto dinero se movió?

Flöid es una empresa tecnológica de origen chileno que procesa pagos y conexiones bancarias para otras compañías, con operación en Perú. De acuerdo con lo publicado por Infobae, la empresa denunció transferencias que no reconocía desde su plataforma hacia cuentas personales en Lima por casi 4 millones de soles. La investigación policial, según El Comercio, identificó a un presunto cabecilla con antecedentes por estafa que se presentaba como empresario y como miembro de la Gran Logia de los Masones del Perú para dar confianza a quienes reclutaba.

El 4 de agosto de 2026, una alerta del sistema bancario permitió a la policía intervenir a varios implicados mientras intentaban cobrar cheques de gerencia por montos altos en agencias de las avenidas Larco y Diagonal, en Miraflores. Se evitó el retiro de S/734.800, pero el perjuicio total contra la empresa se estimó en alrededor de 4 millones de soles. Las personas detenidas están bajo investigación y gozan de presunción de inocencia; los detalles del ataque informático en sí no han sido divulgados por completo.

¿Cómo funcionó la red del falso masón paso a paso?

El primer paso fue el acceso. Según la reconstrucción de El Comercio, el presunto cabecilla se alió con un hacker que logró vulnerar la plataforma de pagos. Antes de mover el grueso del dinero, hicieron transferencias de prueba de S/2.000 y S/300.000. Esa fase de prueba es característica: sirve para confirmar que el acceso funciona, medir qué montos disparan alertas y saber cuánto tiempo tarda alguien en notar el movimiento. Si nadie reacciona a una transferencia de 300.000 soles, la red sabe que puede ir por más.

El segundo paso fue la extracción. El dinero se envió a cuentas de personas reclutadas como prestacuentas o mulas financieras, convencidas de recibir fondos a cambio de una comisión. Esas personas acudieron a agencias bancarias para retirar mediante cheques de gerencia emitidos a nombre de terceros, entre ellos una cambista, con la idea de convertir los soles en dólares sin declarar y luego en bitcoin a través de billeteras privadas. El tercer paso, el que la policía interrumpió, era precisamente esa conversión: una vez en cripto, el dinero habría sido muy difícil de seguir, como analizamos en el caso de la trazabilidad cripto en PDVSA.

¿Por qué el ataque externo empezó por una puerta interna?

El dato más importante del caso no es el hacker ni el bitcoin, sino una línea de la investigación: la policía busca a un exejecutivo de la empresa afectada que habría actuado como contacto inicial para el reclutamiento del presunto cabecilla. Si eso se confirma, el ataque no empezó con una vulnerabilidad técnica sino con conocimiento interno: cómo funciona la plataforma, qué montos pasan sin alerta, qué accesos siguen vigentes después de que alguien se va. Es el patrón que vemos con más frecuencia en empresas medianas y que documentamos en el estudio de PwC sobre fraude en Perú: la mayoría del fraude tiene un componente interno.

Las credenciales que no se revocan al salir un empleado, los accesos compartidos, los usuarios genéricos con permisos de transferencia y la falta de doble autorización para movimientos grandes son las vulnerabilidades reales de la mayoría de las empresas, y ninguna se resuelve con un antivirus. Se resuelven con un inventario de accesos, una regla de revocación inmediata y una separación entre quien puede ordenar un pago y quien puede aprobarlo.

¿Qué alertas funcionaron y cuáles faltaron?

Funcionó la alerta bancaria: el sistema del banco detectó el patrón de cheques de gerencia por montos altos a nombre de terceros y avisó a la policía, lo que permitió frenar S/734.800. Faltó la alerta de la propia plataforma en la fase de prueba: una transferencia de S/300.000 fuera del patrón habitual de la operación debería haber generado una verificación antes de que saliera la siguiente. Y faltó la alerta más temprana de todas, la de acceso: un inicio de sesión con credenciales válidas desde un dispositivo o una ubicación inusual, o fuera del horario de operación, es la señal que precede a casi todos los fraudes de este tipo.

Para una empresa mediana la traducción es directa. Los pagos salientes necesitan límites por operación y por día, aprobación de una segunda persona por encima de un umbral, verificación de beneficiarios nuevos antes del primer pago y una revisión diaria de movimientos por alguien que no los ejecuta. El banco puede ayudar, pero su alerta llega cuando el dinero ya salió de la empresa. La alerta que protege el patrimonio es la que suena antes.

¿Qué controles reducen este riesgo en una empresa mediana?

Primero, gestión de accesos: inventario de quién puede entrar a qué sistema con qué permisos, revocación el mismo día de la salida de cualquier empleado o proveedor, autenticación de dos factores obligatoria en todo sistema que mueva dinero y prohibición de usuarios compartidos. Segundo, separación de funciones en pagos: quien registra un beneficiario no aprueba el pago, y quien aprueba no ejecuta. Tercero, límites y alertas configurados en la plataforma y en el banco: montos máximos por operación, por día y por beneficiario nuevo, con notificación inmediata al dueño o al director financiero.

Cuarto, monitoreo de patrones: transferencias de prueba pequeñas seguidas de una grande, pagos a personas naturales desde cuentas que normalmente pagan a empresas, concentración de pagos en pocas horas. Quinto, capacitación del equipo en ingeniería social, porque el falso masón no engañó a un sistema sino a personas. Sexto, un plan de respuesta escrito: a quién llamar en el banco, cómo congelar cuentas destino, qué evidencia preservar y cómo denunciar en la primera hora, que es cuando el dinero todavía se puede recuperar. En este caso, la ventana entre el retiro en efectivo y la conversión a bitcoin era de minutos.

¿Cómo saber si tu operación de pagos tiene una puerta abierta?

Flöid se enteró cuando vio transferencias que no reconocía. Una empresa mediana puede enterarse antes, revisando cómo están configurados sus accesos y sus pagos. Un diagnóstico de fugas operativas toma los datos que la empresa ya tiene (usuarios activos y sus permisos, historial de altas y bajas de personal, beneficiarios registrados, pagos ejecutados por usuario, horario y monto, límites configurados, cambios de datos bancarios de proveedores) y los cruza para mostrar qué accesos siguen vivos sin dueño, qué usuarios pueden registrar y aprobar a la vez, qué pagos salieron fuera de patrón y qué beneficiarios nuevos nadie verificó. Aquí explicamos cómo funciona el proceso.

El diagnóstico dura cuatro semanas, no detiene la operación y termina con un informe de hallazgos y un plan de contención priorizado. Con el Bono de Confianza, ese informe completo es tuyo siempre, con o sin hallazgos. El hacker es la parte visible; la credencial que nadie revocó y el pago que nadie tuvo que aprobar son la parte que te corresponde cerrar.

Hablar con un asesor  ·  Volver al blog

Preguntas frecuentes

¿Qué es Flöid y qué le pasó?

Una empresa tecnológica de origen chileno que procesa pagos, con operación en Perú. Según El Comercio e Infobae, en 2026 denunció transferencias no reconocidas desde su plataforma hacia cuentas personales en Lima por alrededor de 4 millones de soles; la policía desarticuló en agosto de 2026 a la red presuntamente responsable.

¿Quién era el falso masón?

El presunto cabecilla de la red, con antecedentes por estafa, que se presentaba como empresario y miembro de una logia masónica para ganar la confianza de las personas que reclutaba como prestacuentas. Está bajo investigación y goza de presunción de inocencia.

¿Cómo retiraban el dinero?

Mediante cheques de gerencia emitidos a nombre de terceros, incluida una cambista, cobrados en agencias bancarias de Miraflores, con el plan de convertir el efectivo en dólares y luego en bitcoin. Una alerta bancaria permitió frenar retiros por S/734.800.

¿Hubo participación interna?

La investigación busca a un exejecutivo de la empresa afectada que habría sido el contacto inicial para reclutar al presunto cabecilla. De confirmarse, el ataque habría empezado con conocimiento interno y no con una falla puramente técnica.

¿Qué debe revisar una empresa mediana para no ser la siguiente?

Inventario y revocación inmediata de accesos, doble factor en sistemas que mueven dinero, separación entre quien registra, aprueba y ejecuta pagos, límites y alertas por monto y beneficiario nuevo, monitoreo de transferencias de prueba y un plan de respuesta para la primera hora.

Aviso: este artículo es informativo y se basa en la cobertura de El Comercio, Infobae y Panamericana sobre la investigación de la Policía Nacional del Perú (agosto de 2026). El proceso está en curso y las personas mencionadas gozan de presunción de inocencia; las cifras son las reportadas por la prensa y pueden variar. No constituye asesoría legal ni técnica.