Qué debe hacer un banco cuando el cliente le presenta un SWIFT de localización

Esta página describe, de forma operativa, qué debe hacer un banco cuando un cliente acude con un supuesto mensaje SWIFT (por ejemplo, un “SWIFT de localización” o copia de un MT) y qué normativas condicionan la actuación de la entidad.

El objetivo es separar lo que el banco puede hacer (verificar, localizar, contrastar) de lo que no debe hacer (aceptar documentos impresos como prueba suficiente, asumir obligaciones sin confirmación interbancaria, etc.).

1. Pasos que debe seguir el banco

1.1. No confiar en el papel: verificar en sus propios sistemas

Un documento impreso o un PDF que el cliente llama “SWIFT” no es, por sí mismo, prueba suficiente de que el mensaje exista en la red SWIFT ni de que haya sido recibido por el banco.

El banco debe:

• Tomar nota del supuesto número de referencia, fecha, tipo de mensaje (MT103, MT799, MT760, etc.).
• Verificar en sus propios sistemas internos si existe un mensaje SWIFT con esos datos.
• Comprobar si el banco emisor figura como contraparte autorizada (RMA activa).

1.2. Verificar autenticidad y trazabilidad

El banco debe comprobar:

• Que el mensaje ha sido recibido a través de la red SWIFT, no por correo o canales no autenticados.
• Que el BIC emisor es válido y está operativo.
• Que el contenido del mensaje coincide con lo que el cliente afirma (importe, beneficiario, condiciones).

1.3. Confirmar con el banco emisor (bank-to-bank)

Si hay dudas sobre el contenido o la validez del mensaje, el banco receptor debe:

• Contactar con el banco emisor por canal SWIFT (por ejemplo, MT199/MT999) o por canal seguro acordado.
• Solicitar confirmación de que el mensaje fue efectivamente enviado y que su contenido es correcto.
• No basarse en llamadas telefónicas informales ni correos no autenticados.

1.4. Aplicar controles de cumplimiento (KYC/AML)

Si el mensaje implica fondos, garantías o compromisos (MT103, MT760, etc.), el banco debe:

• Verificar la identidad del cliente y su perfil de riesgo.
• Analizar la coherencia económica de la operación.
• Aplicar filtros de sanciones y listas negras.

1.5. Informar al cliente con precisión

Una vez realizadas las verificaciones, el banco debe informar al cliente:

• Si el mensaje existe o no en sus sistemas.
• Si el mensaje es operativo (por ejemplo, si un MT760 está efectivamente disponible y utilizable).
• Si faltan pasos interbancarios (por ejemplo, pre-advice, confirmaciones, etc.).

2. Normativas que condicionan la actuación del banco

2.1. Estándares SWIFT

La verificación de un mensaje SWIFT se rige por:

• SWIFT FIN / ISO 15022 para mensajes MT.
• ISO 20022 para mensajes MX.
• RMA (Relationship Management Application) para autorización entre bancos.

2.2. Normativa de prevención de blanqueo (AML/KYC)

El banco debe cumplir con:

• Recomendaciones FATF/GAFI.
• Directivas AML de la Unión Europea (si aplica).
• Normativa nacional de prevención de blanqueo y financiación del terrorismo.
• Listas de sanciones (ONU, UE, OFAC, etc.).

Esto implica que, aunque el cliente presente un “SWIFT de localización”, el banco no puede omitir sus propios controles internos.

2.3. Normas ICC para instrumentos (si aplica)

Si el mensaje se refiere a instrumentos como SBLC, garantías o créditos documentarios, pueden aplicar:

• UCP 600 (créditos documentarios).
• ISP98 (standby letters of credit).
• URDG 758 (garantías a primer requerimiento).

Estas normas no regulan la red SWIFT, pero sí el contenido y la interpretación del instrumento que el mensaje transmite.

3. Alertas y riesgos de fraude

3.1. Documentos SWIFT impresos o manipulados

Es frecuente que se presenten documentos que aparentan ser SWIFT pero:

• No corresponden a mensajes realmente enviados por la red SWIFT.
• Han sido modificados (importe, fechas, BIC, campos clave).
• Son plantillas genéricas sin trazabilidad real.

El banco debe considerar cualquier documento aportado por el cliente como no probatorio hasta verificarlo en sus propios sistemas.

3.2. “SWIFT de localización” sin reflejo contable

Si el cliente presenta un supuesto SWIFT que indica fondos o instrumentos a su favor, pero:

• No hay registro en los sistemas del banco.
• No existe apunte contable, ni pre-advice, ni mensaje asociado.

El banco debe tratarlo como no recibido y, en su caso, sugerir al cliente que contacte con el banco emisor para que reenvíe el mensaje por los canales correctos.

3.3. Presión para “aceptar” documentos no verificados

El banco no debe:

• Emitir certificados basados únicamente en documentos impresos.
• Reconocer como válidos mensajes no localizados en SWIFT.
• Asumir obligaciones sobre instrumentos que no constan en sus sistemas.

Normativas ICC aplicables (UCP 600, ISP98, URDG 758)

Cuando un cliente presenta un supuesto mensaje SWIFT relacionado con créditos documentarios, standby letters of credit o garantías, el banco debe actuar conforme a las reglas ICC aplicables. A continuación se indican los artículos relevantes y su función operativa.

1. UCP 600 (Créditos Documentarios)

• Artículo 2 – Definiciones: Define “crédito”, “banco emisor”, “banco avisador”, “presentación”, etc.
• Artículo 4 – Independencia del crédito: El crédito es independiente del contrato subyacente.
• Artículo 5 – Documentos vs. mercancías: El banco examina documentos, no bienes ni servicios.
• Artículo 7 – Compromiso del banco emisor: El banco emisor asume obligación irrevocable al emitir.
• Artículo 9 – Aviso del crédito: El banco avisador debe verificar autenticidad del mensaje.
• Artículo 14 – Estándar de examen: El banco tiene hasta 5 días hábiles para examinar documentos.
• Artículo 35 – Transmisión de mensajes: El banco no es responsable por errores en transmisión si usa canales habituales.

2. ISP98 (Standby Letters of Credit)

• Regla 1.06 – Independencia: La SBLC es independiente del contrato subyacente.
• Regla 2.01 – Emisión y eficacia: La SBLC es efectiva cuando el banco la emite por un canal autorizado (SWIFT).
• Regla 2.04 – Autenticidad: El banco receptor debe verificar autenticidad del mensaje.
• Regla 3.14 – Documentos presentados: El banco examina documentos, no hechos ni relaciones comerciales.
• Regla 5.01 – Notificaciones: El banco debe notificar discrepancias o aceptación dentro del plazo.

3. URDG 758 (Garantías a Primer Requerimiento)

• Artículo 2 – Definiciones: Define “garantía”, “ordenante”, “beneficiario”, “banco garante”.
• Artículo 5 – Independencia: La garantía es independiente del contrato subyacente.
• Artículo 7 – Emisión y forma: La garantía debe emitirse por un canal seguro y verificable.
• Artículo 15 – Examen de la demanda: El banco debe examinar la demanda de pago con criterios documentales.
• Artículo 24 – Transmisión de mensajes: El banco no es responsable de errores en transmisión si usa canales habituales.

4. Relación con mensajes SWIFT

Estas normas no regulan la red SWIFT, pero sí regulan la obligación bancaria que un mensaje SWIFT transmite. Por tanto:

• Un MT760 debe ser examinado conforme a ISP98 o URDG 758, según el tipo de instrumento.
• Un MT700/701 se rige por UCP 600.
• Un MT799 no crea obligación, pero debe ser auténtico y verificable.
• El banco receptor debe verificar autenticidad (RMA, BIC, canal SWIFT) antes de aplicar la norma ICC correspondiente.

4. Resumen operativo