SWIFT

Transferencias SWIFT y comunicación mediante mensajes MT y MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) es una red de mensajería segura que permite a las entidades financieras, como los bancos, enviar y recibir mensajes estandarizados sobre operaciones financieras, tales como instrucciones de pago y confirmaciones. SWIFT no mantiene cuentas ni transfiere fondos; se limita a proporcionar una plataforma segura y fiable para el intercambio de información.

Las transferencias SWIFT ordinarias utilizan una serie de tipos de mensaje normalizados, conocidos como mensajes MT (Message Type). Estos mensajes tienen formatos y campos predefinidos, lo que permite que las entidades financieras comprendan y procesen con facilidad la información que contienen.

Los mensajes MX (ISO 20022) son una norma más reciente de mensajería financiera basada en XML (eXtensible Markup Language). Ofrecen un formato más rico y estructurado, que permite un intercambio de datos mejorado y un procesamiento automatizado de extremo a extremo más eficiente. Los mensajes MX están sustituyendo progresivamente a los mensajes MT en la red SWIFT, con el objetivo de ofrecer mayor interoperabilidad y mejores capacidades de tratamiento de datos.

Si bien las transferencias SWIFT tradicionales han sido durante décadas el pilar de los pagos internacionales, presentan algunas limitaciones, entre ellas una transparencia limitada, tiempos de procesamiento más lentos y datos no estructurados.

Swift 103+ STP (procesamiento directo, Straight Through Processing)

Swift 103+ STP era el formato MT heredado, optimizado para el procesamiento automatizado de extremo a extremo (Straight Through Processing, STP); desde el fin del periodo de coexistencia, su función corresponde a la guía de uso STP de pacs.008. El STP permite que todo el proceso de pago, desde la iniciación hasta la liquidación definitiva, se realice por vía electrónica sin necesidad de intervención manual.

Características adicionales:

1. Formato normalizado: exige el cumplimiento estricto de un formato normalizado, lo que reduce los errores y los retrasos.
2. Procesamiento automatizado: las transacciones se procesan de forma automática, lo que garantiza una tramitación más rápida y eficiente.
3. Menor intervención manual: se reduce al mínimo la necesidad de introducción y verificación manuales, lo que disminuye el riesgo de errores y retrasos.
4. Liquidación más rápida: las operaciones se liquidan con mayor rapidez que con los métodos tradicionales.

Consideraciones sobre el procesamiento directo (STP):

1. Introducción precisa de datos: Los datos deben introducirse con exactitud para evitar retrasos o rechazos.
2. Cumplimiento de los requisitos de formato: los bancos deben asegurarse de que se respeten estrictamente los requisitos de formato de 103+ STP.
3. Software y sistemas: Los bancos deben contar con el software y los sistemas adecuados para gestionar eficazmente el procesamiento directo (STP)

Es fundamental distinguir entre mensajería y liquidación. SWIFT transmite mensajes financieros estructurados entre entidades, pero no mueve fondos ni mantiene saldos por sí misma. Una confirmación SWIFT, incluido un mensaje pacs.008, solo es válida cuando se corresponde con una operación real procesada y conciliada en los sistemas bancarios de las entidades participantes.

Ningún documento SWIFT independiente, captura de pantalla o mensaje presentado sin verificación institucional debe considerarse prueba de una liquidación completada.

Transferencias SWIFT gpi.

SWIFT gpi (Global Payments Innovation):

Lanzada en 2017, SWIFT gpi es una iniciativa concebida para superar las limitaciones de las transferencias SWIFT tradicionales mediante la mejora de la rapidez, la transparencia y la trazabilidad de los pagos transfronterizos. SWIFT gpi se apoya en los formatos de mensaje MT y MX existentes para mejorar los servicios de pago. Entre sus características principales figuran las siguientes:

• Pagos más rápidos: gpi simplifica los procesos y establece acuerdos de nivel de servicio (SLA) más estrictos entre bancos, lo que se traduce en tiempos de transacción más breves, con frecuencia de minutos o segundos.
• Seguimiento de pagos: El gpi Tracker permite el seguimiento en tiempo real de las transacciones, mejorando la transparencia y reduciendo las investigaciones manuales.
• Transparencia de las comisiones: los bancos pueden facilitar a los clientes información previa sobre las comisiones por transacción, lo que permite una mejor toma de decisiones.
• Datos más completos: gpi admite un intercambio de información más detallado y estructurado, lo que facilita una mejor conciliación y el cumplimiento normativo.

SWIFT gpi supera las limitaciones de las transferencias SWIFT tradicionales al mejorar los pagos transfronterizos mediante el seguimiento de extremo a extremo, un procesamiento más rápido y datos más completos.

Parámetros clave para participantes que no pertenecen a SWIFT gpi

Cuando un participante que no pertenece a SWIFT gpi (por ejemplo, un banco o una entidad financiera no adherida directamente a gpi) envía una instrucción de pago a un banco participante en gpi, este puede convertirla a los formatos de mensaje SWIFT requeridos (pacs.008 para transferencias de crédito de clientes, pacs.009 COV para transferencias de cobertura y pacs.009 para transferencias de crédito entre entidades financieras). Esta conversión permite su tramitación y seguimiento dentro de la red gpi, siempre que la instrucción incluya datos suficientes para cumplimentar los campos obligatorios y cumpla las normas de gpi, como la trazabilidad de extremo a extremo.

Los participantes que no son de gpi suelen facilitar estos parámetros a través de esquemas de pago nacionales, API o formatos heredados, y el banco gpi se encarga de las adiciones específicas de gpi (por ejemplo, generar un UETR si no se ha facilitado, aunque su transmisión es opcional para las entidades que no son de gpi). Los requisitos exactos pueden variar según la jurisdicción, la divisa y los acuerdos bilaterales, pero los parámetros esenciales proceden de las directrices CBPR+ (Cross-Border Payments and Reporting Plus) y de las normas ISO 20022. Desde el fin de la coexistencia el 22 de noviembre de 2025, las instrucciones de pago transfronterizo se intercambian en formato ISO 20022; las referencias a campos MT heredados que figuran a continuación se ofrecen únicamente a título orientativo.
1. Identificación de las partes (datos del ordenante y del beneficiario)
Estos datos identifican al ordenante y al beneficiario, y garantizan el cumplimiento de la Recomendación 16 del FATF en materia de requisitos de la «regla de viaje».

• Deudor/Ordenante: nombre completo, dirección estructurada (calle, ciudad, código postal, país) e identificación de la cuenta (por ejemplo, IBAN o número de cuenta). En los antiguos MT 103/MT 202 COV, corresponde al campo 50a; en pacs.008/pacs.009, a <Dbtr> y <DbtrAcct>.
• Acreedor/Cliente beneficiario: nombre completo, dirección estructurada e identificación de la cuenta. Corresponde al campo 59a del antiguo MT 103/MT 202 COV; <Cdtr> y <CdtrAcct> en pacs.008/pacs.009.
• Deudor/Acreedor final (si procede): Si son distintos de las partes principales, incluya sus datos para mayor transparencia (opcional, pero recomendado para el seguimiento gpi). Corresponde a <UltmtDbtr>/<UltmtCdtr> en pacs.008/pacs.009.

Motivo de la exigencia: Permite un encaminamiento preciso y los controles regulatorios; los datos incompletos pueden dar lugar a rechazos o retrasos.

2. Información sobre agentes y enrutamiento
Especifica las entidades financieras que intervienen en la cadena.

• Agente del ordenante: BIC (Bank Identifier Code) u otro identificador del banco emisor. Corresponde al campo 52a del antiguo MT 103; <DbtrAgt> en pacs.008/pacs.009.
• Banco del acreedor: BIC del banco receptor. Corresponde al campo 57a de los antiguos MT 103/MT 202 COV; <CdtrAgt> en pacs.008/pacs.009.
• Agentes intermediarios (si se conocen): BIC de los corresponsales (hasta 3 niveles). Corresponde al campo 56a del antiguo MT; <IntrmyAgt1-3> en pacs.008/pacs.009.
• Agentes instructores/instruidos: BIC del remitente o receptor inmediato en la cadena. Opcional, pero facilita los métodos en serie o de cobertura.
• Agentes instructores previos (si procede): En cadenas de varios intermediarios, hasta 3 agentes previos.

Motivo de la exigencia: Garantiza el correcto encaminamiento a través de los intermediarios; en pacs.009 COV debe utilizarse el BICFI en lugar de los nombres, para mayor precisión.

3. Detalles de la operación
Elementos financieros esenciales para la liquidación.

• Importe y divisa: importe de liquidación interbancaria y código de divisa ISO 4217 (p. ej., USD, EUR). Equivale al campo 32A de los antiguos MT 103/MT 202 COV; <IntrBkSttlmAmt> en pacs.008/pacs.009.
• Importe ordenado (si es distinto): Importe original antes de deducciones.
• Fecha de liquidación interbancaria: Fecha valor de la liquidación. Corresponde a parte del campo 32A en MT; <IntrBkSttlmDt> en pacs.008/pacs.009.
• Método de liquidación: indicar si es mediante RTGS (CLRG), cobertura (COVE) o agente (INDA/INGA). No existe un equivalente MT directo, pero se sobrentiende.

Por qué es obligatorio: Define la transferencia de valor; es obligatorio en todos los formatos.

4. Referencias e identificadores de seguimiento
Para garantizar la trazabilidad, especialmente en gpi.

• Identificación de extremo a extremo: referencia que vincula toda la cadena (por ejemplo, factura o identificador de operación). <EndToEndId> en pacs.008/pacs.009.
• Instruction Identification: referencia del remitente (limitada a 16 caracteres en MT). Corresponde al campo 20 del antiguo MT; <InstrId> en pacs.008/pacs.009.
• Referencia única de transacción de extremo a extremo (UETR): un UUID para el seguimiento de extremo a extremo. Es obligatorio en pacs.008/pacs.009 y, en los anteriores MT 103/MT 202, en el campo 121; si un canal iniciador no lo facilita, el primer banco Swift de la cadena lo genera.
• Identificación de la transacción: Referencia interna adicional.

Motivo de la exigencia: Permite el seguimiento y la vinculación de gpi (por ejemplo, de pacs.008 con pacs.009 COV); el UETR es esencial para las confirmaciones universales.

5. Finalidad e información del servicio
Clasifica el tipo de pago.

• Códigos de finalidad y de categoría de finalidad: códigos ISO (p. ej., SALA para salarios) que indican la naturaleza de la operación. Obligatorios en determinados corredores; <Purp> y <CtgyPurp> en pacs.008.
• Código de nivel de servicio: Identifica el servicio gpi (p. ej., G001 para una transferencia de crédito de cliente gpi); los bancos que no operan con gpi no deben incluir códigos específicos de gpi salvo acuerdo en contrario. Corresponde al campo 23E en MT; <SvcLvl> en pacs.008/pacs.009.
• Local Instrument Code: Para esquemas específicos (por ejemplo, transferencias intragrupo).

Motivo de la exigencia: garantiza el cumplimiento normativo y la prioridad de tramitación; cada vez más obligatorio tras la migración a ISO.

6. Remesa e instrucciones adicionales

• Información de remesa: No estructurada (hasta 140 caracteres) o estructurada (p. ej., datos de factura). Corresponde al campo 70 del antiguo MT103; <RmtInf> en pacs.008/pacs.009.
• Instrucciones para agentes: Por ejemplo, /REC/ para el receptor, /ACC/ para la cuenta o instrucciones telefónicas (PHOB). Corresponde al campo 72 del antiguo MT; <InstrForNxtAgt>/<InstrForCdtrAgt> en pacs.008/pacs.009.
• Indicadores de hora de liquidación: Horas solicitadas (por ejemplo, CLSTm para la hora CLS).

Motivo de su exigencia: Aporta contexto e instrucciones de tramitación; resulta esencial para los métodos de cobertura en pacs.009 COV.

7. Datos regulatorios y de cumplimiento normativo

• Notificación regulatoria: Códigos o datos (p. ej., identificación fiscal, indicador de notificación como CRED/DEB). Corresponde al campo 77B en MT; <RgltryRptg> en pacs.008/pacs.009.
• Códigos de motivo de devolución (si procede en devoluciones): Por ejemplo, AC04 para cuenta cerrada, en pacs.004 vinculado a los mensajes originales.

Motivo de la exigencia: Cumple las obligaciones de AML/KYC y de comunicación de información; es obligatorio en los corredores regulados.

Como buena práctica, los participantes que no son gpi deben estructurar los datos de modo que se evite su truncamiento durante las conversiones de MT a MX y consultar al banco miembro de gpi para necesidades específicas. Si el pago implica métodos de cobertura, los datos subyacentes del cliente deben reproducirse de forma idéntica en todos los mensajes (por ejemplo, de pacs.008 a pacs.009 COV).

Mensajes de pago en SWIFT gpi

En el marco de SWIFT gpi (Global Payments Innovation), los mensajes de pago originales (p. ej., pacs.008 para transferencias de clientes o pacs.009 COV para transferencias de cobertura) se consideran inmutables una vez enviados. Los bancos receptores no pueden alterar ni modificar directamente su contenido, ya que los mensajes SWIFT están diseñados para preservar la integridad y la auditabilidad a lo largo de toda la cadena de pago. Cualquier cambio, corrección o cancelación se tramita mediante mensajes de seguimiento independientes, actualizaciones de estado a través del gpi Tracker o servicios específicos como gSRP (gpi Stop and Recall Payment). De este modo se garantiza la trazabilidad de extremo a extremo mediante la referencia única de transacción de extremo a extremo (UETR).

Sin embargo, los bancos receptores (que suelen actuar como agente del acreedor o como intermediario) pueden responder a las solicitudes de modificación del remitente o iniciar acciones que den lugar de hecho a modificaciones del resultado del pago (por ejemplo, devoluciones o retenciones). También pueden solicitar aclaraciones o modificaciones al remitente en determinadas condiciones. Estos procesos se rigen por los reglamentos de SWIFT, las directrices de prácticas de mercado (por ejemplo, las del Payments Market Practice Group – PMPG) y los requisitos regulatorios, y dan prioridad a la automatización, la transparencia y la prevención del fraude.

Condiciones para que los bancos receptores soliciten o faciliten modificaciones
Los bancos receptores pueden solicitar modificaciones (por ejemplo, correcciones de datos) o adoptar medidas que impliquen la necesidad de un cambio cuando el pago original no puede procesarse conforme a lo instruido. Normalmente se hace mediante mensajes de consulta (por ejemplo, MT 195/199) o respuestas a solicitudes iniciadas por el remitente. Las condiciones principales son las siguientes:

• Errores en los datos del pago: Si existen inexactitudes, como una cuenta del beneficiario incorrecta (p. ej., cuenta cerrada – código AC04), una divisa errónea (código CURR), un enrutamiento incorrecto del agente (código AGNT) o incidencias técnicas (código TECH), el banco receptor puede retener el pago y solicitar al ordenante que facilite la información corregida o envíe un nuevo pago. De este modo se evita el rechazo definitivo y se permite la resolución.
• Imposibilidad de aplicar el pago: conforme al código CUTA (Cancel Upon Unable to Apply), si el pago no puede abonarse por discrepancias (por ejemplo, divergencia entre nombre y cuenta o datos insuficientes), el banco receptor puede solicitar al ordenante los datos de cancelación o modificación para subsanar la incidencia.
• Sospecha de fraude u operaciones no autorizadas: en caso de fraude (código FRAD), el banco receptor puede detectar de forma independiente las irregularidades e iniciar la devolución de los fondos sin solicitud previa del ordenante. También puede responder a las solicitudes de devolución del ordenante inmovilizando los fondos y solicitando una indemnidad (código INDM) si ya han sido abonados, a fin de mitigar el riesgo antes de proceder a la devolución.
• Pagos duplicados o indebidos: códigos como DUPL (pago duplicado) o UPAY (pago indebido) permiten al banco receptor señalar la operación y solicitar su cancelación si es errónea o carece de justificación.
• Problemas regulatorios o de cumplimiento normativo: si el pago infringe la legislación local, las sanciones o los requisitos de AML (código LEGL), el banco receptor puede rechazarlo o retenerlo y solicitar al ordenante documentación adicional o modificaciones.
• Decisiones del cliente o del beneficiario: Si el beneficiario rechaza el pago (código CUST o NOAS, sin respuesta del beneficiario), el banco receptor puede devolverlo y notificarlo al ordenante, pudiendo solicitar la confirmación de las modificaciones.
• Resoluciones pendientes: En los casos pendientes (código PDCR), como la espera de autorización de adeudo (RQDA) o de respuesta del siguiente agente (PTNA), el banco receptor puede retener el pago y solicitar instrucciones adicionales o modificaciones para poder proseguir.

En todos los casos, las solicitudes deben estructurarse para su automatización (por ejemplo, incluyendo el UETR, las referencias originales como los campos 20/32A/50/59 y los códigos específicos en el campo 79 de los mensajes) a fin de permitir el procesamiento directo (straight-through processing). Pueden exigirse acuerdos de indemnización bilaterales si se abonan fondos; el banco receptor no tiene obligación de aceptar las solicitudes, pero debe dar prioridad a las urgentes (por ejemplo, las relacionadas con fraude).

Procesos implicados

• Respuesta a las solicitudes de devolución iniciadas por el banco emisor: El banco emisor (agente del deudor) suele iniciar una solicitud de devolución mediante MT 192/292 (o equivalentes ISO 20022 como camt.056) a través del servicio gSRP, enviada en serie o directamente al banco receptor. El banco receptor debe acusar recibo de inmediato y responder con MT 196/296 (o MT 199/299 si es estructurado), utilizando códigos como CNCL (cancelado), RJCR (rechazado con motivo) o PDCR (pendiente). Si se acepta, los fondos se devuelven mediante pacs.004 (Devolución de pago).
• Actuaciones independientes de los bancos receptores: Si se detecta un fraude internamente, el banco receptor puede devolver los fondos mediante pacs.004 con información estructurada, notificándolo a través del Tracker para la actualización del estado en tiempo real.
• Solicitudes de modificación o aclaración: los bancos receptores utilizan mensajes de consulta (p. ej., MT 195/295) para solicitar cambios, como información adicional. Esto es habitual en los pagos retenidos.
• Integración con Tracker: todas las acciones actualizan el gpi Tracker en tiempo real, al que se puede acceder mediante API o interfaz gráfica, lo que garantiza la visibilidad para todas las partes. Los miembros de gpi deben cumplir los reglamentos obligatorios aplicables a gCCT (Customer Credit Transfer), gCOV (Cover) y gSRP.
• Limitaciones y factores de éxito: Las modificaciones no están garantizadas; el éxito depende de la fase del pago (resulta más sencillo antes del abono), de la cooperación del beneficiario y de la jurisdicción. En caso de que ya se haya abonado, la devolución requiere el consentimiento del beneficiario o una garantía de indemnidad. La normativa prevalece siempre sobre las directrices.

Estas prácticas se aplican principalmente a los miembros de gpi, pero los bancos que no pertenecen a gpi pueden participar a través de pasarelas. Para conocer los detalles más actualizados, consulte los reglamentos oficiales de SWIFT, ya que los procesos evolucionan (por ejemplo, con la migración a ISO 20022).

Separación entre mensajería y liquidación en SWIFT gpi

SWIFT gpi gestiona principalmente instrucciones de pago y su seguimiento mediante mensajería (por ejemplo, formatos ISO 20022 como pacs.008 para transferencias de clientes, pacs.009 para transferencias financieras, o los MT 103/MT 202 heredados), pero el movimiento efectivo del dinero se produce por separado, en el plano de la liquidación. La liquidación se efectúa normalmente a través de relaciones de banca corresponsal (cuentas nostro/vostro), compensación bilateral o mecanismos de compensación y liquidación (CSM), como los sistemas de liquidación bruta en tiempo real (RTGS) (por ejemplo, T2, antes TARGET2, en Europa; Fedwire en EE. UU.; o CHAPS en el Reino Unido). El gpi Tracker ofrece visibilidad en tiempo real del estado de los mensajes, pero la transferencia de fondos depende de estos sistemas subyacentes.

El período de coexistencia para las instrucciones de pago transfronterizas finalizó el 22 de noviembre de 2025: las instrucciones de pago como MT103 y MT202 han sido sustituidas por mensajes ISO 20022 (MX) como pacs.008 y pacs.009, mientras que las demás categorías MT se irán retirando en fechas posteriores. A continuación se explica cómo se producen las devoluciones y las liberaciones de retenciones a nivel de cuenta, compensación y liquidación.

Cómo se devuelve el dinero en el ámbito de la cuenta, la compensación y la liquidación
Las devoluciones se inician tras una solicitud de recuperación satisfactoria (mediante gSRP, el servicio gpi Stop and Recall Payment) o tras una detección independiente (por ejemplo, fraude o errores). El gSRP utiliza el mensaje camt.056 (Solicitud de cancelación de pago) del ordenante, al que se responde con camt.029 (Resolución de investigación). Una vez aceptada, la devolución de los fondos se ejecuta mediante una nueva instrucción de pago que invierte el flujo, adeudando la cuenta del banco receptor y abonando de vuelta a lo largo de la cadena. No se trata de una modificación del mensaje original, sino de una operación independiente.

Principales métodos de liquidación y procesos de devolución
Los métodos de liquidación determinan cómo se producen las devoluciones:

• CLRG (Clearing via Market Infrastructure): Liquidación a través de un RTGS o de un CSM (por ejemplo, mediante un banco central). Las devoluciones utilizan pacs.004 para ordenar a la infraestructura de mercado que adeude la cuenta del agente receptor y abone la del agente anterior, con frecuencia en tiempo real o el mismo día.
• INGA (Instructing Agent Settles First): El remitente liquida los fondos antes de enviar el mensaje. Las devoluciones mediante pacs.004 adeudan la cuenta del agente instruido tras la liquidación.
• INDA (el agente instruido liquida a la recepción): el receptor liquida al recibir el mensaje. Si no se liquida, se rechaza mediante pacs.002 (no se mueven fondos); si se ha liquidado, se devuelve mediante pacs.004.
• COVE (método de cobertura): Se utiliza para pagos de elevado importe con una transferencia de cobertura (pacs.009 COV). Las devoluciones siguen la cadena inversa: pacs.004 desde el agente del beneficiario hacia los intermediarios, con los correspondientes adeudos y abonos en las cuentas de los corresponsales.

Proceso de devolución paso a paso en el ámbito de la liquidación

1. Inicio y aceptación: el remitente solicita la devolución (p. ej., mediante camt.056 con UETR). El receptor responde (camt.029) y la acepta si los fondos están disponibles o aún no se han abonado al beneficiario (más sencillo antes del abono). Si ya se han abonado, puede requerirse el consentimiento del beneficiario o una garantía de indemnidad.

2. Instrucción de devolución de fondos: El receptor emite un mensaje pacs.004 (devolución de pago) o un MT 103/MT 202 tradicional con códigos de devolución (p. ej., RETN). Este mensaje incluye:

• Referencias originales (UETR, End-to-End ID, Instruction ID).
• Inversión de roles: el acreedor original pasa a ser deudor; el agente del deudor original pasa a ser acreedor.
• Datos de liquidación: importe y fecha originales de liquidación interbancaria, tipo de cambio (si interviene una operación de divisas), gastos (si se han deducido).
• Código del motivo de devolución (p. ej., AC04 para cuenta cerrada, FRAD para fraude).
• Campo de cuenta de liquidación (si figura en el mensaje original) para especificar la cuenta que se abonará.

3. Ejecución de la liquidación:

• El mensaje pacs.004 desencadena el adeudo en la cuenta nostro/vostro de la entidad receptora (mantenida en el agente anterior o en la infraestructura del mercado financiero).
• Los fondos se reabonan salto a salto a lo largo de la cadena, utilizando el mismo método de liquidación (por ejemplo, transferencia RTGS en CLRG).
• En caso de devolución parcial, indique «PART» en Información adicional junto con el importe prorrateado.
• El Tracker actualiza el estado (por ejemplo, «Devuelto») en tiempo real, visible a través de API o de la interfaz gráfica.

4. Abono definitivo: Se abona la cuenta del ordenante original, con frecuencia previa deducción de comisiones. Si la operación se cursa a través de un CSM, la liquidación es atómica; en esquemas bilaterales, puede implicar una compensación al cierre del día.

5. Notificaciones posteriores a la devolución: Utilice camt.053/054 (extracto de cuenta/notificación de adeudo-abono) para confirmar las actualizaciones contables. No se emite otro pacs.004 para «devolver una devolución»: utilice en su lugar las consultas.
Las devoluciones se automatizan siempre que es posible, pero puede ser necesaria una intervención manual por motivos de cumplimiento normativo o si los fondos están inmovilizados. La recuperación no está garantizada; depende sobre todo de la rapidez con que se envíe la solicitud de recuperación y de que los fondos ya se hayan abonado o no. Si la operación no se ha liquidado (por ejemplo, rechazada antes de la liquidación), no se mueven fondos: utilice en su lugar pacs.002.

Cómo se liberan los pagos retenidos (luz verde) en el ámbito de la cuenta, la compensación y la liquidación

Las retenciones se producen cuando un pago no puede procesarse de inmediato (por ejemplo, por errores, controles de cumplimiento normativo o a la espera de aclaraciones), quedando en estado «pendiente» sin liquidación. No se carga ni se abona ningún importe hasta su resolución. El gpi Tracker muestra estados como «On Hold» o «Pending» (por ejemplo, el código PDCR), y la resolución se efectúa mediante mensajes de consulta (MT 195/199 o camt.029).

Circunstancias que dan lugar a retenciones

• Discrepancias (por ejemplo, falta de coincidencia entre cuenta y nombre – código CUTA).
• Controles regulatorios (p. ej., sanciones – código LEGL).
• A la espera de la respuesta del beneficiario (código NOAS) o de la autorización de adeudo (RQDA).
• Horario de inactividad o procesamiento por lotes en el banco del beneficiario.

Proceso de liberación a nivel de liquidación
1. Notificación de retención: El receptor envía un pacs.002 (actualización de estado) o un MT 199 con código de pendiente, y retiene los fondos en una cuenta de suspenso o de depósito en garantía (escrow) si la liquidación es parcial (por ejemplo, en los métodos de cobertura).
2. Resolución: El emisor aporta las modificaciones o aclaraciones (por ejemplo, mediante una respuesta MT 195 o un camt.029). Una vez resuelto, el receptor da su conformidad y procesa la instrucción original.
3. Ejecución de la liquidación:

• El pacs.008/pacs.009 original se libera de su retención.
• Los fondos se liquidan mediante el método especificado: adeudo en la cuenta del ordenante, abono en la del receptor (p. ej., a través de RTGS en CLRG) y, por último, abono definitivo en la cuenta del beneficiario.
• El tramo del beneficiario (del banco receptor al cliente final) es con frecuencia donde se producen los retrasos, en particular en mercados con controles de capital o infraestructuras limitadas.
• El rastreador se actualiza a «Abonado» o «Completado», y el pacs.002 (Informe de estado del pago) lo confirma.

4. Si no se libera: Si la situación no se resuelve (por ejemplo, tras el vencimiento del plazo), devolución mediante pacs.004 como se indicó anteriormente, o rechazo con pacs.002 (sin liquidación).

Las normas de gpi exigen el abono en el mismo día siempre que sea posible; Swift informó en 2018 de que casi el 50 % de los pagos gpi se abonaron en 30 minutos y casi el 100 % en 24 horas. Factores como los controles de capital o los horarios de inactividad de los bancos pueden prolongar las retenciones, pero gpi hace hincapié en la automatización para reducirlas al mínimo.

SwiftNet Instant

SwiftNet Instant. Es una plataforma de mensajería en tiempo real, de baja latencia, disponible las 24 horas del día, los 7 días de la semana, que permite el intercambio seguro de flujos de pagos instantáneos entre los mecanismos de compensación y liquidación (CSM) y sus participantes.

Los clientes pueden conectarse a SwiftNet Instant a través de su infraestructura de conectividad y seguridad de Swift existente, que incluye cajas VPN, líneas dedicadas y módulos de seguridad de hardware. La integración con el entorno informático del banco se realiza mediante Alliance Gateway Instant (AGI).

Todas las partes de la cadena de pagos instantáneos pueden utilizar AGI y la mensajería SwiftNet Instant. Entre las aplicaciones se incluyen la iniciación de pagos desde un servicio superpuesto, las comunicaciones indirectas de un miembro con un miembro patrocinador o la recepción por parte de una empresa de una confirmación de pago.

SWIFT Instant se conecta con los sistemas nacionales de pagos instantáneos para permitir el procesamiento de transacciones en tiempo real, tanto a escala nacional como internacional, mediante el estándar ISO 20022. Estos sistemas representan los esfuerzos continuos por modernizar y simplificar los procesos de pago en el sector financiero.

Adeudo directo SWIFT

El adeudo directo en el sistema SWIFT es un método de pago que permite a empresas y particulares cobrar fondos de cuentas bancarias de deudores en múltiples divisas y en distintos países. A diferencia del adeudo directo SEPA, diseñado específicamente para la zona SEPA y limitado a operaciones denominadas en euros, el adeudo directo en SWIFT tiene alcance global y admite una amplia gama de divisas.

El proceso de iniciar una operación de adeudo directo dentro del sistema SWIFT comprende normalmente los siguientes pasos:

1. Acuerdo entre acreedor y deudor: el acreedor y el deudor deben contar con un acuerdo previo que recoja los términos y condiciones de las operaciones de adeudo directo. Este acuerdo puede incluir también el establecimiento de un mandato o autorización que permita al acreedor cobrar los pagos de la cuenta bancaria del deudor.
2. Intercambio de mensajes: El banco del acreedor inicia el adeudo directo enviando un mensaje SWIFT al banco del deudor: en ISO 20022, un pacs.003 (adeudo directo de cliente) o pacs.010 (adeudo directo entre entidades financieras), anteriormente MT 104 o MT 204. Este mensaje contiene los datos de la operación, como el importe, la divisa, la información de la cuenta del deudor y cualquier otra información necesaria.
3. Verificación y autorización: el banco del deudor verifica los datos de la operación, comprueba la disponibilidad de fondos en la cuenta del deudor y confirma la autorización de la operación. Si todo es conforme, el banco del deudor procede a adeudar los fondos en la cuenta del deudor.
4. Transferencia de fondos: los fondos se liquidan entre el banco del deudor y el banco del acreedor mediante cuentas de corresponsalía o un sistema de compensación y liquidación.
5. Confirmación: al recibir los fondos, el banco del acreedor envía una confirmación al acreedor para notificarle que el adeudo directo se ha realizado correctamente.

Los requisitos previos para iniciar una operación de adeudo directo en el sistema SWIFT son los siguientes:

1. Cuentas bancarias: tanto el acreedor como el deudor deben ser titulares de cuentas en entidades financieras integradas en la red SWIFT.
2. Acuerdo y autorización: debe existir previamente un acuerdo y una autorización (mandato) entre el acreedor y el deudor que permita efectuar operaciones de adeudo directo.
3. Formatos de mensaje SWIFT: El acreedor y su banco deben utilizar los formatos de mensaje adecuados: pain.008 para iniciar un adeudo directo, pacs.003 o pacs.010 entre bancos.
4. Comisiones bancarias: El acreedor y el deudor deben conocer las comisiones asociadas a las operaciones de adeudo directo dentro del sistema SWIFT, ya que dichas comisiones pueden variar según los bancos y los países implicados.

RMA en la mensajería interbancaria SWIFT

En la banca y las finanzas, es esencial que la comunicación entre bancos sea segura y eficiente. Es aquí donde SWIFT (Society for Worldwide Interbank Financial Telecommunication) desempeña un papel fundamental, al transmitir la mayor parte de los mensajes interbancarios internacionales. Un componente esencial para garantizar la seguridad y la selectividad de estas comunicaciones es la Relationship Management Application (RMA).

¿Qué es el RMA?

Relationship Management Application (RMA) es una aplicación de software de SWIFT que permite a las entidades financieras definir qué contrapartes pueden enviarles mensajes SWIFT y garantiza que la comunicación en la red SWIFT se limite a usuarios autenticados. RMA constituye una capa de seguridad fundamental en la gestión de la comunicación interbancaria, ya que filtra los mensajes no autorizados y reduce el riesgo de fraude.

La importancia de la RMA

Para los bancos que operan en el ámbito de las finanzas internacionales, como IFB, la herramienta RMA es indispensable. No solo refuerza los protocolos de seguridad, sino que también garantiza el cumplimiento de la normativa bancaria mundial. Al gestionar qué entidades pueden enviarles mensajes, los bancos pueden evitar solicitudes de información e instrucciones financieras no autorizadas, protegiendo tanto sus intereses como los de sus clientes.

Cómo funciona el RMA

El proceso de RMA comprende varias etapas fundamentales:

1. Establecimiento de relaciones RMA: antes de que dos bancos puedan intercambiar información a través de SWIFT, deben acordar mutuamente el establecimiento de una RMA. Este acuerdo equivale a un apretón de manos digital, que expresa confianza y consentimiento para comunicarse.
2. Intercambio de claves: cada banco envía una autorización RMA a través de la aplicación RMA, que la contraparte acepta. El RMA sustituyó al anterior intercambio bilateral de claves (BKE); los propios mensajes se autentican mediante la PKI (infraestructura de clave pública) de SWIFTNet.
3. Configuración de los ajustes de RMA: cada banco utiliza la herramienta RMA para configurar los permisos y especificar qué tipos de mensajes se aceptan de la otra entidad. Esto puede definirse de forma general o ajustarse con precisión para incluir tipos de mensaje y subclases específicos.
4. Activación y supervisión: Una vez configurados y activados los parámetros de RMA, los bancos pueden supervisar los mensajes entrantes para verificar su conformidad con los permisos establecidos. RMA ofrece asimismo herramientas para modificar o revocar los permisos cuando así lo exijan las necesidades del negocio o motivos de seguridad.

Aplicaciones prácticas

Para IFB, que se especializa en inversión y gestión patrimonial para personas de alto patrimonio y entidades corporativas, la RMA ofrece varias ventajas:

• Mayor seguridad: Al controlar el tráfico de mensajes, IFB puede proteger las operaciones y la información sensible de sus clientes frente a accesos no autorizados.
• Eficiencia operativa: la simplificación de las comunicaciones con entidades de confianza permite un procesamiento más rápido de los mensajes legítimos, lo que mejora los tiempos de respuesta y la satisfacción del cliente.
• Cumplimiento normativo: la RMA contribuye al cumplimiento de la normativa bancaria internacional, que exige un control estricto del intercambio de información para prevenir delitos financieros como el blanqueo de capitales y el fraude.

RMA y MT799. Los bancos pueden utilizar un MT799 para solicitar o coordinar una relación RMA, siempre que el canal lo permita. La propia autorización RMA se concede en el sistema RMA; un MT799 por sí solo no activa ningún permiso. Cuando falte la autorización RMA necesaria para el MT799, no podrá eludirse enviando directamente un MT799. En tal caso, la configuración se acuerda mediante la función de comunicación RMA del Relationship Management Portal de Swift, diseñada para la coordinación con las contrapartes antes de intercambiar las autorizaciones, o mediante otro canal permitido. Por tanto, «RMA por MT799» puede designar la correspondencia bancaria que acompaña al proceso; la autorización técnica RMA es un paso distinto.

En resumen

Para IFB, la implantación eficaz de RMA no es solo un requisito técnico, sino un activo estratégico en sus operaciones globales. Refuerza el compromiso del banco con la seguridad y el cumplimiento normativo, al tiempo que mejora la eficiencia de sus redes de comunicación. A medida que el entorno de las finanzas internacionales sigue evolucionando, herramientas como RMA continúan siendo esenciales en el arsenal de las entidades comprometidas con mantener los más altos estándares de integridad operativa y de servicio al cliente.

Los RMA constituyen la columna vertebral de una comunicación interbancaria segura y selectiva, y garantizan que cada mensaje intercambiado a través de la red SWIFT cumpla las más altas normas de seguridad y esté plenamente autenticado. Para entidades como IFB, comprender y gestionar los RMA es esencial para salvaguardar sus operaciones y generar confianza entre sus socios globales.

Instrucciones financieras mediante blockchain de Swift Digital

En septiembre de 2025, Swift anunció que, junto con más de 30 entidades financieras, había iniciado el diseño y desarrollo de un libro mayor digital compartido. El 9 de julio de 2026, Swift declaró que el libro mayor estaba listo para su uso inicial, con 17 bancos preparándose para realizar pilotos de operaciones en vivo con depósitos tokenizados: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB y Wells Fargo. La primera aplicación se centrará en habilitar instrucciones transfronterizas en tiempo real, las 24 horas del día, los 7 días de la semana, entre bancos, una mejora decisiva en el tejido del procesamiento de operaciones internacionales.

El primer prototipo conceptual se construyó con Consensys. El libro mayor está concebido como un registro seguro, inmutable y en tiempo real de las instrucciones financieras entre instituciones. Registrará, secuenciará y validará los mensajes de las transacciones, y hará cumplir las normas operativas y de cumplimiento normativo mediante contratos inteligentes. La interoperabilidad es un principio central: el libro mayor se conectará tanto con las infraestructuras existentes como con las emergentes, manteniendo la resiliencia, la confianza y el cumplimiento regulatorio que caracterizan a Swift.

Como explicó Javier Pérez-Tasso, consejero delegado de Swift:
«La combinación de un libro mayor compartido con la mensajería, las API y el ISO 20022 ya existentes de Swift crea una estructura aún más potente, capaz de integrar desde el origen los requisitos de riesgo, control y cumplimiento normativo en los flujos de las operaciones, y de permitir instrucciones interbancarias transfronterizas en tiempo real, las 24 horas del día, los 7 días de la semana, con la misma confianza, seguridad, resiliencia, escalabilidad y excelencia operativa que caracterizan a Swift. Todo ello en línea con el enfoque de innovación responsable que siempre hemos adoptado».

Ampliación de la infraestructura

El libro mayor compartido complementa la infraestructura existente de Swift; no la sustituye. Está concebido para ampliar la orquestación y la interoperabilidad, de modo que las entidades financieras puedan intercambiar instrucciones con mayor rapidez, con mayor previsibilidad y a una escala verdaderamente global.

En Sibos, Pérez-Tasso subrayó este enfoque de doble vía:
«Las infraestructuras financieras deben mantener una atención permanente a los fundamentos de la excelencia operativa, el cumplimiento normativo y el gobierno corporativo. Y, al mismo tiempo, deben prepararse para el futuro. En Swift, nuestro enfoque consiste en innovar a lo largo de dos vías paralelas».

Colaboración en todo el sector

Desde el inicio participaron instituciones financieras de 16 países en la definición del diseño, la gobernanza y la trayectoria de desarrollo del libro mayor compartido. Este esfuerzo colectivo refleja un reconocimiento común: avanzar en la infraestructura global de instrucciones interbancarias exige escala y colaboración.

Perspectivas futuras

El libro mayor compartido es una evolución natural de los anteriores ensayos de Swift con activos digitales y forma parte de un compromiso más amplio con la interoperabilidad entre redes públicas y privadas. Ello permitirá que el valor tokenizado regulado y los instrumentos tradicionales circulen sin fricciones entre sistemas.

Pérez-Tasso resumió la visión:
«Esta es una plataforma potente para el futuro. Y en el futuro puede ser aún más transformadora».

Preguntas frecuentes

¿Qué es el libro mayor compartido de Swift basado en blockchain?
Una infraestructura blockchain que proporciona un registro compartido y en tiempo real de las instrucciones financieras entre instituciones, y que permite un procesamiento transfronterizo continuo y conforme a la normativa.

¿A quién va dirigido?
A bancos e instituciones financieras que deben ofrecer instrucciones de transacción más rápidas y transparentes, al tiempo que se preparan para el futuro digital.

¿Cuáles son los beneficios?

• Visibilidad en tiempo real y secuenciación de las instrucciones
• Cumplimiento normativo automatizado mediante contratos inteligentes
• Interoperabilidad entre redes tradicionales y digitales
• Gestión segura de flujos de valor tokenizado regulados

¿Cómo encaja con la plataforma de Swift?
Amplía la infraestructura de confianza de Swift, incorporando capacidades de instrucción digital y manteniendo la resiliencia, la seguridad y el cumplimiento normativo.

¿Cuál es el primer caso de uso?
Instrucciones de transacciones interbancarias transfronterizas en tiempo real, las 24 horas del día, los 7 días de la semana.

¿Quiénes participan?
Más de 30 instituciones financieras de 16 países contribuyeron a definir el diseño; 17 bancos están poniendo a prueba las primeras operaciones en producción.

¿Cuándo estará disponible?
Swift declaró el libro mayor listo para su uso inicial el 9 de julio de 2026. Los bancos piloto realizan las primeras operaciones reales en una fase de puesta en marcha controlada; la liquidación final sigue efectuándose a través de los sistemas existentes. Posteriormente se ampliarán las funcionalidades y la disponibilidad.

Si desea obtener más información sobre cómo transferir fondos a través del sistema de banca corresponsal, póngase en contacto con nuestro Responsable de Banca Corresponsal, el Sr. Amri Elarisse.