This transaction is used to create/advise a new undertaking (guarantees and standby L/Cs).

If a draft/pre-advice is already available for an undertaking, all available data relating to the draft/pre-advice is made available once the user has selected the relevant contract. This can be edited as necessary.

The following types are supported by the application.

• Issuance of undertaking (ISSU)
  We create an undertaking in favor of the beneficiary and forward this either directly to the beneficiary, or via the advising bank.
• Issuance of counter-undertaking (ISCO)
  We instruct the issuing bank to create an undertaking in favor of the beneficiary for which we assume full responsibility.
• Issuance of counter-counter-undertaking (ICCO)
  We instruct the counter-issuing bank to instruct the issuing bank to create an undertaking in favor of the beneficiary.
• Advice and confirmation of issued undertaking (ACNF)
  We advise the undertaking and assume full responsibility by adding our confirmation.
• Advice of issued undertaking (ADVI)
  We advise the undertaking without obligation on our part to the beneficiary.
• Guarantee received
  A guarantee in our own favor.

The undertaking type describes the relevant type of undertaking and is one of the selection criteria for picking the 'choice of text' (see also General Information on Advanced Text Definition).

This field is used to define the legal form of the undertaking.

These values are supported (also for input from electronic message channels):

• Demand Guarantee
• Standby Letter of Credit
• Dependent Undertaking (Surety)
• Surety Payable on First demand

The “Form of Undertaking” field was used in the application before the guideline fields “Applicable Rules” (APPRUL and APPRULTXT') was introduced by SWIFT.
In larger installations with a multitude of guarantee texts, the field is used to divide the list of proposed guarantee texts. (The “Form of Undertaking” field is also available as “Legal Form” in the General Information on Advanced Text Definition transaction.) This is particularly helpful for banks that use a large number of standard texts.
With smaller installations the use of “Applicable Rules” is usually sufficient.

SWIFT interbank message (MT760), supports only the values ‘Demand Guarantee’ and ‘Standby Letter of Credit’ in sequence B of its message. Hence, if applicant requests for any other form of undertaking, as recommended by SWIFT, DOKA-NG generates a MT759 (ancillary message) instead of MT760.

Expiry Type : In case of direct (ISSU) and Advice (ADVI, ACNF) scenarios, the validity of the undertaking is defined under the Expiry type field. In case of an indirect undertaking (ISCO, ICCO), the validity of the local undertaking (sequence C fields) is defined under the Expiry type fields.

Liability Type : This is only active in case of an indirect undertaking. In this scenario, the validity of the counter undertaking (sequence B fields) is defined under the liability type fields.

Below options are allowed for the expiry/liability type selection:

• “Expiry condition”:
  User to mandatorily provide a specific condition to be fulfilled for expiry of the Undertaking, whilst a specific date for expiry is optional. The expiry condition can also be defined and maintained along with the undertaking text in the Maintaining Advanced Text Definition transaction
• “Specified date of expiry”:
  User could provide a specific date for the expiry of the undertaking. On selecting this type, an expiry/liability date must be specified in the corresponding field.
• “No specified date of expiry”:
  If the undertaking is an open contract without a specific expiry date, this option could be selected.

The main information here is the undertaking text. This is automatically proposed based on data such as type of processing, undertaking type, form and language . Depending on the undertaking type and the definition of the relevant text, some additional fields may have to be completed. If required, the user is able to edit the undertaking text manually by checking the “Modify Text” checkbox. It is also possible to format the text, using three formatting buttons - bold, italics or underline. The undertaking text is displayed with the unresolved variables. In this case, a warning is generated, indicating that the undertaking text has been edited manually. The [vs. System] button shows the user's manual changes compared to the undertaking text proposed by the system. The [vs. History] button shows the changes made to the undertaking text in the past. Entries made by the user are shown in yellow, deletions in red. To view the text showing any resolved variables click the [Show Text] button. Contract datafields embedded in the text are updated instantly. Manual changes are only conclusively accepted in the system when the icon is clicked.

If the reference number of the contract is required in the undertaking text - for example when adding a new guarantee, or pre-advising a guarantee - this can be generated in advance using the [Get Ref.] button.

All open fields on the Details panel have been defined as elements of the undertaking text in the relevant definition of the text. Accordingly, they have become mandatory fields. It makes sense, therefore, to adapt the definition of undertaking texts appropriately. As much as possible, the aim is to avoid users having to edit guarantee texts manually, and to avoid verifiers having to check individual undertaking texts.

If the checkbox “Create Declaration of Indemnity” on panel “Overview” is checked, the panel “Declaration of Indemnity” will also be displayed. On this panel the text of the Declaration of Indemnity to be sent can be entered.

If a guarantee is to be settled automatically, the option for fee settlements (accessed by clicking the icon) on the Liability Panel is set to 'Automatic'. If the selected guarantee is to be settled manually, change the setting to 'Manual'.

Furthermore, syndications can be handled on the homonymous panel. Detailed information about syndications can be found under “Participations Sold (Syndications)”.

Detailed information on the processing of assignments can be found under: “Assignments”.

Standby LCs/guarantees can be issued for a limited period if banks are concerned about issuing contracts for longer terms. The Auto-Extension functionality provides the ability to automatically extend the expiry date of the contract. The checkbox “Auto-Extension” can be set for a standby LC or guarantee, which makes the “Auto-Extension” panel visible and allows the user to enter the details of the auto-extension schedule. The Auto-Extension process can be initiated when issuing or amending the contract (such as Creating a Guarantee/Standby, Amending or Internal Amendment). Diary entries are generated or updated in these transactions in order to inform the account officer/relationship manager or applicant of the upcoming Auto-Extension and to process the Auto-Extension itself. The Auto-Extension Advice is sent to the account officer/relationship manager or applicant by processing of the diary in transaction Common Messages. The Auto-Extension is done by processing of the diary in transaction Internal Amendment. With activation of the SWIFT 2021 release, for Indirect Guarantees, Auto-Extension could be chosen for both Sequence B (counter undertaking) and Sequence C (local undertaking). In cases of these indirect guarantees, auto registered entries such as diaries will be generated based on the auto extension value from sequence B.

Until timely notice of Non-Extension is given by the account officer/relationship manager or applicant, the standby LC/guarantee will automatically be extended for an additional period as per defined “Extension Period” until the “Final Expiry Date” is reached or cancellation is agreed to by the beneficiary (please refer to Internal Amendment).

This functionality is enabled for Standby L/C's only, where the user can include the Reimbursement bank who can reimburse a claim that is presented by the 'Available with bank' (AVB). Details related to the reimbursement such as Reimbursement bank, Account details etc. can be captured in the panel 'Reimbursement Authorization'. This panel is enabled when the 'Reimbursement Authorization' checkbox is set from the overview panel. Swift message MT740 is sent out in this case.

This transaction creates a new Guarantee contract.
If an existing Guarantee contract is used, it may not be open or closed.

For more information see TRNDIA Diaries.

If changes are made to the maturity date in the Increase/Decrease Schedule, diary events to correct the liability are created in the “Handling Increase/Decrease Schedule” transaction.

The amount of the guarantee and, where applicable, any additional amount are stored.

A liability is booked regardless of the handling type and confirmation status. If there are several applicants the liability is to be spread across the applicants in accordance with their respective proportion in the guarantee on the “Liability” panel.

Details on creation of messages can be found under DOCEOT Messages.

Assignments messages and messages concerning Participations Sold (Syndications) will be created.

Signature required

Overview
Parties
Presentation/ Delivery
Details
Undertaking Text
Declaration of Indemnity
Confirmation Details
Auto-Extension
Add. Amounts
Reimbursement Auth.
Assignment
Electronic MSG Details
DTAG Fields
Settlement Details
Settlement
Completion
Messages
Compliance
Attachments
Seq. C: Overview
Seq. C: Parties
Seq. C: Presentation/ Delivery
Seq. C: Details
Seq. C: Undertaking Text
Seq. C: Auto-Extension
Seq. C: Add. Amounts