Emisión de una contraparte y solicitud de emisión de una empresa local (ISCO)

El Banco DOKA-NG recibe las instrucciones de la empresa para emitir una contragarantía, solicitando la emisión de un compromiso local al beneficiario final. En este caso, tanto el propósito del mensaje entrante como el saliente será ISCO y los mensajes incluirán tanto la Secuencia B como la Secuencia C.

Cuando la emisión se recibe electrónicamente, las etiquetas se asignan a los campos respectivos como se define en la asignación entrante (en la transacción Mantenedor Mapeo de Mensajes Recibidos (DBISWH)). El pedido electrónico entrante podría recibirse a través de Score (MT784), DTA (G01) o Bolero (429).

Cuando el «Propósito entrante» del Mensaje de la empresa sea «ISCO», el «Propósito del mensaje» saliente será predeterminado como «ISCO» en la aplicación. El usuario puede seguir seleccionando otros códigos de «Objetivo del mensaje»: ISSU o ICCO proporcionan más flexibilidad al usuario. Este mensaje es enviado por nosotros, el Banco Emisor del Contador, al banco Emisor Local (ISS). El «Tipo de manipulación» viene predeterminado según el propósito del mensaje seleccionado.

• El mensaje entrante y saliente contendrá tanto la Secuencia B como la Secuencia C, donde la Secuencia C incluirá los detalles de la garantía local. La Secuencia B de la entrada se asignará a los paneles de la Secuencia B y la Secuencia C a los paneles de la Secuencia C.
• En este caso, la aplicación identifica el tipo de mensaje entrante (Score/DTA/Bolero) y marca la casilla de verificación «Pedido corporativo entrante».
• La función «Aplicante» de la secuencia B del mensaje entrante (Tag 50) se asigna a la función «CTR».
• La función «Garante» de la secuencia B del mensaje entrante (Tag 51) se asigna a la función «APL».
• Para un pedido corporativo entrante, la casilla de verificación «Suprimir parte en SWIFT MT 760 saliente» en el panel de partes de la secuencia B se establece por defecto cuando se llenan tanto el solicitante de las partes como el deudor. En tales casos, tag 51 (sec. B) del MT760 saliente no está impreso y etiqueta 50 (sec. B) se completará con el participante introducido en el campo de deudor de la secuencia B.
• La función «Aplicante» de la secuencia C del mensaje entrante (Tag 50) se asigna a la función «CTC».
• La función «Garante» de la secuencia C del mensaje entrante (Tag 51) se asigna a la función «APC».
• Para un pedido corporativo entrante, la casilla de verificación «Suprimir parte en SWIFT MT 760 saliente» en el panel de partes de la secuencia C se establece por defecto cuando se llenan tanto el solicitante de las partes como el deudor. En tales casos, tag 51 (sec. C) del MT760 saliente no está impreso y etiqueta 50 (sec. C) se completará con el participante introducido en el campo de deudor de la secuencia C.
• Si se establece la función CTR, la etiqueta 50 de la secuencia B (aplicante) en el MT760 saliente contendrá detalles de la función CTR; de lo contrario, contendrá detalles de la función APL.
  De manera similar, si se establece CTC, entonces Tag 50 de la secuencia C (Aplicante) en el MT760 saliente contendrá detalles de la función CTC, de lo contrario contendrá detalles de la función APC.
• El mapeo entrante de Tag 52a (Emisor) de la Secuencia B para mensajes corporativos se establece como no mapeado.
• Se introduce una nueva función BEC (beneficiario intermedio) para capturar los detalles del beneficiario (etiqueta 59) de la secuencia B cuando esta está presente. Aunque captura detalles sobre el Beneficiario de la Secuencia B, esta parte es visible en el panel «Sec.C: Partes» de la aplicación.
• El Beneficiario definitivo siempre se establecerá en el rol BEN en la aplicación, que en este caso será el Beneficiario de la secuencia C.
• Cuando se reciban instrucciones de confirmación de la empresa, la empresa podría haber sugerido un banco de confirmación (tag 58a). Esto se asigna a la función CNR (Banco Confirmador Entrante) y se almacena como información entrante. El usuario bancario tiene que decidir si seguir esta sugerencia o anular la empresa. A continuación, el usuario del banco debe añadir el participante en el campo Participante de confirmación (CON - Banco de confirmación) que, a continuación, se rellenaría en el MT760 saliente para la etiqueta 58a como Banco de confirmación solicitado.
• Para las L/C Standby, cuando se recibe «Disponible con» (Tag 41a) de Seq.B de la empresa, la parte se asigna al Rol AVB (Disponible con el Banco).
  Esta función está disponible en la cuadrícula «Partes adicionales».
• Para las L/C Standby, cuando se recibe «Disponible con» (Tag 41a) de Seq.C desde la empresa, la parte se asigna a la Función AVC (Disponible con el Banco C).
  Esta función está disponible en el panel «Seq.C: Participantes».

Los mapeos de roles de las partes siguen siendo los mismos, para una entrada manual por parte del usuario como antes SR2021, aparte de la función BEC adicional. El punto a tener en cuenta es el Beneficiario de la secuencia B (Función BEC - Beneficiario intermediario) debe rellenarse en el panel «Sec.C: Partes». Y el Beneficiario final (Role BEN -en este caso la Secuencia C del Beneficiario) debe rellenarse en el panel de Partes como antes. En este caso manual, la casilla de verificación 'Orden Corporativa Entrante' se establece automáticamente para la gestión adecuada del mensaje saliente tanto para seq.B como para seq.C. Cuando el Banco Emisor se rellena en el panel de Partes de la Secuencia C, el Beneficiario Intermediario (BEC) se considera predeterminado. El usuario puede cambiar los detalles, si es necesario. Este incumplimiento existe, al igual que en el escenario de ISCO saliente, el Beneficiario intermediario y el Banco emisor serían la misma parte.

se muestra a continuación.

• Receptor del mensaje:
  • Banco Emisor Local (ISS)
• Pedido corporativo entrante:
  • Esta casilla de verificación se activa cuando se recibe el mensaje de una empresa.
  • En este escenario, la recepción se basa en un «Pedido corporativo entrante», por lo que se establece la marca. Esto significa que, si se establece la función CTR, CTR se rellenará en el Tag 50 de la función saliente MT 760; de lo contrario, APL.

El Banco DOKA-NG recibe instrucciones de un Banco Emisor del Contador, solicitando la emisión de una contragarantía y solicitando que se emita un compromiso local hacia el beneficiario final.

Cuando la emisión se recibe electrónicamente, las etiquetas se asignan a los campos respectivos como se define en la transacción de mapeo entrante (en Mantenedor Mapeo de Mensajes Recibidos (DBISWH). Dado que la orden entrante es de un banco, la casilla de verificación «Orden corporativa entrante» no está marcada.

Cuando el «Propósito entrante» del mensaje del banco sea «ICCO», el «Propósito del mensaje» saliente será predeterminado como «ISCO» en la aplicación. El usuario no puede seleccionar ningún otro código de «Objetivo del mensaje», ya que la selección está restringida solo a ISCO. Este mensaje es enviado por nosotros, el Banco Emisor del Contador, al Banco Emisor Local (ISS). El «Tipo de manipulación» viene predeterminado según el propósito del mensaje seleccionado. El mensaje entrante y saliente contendría tanto la Secuencia B como la Secuencia C, en donde la Secuencia C incluirá los detalles de la garantía local. Los valores de la Secuencia B de la entrada se asignarán al panel de la Secuencia B y los valores de la Secuencia C al panel de la Secuencia C.

• La etiqueta 50 de la secuencia B (Aplicante) del mensaje recibido se asignará a la función 'CTR' (Contable/Obligador) y luego se completará la etiqueta 50 del MT760 saliente.
• La etiqueta 51 de la secuencia B (Garante) si se recibe del mensaje recibido se asignará a la función 'APR' (Aplicante para reembolso) y luego se rellenará en la etiqueta 51 del MT760 saliente.
• La etiqueta 50 de la secuencia C (Aplicante) del mensaje entrante se asignará a la función 'CTC' (Sec. C del Contable) y luego se completará la etiqueta 50 del MT760 saliente.
• La etiqueta 51 de la secuencia C (Garante) si se recibe del mensaje entrante se asignará a la función 'APC' (Sec. Aplicante C) y luego se completará en la etiqueta 51 del MT760 saliente.
• El banco emisor del mensaje Recibido se asignará al rol de parte «Solicitante» para la reserva de responsabilidad, esto sigue siendo el mismo que antes del SR2021.
• El Beneficiario definitivo siempre se establecerá en el rol BEN, que en este caso será el Beneficiario de la secuencia C.
• Cuando se reciben las instrucciones de confirmación, el banco de confirmación (etiqueta 58a) se asigna a la función CNR (Banco de confirmación entrante). Esto es para almacenar la información entrante; el usuario debe agregar el participante en el campo Participante de confirmación (CON - Banco de confirmación) que luego se rellenaría en el MT760 saliente para la etiqueta 58a.
• El beneficiario intermediario es la parte a cuyo favor se emite el compromiso o una contraparte, lo que significa que en un mensaje interbancario en el que esté implicada la Secuencia C, el beneficiario intermediario siempre será el receptor del mensaje.
• Cuando un banco que utiliza DOKA-NG recibe MT760 con ICCO de otro banco, se mencionará como el Beneficiario en la Secuencia B que se asignará al rol BEC en la aplicación. En tales casos, si BEC se asigna a OWN, los datos se borran y los datos del Banco Emisor se introducen automáticamente en BEC.

Los mapeos de roles de las partes siguen siendo los mismos, para una entrada manual por parte del usuario como antes SR2021, aparte de la función BEC adicional. El punto a notar es el Beneficiario de la Secuencia B «BEX del beneficiario intermedio (Tag59 de la Sec B)» debe llenarse en el panel «Seq.C: Partes». Y el «Beneficiario» (Rol BEN) debe rellenarse en la «Sec. B:Partes“ como antes y también se rellenará automáticamente en «Beneficiario final» en el panel «Sec.C: Partes».

Cuando el Banco Emisor se rellene en el panel «Sec.C: Partes», el Beneficiario Intermediario (BEC) tendrá un incumplimiento. El usuario puede cambiar los detalles, si es necesario. Este incumplimiento existe, al igual que en el escenario de ISCO saliente, el Beneficiario intermediario y el Banco emisor serían la misma parte.

salientes.

• Receptor del mensaje:
  • Banco emisor local (ISS)
• Pedido corporativo entrante:
  • Esta casilla de verificación no está marcada cuando se recibe el mensaje de un banco.
  • Basándose en las reglas validadas de la red SWIFT, el Tag 50(Sec.B) en el MT 760 saliente no es obligatorio para un ISCO saliente, por lo que el CTR no es obligatorio aquí.
    Si se llena el CTR, solo entonces completamos el Ordenante (Tag 50 seq.B) en la salida.