Fraude interno en P2P: cuando el empleado y el pago no cuadran con los registros

En un equipo P2P hipotético, una revisión de fraude interno detectó tres hechos. Una misma transferencia bancaria está vinculada a dos solicitudes exitosas. El beneficiario de un pago se cambió después de la aprobación. Varias excepciones de una misma contraparte las cierra siempre la misma pareja de empleados. Ningún hecho por separado demuestra un fraude. Juntos exigen detener las acciones correspondientes y revisar la evidencia mientras el dinero y el historial siguen disponibles.

Es un escenario defensivo compuesto, no el relato de un procesador concreto. Aquí, fraude interno significa el abuso intencional del acceso o de las facultades de un empleado, incluso en colusión. Los errores, una interfaz incómoda y un turno sobrecargado pueden generar señales parecidas. Por eso los controles deben detectar contradicciones y la investigación debe establecer la causa, sin reemplazarla por una acusación.

Primer episodio: la confirmación convence, pero el dinero no alcanza

Un comprobante falso no solo es peligroso para un trader sin experiencia. Dentro del equipo puede convertirse en un fundamento cómodo para una decisión manual si el revisor solo ve el documento que subió el operador. Entonces dos personas participan formalmente en la aprobación, pero ambas confían en la misma fuente no confiable. La regla de los dos empleados no crea independencia por sí sola.

Para confirmar un ingreso hace falta una fuente autorizada del movimiento real de fondos, independiente de la captura de pantalla de la contraparte: un registro bancario o la confirmación correspondiente del proveedor de pagos. El documento del cliente ayuda a encontrar la operación, pero no debe crear dinero automáticamente en los registros. Si la fuente no está disponible temporalmente, la solicitud queda pendiente de verificación y no pasa a exitosa porque lo pida un gerente.

La verificación debe tener en cuenta la unicidad. Monto, fecha y nombre pueden coincidir en operaciones distintas. El sistema vincula un identificador estable del movimiento bancario con el asiento contable y no permite reutilizarlo sin que se note. Si la referencia no es única o la fuente no la proporciona, hace falta otro método de asociación y un estado explícito de incertidumbre. No se puede declarar suficiente el control solo porque el campo UTR está completo.

Segundo episodio: se aprobó una cosa y se envió otra

El cambio de beneficiario es especialmente peligroso cuando la revisión y la ejecución usan versiones distintas de los datos bancarios. El revisor aprobó un pago al cliente, luego un empleado corrigió la cuenta y el sistema conservó la aprobación anterior. En el log hay dos firmas, pero ninguna corresponde al conjunto de datos que realmente se envió.

OWASP, en sus recomendaciones sobre autorización de transacciones, subraya que la confirmación debe estar ligada a los datos relevantes de la operación. Para el diseño operativo P2P, esto significa que la aprobación se refiere a un monto, una moneda, un beneficiario y una versión de la orden concretos. Cambiar datos sustanciales exige una nueva decisión. Es una aplicación propuesta de un principio general, no una afirmación sobre la protección integrada de cualquier panel.

Las facultades de editar el beneficiario, autorizar una excepción y ejecutar el pago se separan. El responsable del área tampoco debe tener un derecho ilimitado a modificar el log de forma retroactiva. El acceso de emergencia necesita una tarea acotada, un motivo, un plazo y una revisión posterior independiente. De lo contrario, el botón de emergencia se vuelve rápidamente la forma habitual de trabajar sin control.

Tercer episodio: dos personas también pueden ponerse de acuerdo

Si un trader confirma una y otra vez operaciones dudosas de una contraparte conocida, y un mismo revisor siempre autoriza las excepciones, hay motivo para una verificación independiente por muestreo. Pero una concentración similar puede deberse al calendario de turnos, a la especialización por idioma o a una cartera asignada. El análisis compara el trabajo real con las asignaciones y con la muestra disponible.

Conviene construir las señales defensivas a partir de combinaciones: correcciones manuales inusualmente frecuentes, vínculos repetidos operador–revisor–beneficiario, reembolsos tras un cambio de datos bancarios, ausencia de evidencia primaria y diferencias notorias en los resultados después de la conciliación. No hace falta publicar los umbrales para que alguien los esquive. Al equipo le basta saber qué acciones requieren explicación y que el log no puede editarse sin dejar rastro.

La rotación periódica de revisores y el muestreo posterior a las operaciones reducen la dependencia de una sola pareja de empleados. Un equipo pequeño no necesita crear un enorme departamento de seguridad. A veces, una revisión diaria independiente de los cambios más riesgosos por parte de un controller financiero es más útil que otra aprobación formal de la misma persona.

La triangulación rompe la imagen habitual del cliente

Ante una sospecha de triangulación, el dinero, la solicitud y el supuesto comprador pueden corresponder a personas distintas. Para protegerse importa detectar la ruptura entre identidades y destinos, no intentar adivinar el esquema completo a partir de los chats. Que coincidan el monto y el ingreso no vincula todavía al pagador con la persona a la que se va a entregar un activo o acreditar saldo de juego.

Las señales se analizan junto con las reglas del canal concreto: nombre del pagador, usuario verificado, beneficiario del pago, destino confirmado e historial de cambios. No se piden más datos de los necesarios ni se juntan documentos de terceros en un chat común. Si el vínculo no tiene explicación, la ejecución de la operación correspondiente se suspende dentro de las facultades propias y se deriva a la parte autorizada.

El reembolso también puede formar parte del riesgo. Un pedido de devolver un ingreso erróneo a una cuenta nueva no debe ejecutarse solo porque el interlocutor conoce el monto. Se verifican el solicitante, el movimiento original, las facultades de disposición y el canal de devolución admisible. Si hay una restricción bancaria o una disputa, se actúa a través del banco y del procedimiento establecido, sin crear una nueva cadena de transferencias.

Investigar sin cazar empleados

Primero se preservan los registros y se limitan las facultades riesgosas concretas. Después, un revisor independiente reconstruye los hechos: quién vio los datos, qué cambió, qué evidencia estaba disponible y qué acción se ejecutó realmente. No se debe dar a la persona cuyas acciones se revisan el control exclusivo de la exportación de evidencia. Al mismo tiempo, el acceso a los materiales de la investigación también se restringe para los demás.

La decisión de gestión se separa de la calificación jurídica. Se puede retirar temporalmente el permiso de confirmación manual sin declarar delincuente al empleado. Un defecto de interfaz detectado se corrige aunque no se haya probado la intención. El daño financiero se calcula sobre movimientos y obligaciones confirmados, evitando contar dos veces un mismo evento como reembolso y como pago repetido.

Después de la revisión se cambia un control concreto: vincular la aprobación a la versión, una fuente de confirmación independiente, los permisos de edición o la verificación de reutilización de movimientos. Un cambio masivo de contraseñas no elimina la posibilidad lógica de aprobar un pago y enviar otro. Una buena protección hace más clara la operación legal y deja menos lugares donde alguien pueda reemplazar un hecho por una historia conveniente sin que se note.