de:app:030bsi:060gi:0022broadvi

Avisierung mit/ohne Bestätigung (ADVI/ACNF)

1. Avisierung aufgrund des Erhalts einer eingehenden Verpflichtung von einer Eröffnenden Bank (Eingehend ISSU)

Szenario

Die DOKA-NG Bank erhält ein MT760 von der ausstellenden Bank mit “Nachrichten Funktion Eingehend” Vermerk “ISSU”. Sie avisiert dem Begünstigten die Verpflichtung über eine oder mehrere avisierende Banken mit oder ohne Hinzufügung ihrer Bestätigung.

In diesem Fall enthalten die eingehende und die ausgehende Nachricht nur die Sequenz B, da “Nachrichten Funktion Eingehend” auf “ISSU Erstellung eines direkten Avals” lautet und die ausgehende “Nachrichten Funktion” entweder ADVI Avisierung ohne Bestätigungsvermerk oder ACNF Avisierung mit Bestätigungsvermerk sein kann. In diesem Avisierungsszenario wird die Verpflichtungserklärung weitergeleitet, ohne dass Änderungen an der von der ausstellenden Bank erhaltenen Verpflichtung vorgenommen werden. Die einzige Änderung, die hier vorgenommen werden kann, betrifft den Bestätigungsvermerk, falls dies gewünscht wird.

Wenn die “Nachrichten Funktion Eingehend” von der Bank “ISSU Erstellung eines direkten Avals” lautet, wird die ausgehende “Nachricht Funktion” standardmäßig auf ““ADVI Avis der ausgestellten Verpflichtungserklärung”” gesetzt. Der Benutzer kann jedoch auch den anderen Code für den “Zweck der Nachricht” - ““ACNF Advice and confirm of issued undertaking”” - auswählen, wenn er das Standby-Akkreditiv bestätigen möchte. Diese Nachricht wird dann von der avisierenden Bank direkt an den Begünstigten (im Falle einer direkten Beziehung) oder über eine oder mehrere avisierende Banken in der Kette weitergeleitet.

  • Die “Abwicklungsart” wird entsprechend der gewählten “Nachrichten Funktion” voreingestellt.
  • Der ausstellenden Bank der eingehenden Nachricht wird der Beteiligtenrolle 'APL “Antragsteller”' für die Engagement-Buchung zugeordnet.
  • “Tag 50 Applicant / “Auftraggeber”” aus der eingehenden Nachricht wird der Rolle “CTR “Accountee/Obligor”” zugeordnet und wird dann in “Tag 50 Applicant” des ausgehenden MT760 eingetragen.
    Da Tag 50 ein Pflichtfeld in der eingehenden ISSU ist, ist die Rolle CTR auch im Fall der Avisierung zwingend vorgeschrieben.
  • “Tag 51 “Schuldner/Obligor”” wird, falls in der eingehenden Nachricht empfangen, der Rolle “APR “Applicant for Reimbursement”” zugeordnet und dann in Tag 51 des ausgehenden MT760 eingetragen.
  • Wenn in der eingehenden Nachricht eines Standby-Akkreditivs Angaben zur “Remboursbank” enthalten sind, können diese Angaben im Vertrag unter der Rolle “RMR “Eing. Remboursbank”' in der Tabelle für “Weitere Beteiligte” auf dem Panel “Beteiligte” hinzugefügt werden.
  • Bei Standby-L/Cs wird die Partei der Rolle 'AVB “Verfügbar bei Bank”' zugeordnet, wenn in der eingehenden Nachricht 'Tag 41a Verfügbar bei' empfangen wird. Diese Rolle ist der Tabelle für “Weitere Beteiligte” auf dem Panel “Beteiligte” verfügbar.
  • Beim Empfang von MT760 von einer Bank mit ISSU als “Nachrichten Funktion Eingehend” ist “Tag 56a Avisierende Bank” der Empfänger der ausgehenden ADVI-Nachricht. Wenn in solchen Fällen die Rolle “ATB “Advice Through Bank (Tag 56a)”” der Entity OWN zugeordnet ist, wird eine Warnung im Warnungsfenster erzeugt. Der Benutzer müsste dann den Eintrag manuell ändern.
  • Wenn Bestätigungsweisungen empfangen werden, wird die eingehende “Bestätigende Bank” (Tag 58a) der Rolle CNR (Incoming Confirming Bank) zugeordnet. Der Benutzer muss dann den Beteiligten in das Feld für die Rolle CON “Bestätigende Bank”, das dann im ausgehenden MT760 für Tag 58a ausgefüllt würde.
    Diese Informationen werden in einem separaten Feld auf dem Panels “Confirmation Details”h hantiert.
  • Die Zuordnungen der Rollen der anderen Partei für APL, BEN, ATB und AT2 bleiben unverändert.

Da die Avisierungsnachricht immer von einer Bank empfangen wird, ist die Rolle CTR eine Pflichtrolle, um den tatsächlichen Antragsteller der Garantie zuzuordnen, wenn “Zweck der Nachricht” “Avisierung” lautet. Es wird eine Fehlermeldung erzeugt, wenn die Rolle CTR nicht gesetzt ist.

In ähnlicher Weise wird eine Fehlermeldung erzeugt, wenn die Checkbox “Erhaltener Kundenauftrag” gesetzt ist, sofern der Zweck der Nachricht “Avisierung” ist. Dies ist der Fall, wenn die Verpflichtungserklärung als schriftliche Garantie eingeht und der Benutzer die Vertragsdaten manuell erfasst.

Workflow, Beteiligtenmodell, Zuordnung eingehender Nachrichten, Rollen in ausgehenden Nachrichten

werden im Folgenden dargestellt

  • Empfänger der Nachricht: Sofern verfügbar, die Avisierende Bank (ATB), ansonsten der Begünstigte (BEN)
  • “Erhaltener Kundenauftrag”
    • Diese Checkbox ist nicht markiert, wenn die Nachricht von einer Bank erhalten wird. Bei den Avisierungsszenarios wird die Nachricht immer von einer Bank empfangen.

Mapping der Beteiligtenrollen

Tags Eingehendes Mapping Ausgehende Nachricht
Sequence B
50 Applicant CTR CTR
51 Obligor / Instructing Party APR APR
52a Issuer APL APL
59a Beneficiary BEN BEN
56a Advising Bank ATB ATB
57a Advice through Bank AT2 AT2
58a Requested Confirmation Party CNR CON

2. Avisierung aufgrund einer Verpflichtung einer anderen avisierenden Bank (Eingehend ADVI)

Die DOKA-NG Bank empfängt ein MT760 von der avisierenden Bank mit der “Nachrichten Funktion” ADVI/ACNF. Die DOKA-NG verwendende Bank ist eine weitere avisierende Bank in der Nachrichtenkette. Sie wird die Verpflichtung dem Begünstigten über eine oder mehrere avisierende Banken mit oder ohne Hinzufügung ihres Bestätigungsvermerkes avisieren.

  • Das Mapping zu allen Rollen bleibt wie oben beschreiben, mit Ausnahme der Rolle der Avisierenden Bank auf der Auftraggeber Seite (ADA).
  • Wenn die DOKA-NG Bank nicht die erstavisierende Bank ist und die Verpflichtung von einer anderen avisierenden Bank mit “Nachrichten Funktions” Codes “ADVI” oder “ACNF” erhält, sollte die Rolle “ADA” vom Benutzer eingetragen werden, um die Details der vorherigen avisierenden Bank im Kontrakt zu vermerken. Andernfalls erstellt die Anwendung eine Warnung, um sicherzustellen, dass die Details der avisierenden Bank in der Nachrichtenkette gespeichert wird.
de/app/030bsi/060gi/0022broadvi.txt · Last modified: 2022/04/19 13:14 (external edit)