Advice of an issued undertaking with/without confirmation (ACNF/ADVI)

The DOKA-NG Bank receives an MT760 from the Issuing bank with “Incoming Purpose” as 'ISSU'. It will further advise the undertaking to the beneficiary via one or more advising banks with or without adding its confirmation.

Here, the incoming and outgoing message will contain only Sequence B as “Incoming purpose” of message is 'ISSU' and the outgoing “Purpose of Message” can be either ADVI Advice of issued undertaking or ACNF Advice and confirmation of issued undertaking. In the advising scenario, the undertaking will just be forwarded without changes to the Guarantee received from the Issuing bank. The only change here could be on the confirmation details, if requested.

When “Incoming Purpose” of the message from the bank is 'ISSU', the Outgoing “Purpose of Message” will be defaulted to '“ADVI Advice of issued undertaking”'. The user is still allowed to select the other “Purpose of Message” code – '“ACNF Advice and confirm of issued undertaking”', in case of confirming the Standby L/C. This message is then forwarded by the Advising bank directly to the Beneficiary (in case of a direct relationship) or via one or more advising banks in the loop.

• The “Handling Type” is defaulted according to the selected “Purpose of message”.
• The issuing bank from the incoming message will be mapped to party role 'APL “Applicant”' for the liability booking.
• 'Tag 50 Applicant' from the incoming message will be mapped to role 'CTR “Accountee/Obligor”' and will then be filled in the 'Tag 50 Applicant' of the outgoing MT760.
  As Tag 50 is a mandatory tag in the incoming ISSU, role CTR is also made mandatory in the Advice case.
• 'Tag 51 Obligor' if received from the incoming message will be mapped to role 'APR “Applicant for Reimbursement”' and will then be filled in the Tag 51 of the outgoing MT760.
• If Reimbursing bank details are present in the incoming message of a Standby L/C, such details could be added in the contract under party role ‘RMR “Inc. Reimbursement Bk”' in the grid for “Additional Parties” on panel “Parties”.
• For Standby L/Cs, when 'Tag 41a Available with' is received from the incoming message, the party is mapped to Role 'AVB “Available with Bank”'. This role is available in the grid for “Additional Parties” on panel “Parties”.
• On receiving MT760 from a bank with “Incoming Purpose” as ISSU, Tag 56a (Advising Bank) will be the receiver of the outgoing ADVI message. In such cases, if role 'ATB “Advice Through Bank (Tag 56a)”' is mapped to OWN entity, a warning would be generated in the warnings panel. The user would then have to modify the entry manually.
• When Confirmation instructions are received, the Confirming bank (tag 58a) is mapped to Role CNR (Incoming Confirming Bank). This is to store the incoming requested confirming bank; the user must then add the party to field “Confirmation Party” for 'CON “Confirming Bank”' which would then be populated in the outgoing MT760 for tag 58a.
  These information are handled on the separate “Confirmation Details” panel.
• The other party role mappings for APL, BEN, ATB, AT2 remain the same.

As the advice message will always be received from a bank, the role CTR is a mandatory role to map the actual applicant of the Guarantee when outgoing “Purpose of message” is Advice. An error message is generated when role CTR is not set.

Similarly, an error message is generated if “Incoming Corporate Order” checkbox is set, when Purpose of message is 'Advice'. This applies, when the Undertaking is received as a paper guarantee and the user manually inputs the contract data.

is shown below.

• Receiver of Message: if available, Advising Bank (ATB) else Beneficiary (BEN)
• Incoming Corporate Order: This flag is not set when the message is received from a bank. For the Advice scenarios, the message will always be received from a bank

The DOKA-NG Bank receives an MT760 from the Advising bank with incoming Purpose as ADVI/ACNF. Here bank using DOKA-NG is another advising bank in the chain and will advise the undertaking to the beneficiary via one or more advising banks with or without adding its confirmation.

• The mappings to all the roles except for role Advising bank on the applicant side (ADA) remain the same as above.
• Where DOKA-NG bank is not the first advising bank and receives the incoming undertaking from another advising Bank with “Purpose of Message” Codes as ‘ADVI’ or ‘ACNF’, the role ‘ADA’ should be filled in by the user, to capture the previous advising bank details in contract. If otherwise, the application will generate a warning message to ensure the details of the Advising bank in the chain is stored.