Novadrastia Import
Info@novadrastia.net

Instrumentos SWIFT – Arquitectura Técnica y Detección de Fraude



Arquitectura técnica de SWIFT

Componentes esenciales

  • SWIFTNet FIN: Mensajería MT basada en bloques.
  • SWIFTNet InterAct: Mensajería MX (ISO 20022) en XML.
  • RMA (Relationship Management Application): Controla quién puede enviar qué mensajes a quién.
  • BIC (Bank Identifier Code): Identificador único de entidad.
  • MAC (Message Authentication Code): Integridad y autenticidad.

Estructura técnica de un mensaje MT

  • Bloque 1: Encabezado básico (BIC emisor, sesión, secuencia).
  • Bloque 2: Encabezado de aplicación (tipo de mensaje, prioridad, BIC receptor).
  • Bloque 3: Campos de usuario y control.
  • Bloque 4: Contenido operativo (datos financieros).
  • Bloque 5: MAC, checksum, trazabilidad.

Mensajes SWIFT relevantes

Pagos

MT103 – Pago cliente a cliente

  • Debe contener campos obligatorios: 20, 23B, 32A, 50, 59, 71A.
  • Es el mensaje más falsificado en fraudes internacionales.
  • No transfiere fondos por sí mismo: es una instrucción.
Interbancario

MT202 / MT202COV

  • MT202COV debe acompañar a un MT103 en pagos transfronterizos.
  • Ausencia de COV es un indicador de fraude o manipulación.
Garantías

MT760 – Garantía / Standby LC

  • Debe incluir condiciones claras de obligación.
  • Frecuente en estafas de “instrumentos financieros exóticos”.
Libre

MT799 – Mensaje preformateado

  • No mueve dinero ni constituye compromiso financiero.
  • Uso legítimo: confirmaciones, aclaraciones, documentación.
  • Uso fraudulento: falsas “reservas de fondos”, “bloqueos”, “POF”.
Libre / Documentario

MT799BPU – Bank Payment Undertaking (Aviso / Comunicación)

  • No es un instrumento financiero ni un compromiso autónomo.
  • Se utiliza en contextos de Bank Payment Undertaking dentro de operaciones documentarias.
  • Su función es comunicar información relacionada con un BPU, no emitirlo ni garantizarlo.
  • No bloquea fondos, no constituye prueba de disponibilidad y no genera obligación de pago por sí mismo.
  • Debe estar respaldado por documentación operativa real (cartas de crédito, acuerdos BPU, instrucciones del banco emisor).

Riesgos y malentendidos frecuentes

  • Se presenta falsamente como “garantía de pago” cuando no lo es.
  • Se usa en estafas para simular compromisos bancarios inexistentes.
  • Puede aparecer acompañado de MT799 falsos para reforzar la apariencia de legitimidad.
  • En muchos casos, el banco no emite BPU reales, pero el estafador genera documentos PDF simulando un MT799BPU.

Cómo verificar un MT799BPU

  • Debe existir un acuerdo BPU formal entre bancos participantes.
  • Debe haber trazabilidad documental previa (LC, instrucciones, avisos oficiales).
  • El mensaje real debe existir en SWIFTNet; cualquier PDF aislado es sospechoso.
  • Debe haber coherencia con mensajes relacionados (MT700, MT707, MT799, MT999).
Clave forense: El MT799BPU no crea obligación de pago. Si aparece como “garantía”, “bloqueo de fondos” o “compromiso irrevocable”, es casi seguro un fraude.

Validaciones técnicas obligatorias

Validaciones de formato

  • Longitud exacta de campos (ej. 32A = fecha + divisa + importe).
  • Codificación SWIFT: caracteres permitidos.
  • Secuencia de bloques coherente.

Validaciones de integridad

  • MAC válido en Bloque 5.
  • Checksum coincidente.
  • Correspondencia entre BIC emisor real y BIC declarado.

Validaciones operativas

  • Coherencia entre MT103 y MT202COV.
  • RMA activo entre las entidades involucradas.
  • Fechas y horas compatibles con zonas horarias de los BIC.

Indicadores de fraude en mensajes SWIFT

Señales típicas

  • MT103 sin MT202COV asociado.
  • MT799 presentado como “prueba de fondos”.
  • BIC inexistente o no registrado en SWIFTNet.
  • Bloques 1 y 2 con rutas imposibles o inconsistentes.
  • Fechas incompatibles con la secuencia FIN.
  • Errores de formato que un banco real no emitiría.

Fraudes más frecuentes

  • Falsos MT103: documentos PDF sin respaldo en SWIFTNet.
  • Falsos MT760: garantías inexistentes para operaciones comerciales.
  • Falsos MT799: supuestos “bloqueos de fondos” sin validez.
  • Manipulación de campos: importes, divisas, BICs o referencias alteradas.
Regla de oro: ningún mensaje SWIFT es válido si no existe en SWIFTNet. Todo documento PDF, captura o impresión puede ser falsificado.

Metodología de análisis forense

Pasos de verificación

  • Confirmar existencia del mensaje en SWIFTNet (consulta oficial).
  • Verificar BIC emisor y receptor en registros SWIFT.
  • Analizar coherencia de bloques 1, 2 y 5.
  • Revisar timestamps y secuencias FIN.
  • Comparar con mensajes relacionados (MT202COV, MT199, MT999).
  • Detectar patrones de edición o manipulación documental.

Indicadores técnicos de falsificación

  • Fuentes, espaciados o alineaciones no estándar.
  • Campos obligatorios ausentes o mal ordenados.
  • Errores en la estructura de bloques.
  • Inconsistencias entre datos operativos y metadatos.

SWIFT de Aviso (Advices) y Errores Habituales

¿Qué es un SWIFT de aviso?

Un “SWIFT de aviso” no es un mensaje SWIFT transmitido por la red SWIFTNet. Es un documento interno generado por el oficial de operaciones después de haber enviado el mensaje real. Su función es informar al cliente o a un área interna de que un MT103, MT202, MT760, etc., ha sido emitido.

No tiene validez operativa, no viaja por SWIFT y no contiene metadatos técnicos (MAC, sesión, secuencia, timestamps FIN). Por ello, no puede usarse como prueba de envío.

Por qué pueden contener errores

  • El oficial lo redacta manualmente después del envío.
  • No se genera automáticamente desde SWIFTNet.
  • Puede contener campos abreviados, omitidos o mal transcritos.
  • Puede incluir importes o referencias que no coinciden exactamente con el MT real.
  • Puede usar plantillas antiguas o no estandarizadas.

Estos errores no afectan al mensaje real enviado por SWIFT, pero sí pueden generar confusión en auditorías, litigios o revisiones internas.

Errores típicos detectados en pericias

  • Referencia 20 incorrecta respecto al MT real.
  • Importe o divisa mal copiados del campo 32A.
  • Beneficiario abreviado o con errores tipográficos.
  • Fecha distinta a la del mensaje SWIFT auténtico.
  • Ausencia de BIC o BIC incorrecto por error humano.
  • Formato no estándar (tablas, logos, estilos internos).

Cómo distinguir un aviso de un SWIFT real

  • El aviso no contiene bloques 1, 2 ni 5.
  • No incluye MAC ni checksum.
  • No muestra sesión FIN ni secuencia.
  • No tiene estructura de bloques SWIFT.
  • Puede incluir logos, membretes o formatos internos del banco.
Punto clave: Un aviso puede tener errores sin que exista fraude. Lo relevante es siempre el mensaje SWIFT real en SWIFTNet, no el documento de aviso.

Página técnica orientada a análisis profesional de mensajería SWIFT. No constituye asesoramiento financiero ni contractual.