Guarantee and Standby LC'S :  Business Sector (‘GI’)

Introduction:

Demand Guarantees:

When a demand is made to the Guarantor (and it is compliant with the terms of the Guarantee), the Guarantor is obligated to pay, regardless of the underlying relationship. The obligation is based solely on the Guarantee itself and the demand.

What are the different types of Guarantees?

Direct Guarantees:

The most common way to issue a Guarantee, as these are issued by the Guarantor directly the Beneficiary, who must present demand for payment direct to the Guarantor. This demand can be issued by letter, telecommunications, or via SWIFT. In this instance, the Guarantee is issued by the Applicant’s bank and forwarded to the Beneficiary through its bankers. The advising party is not obligated to the Beneficiary under the Guarantee.

Indirect Guarantees: 

The Applicant’s bank issues the Counter Guarantee to the Beneficiary’s bank and instructs it to issue its own Guarantee to the Beneficiary. An undertaking given by the counter-Guarantor to another party which names that party as the Beneficiary to procure the issue by that other party of a local guarantee to be issued to the Beneficiary in the underlying contract/relationship. The Counter Guarantor is obligated to the Guarantor and the Guarantor is obligated to the Beneficiary. The Counter Guarantor undertakes to
reimburse the Guarantor should a complying demand be made under the Guarantee.

In Doka -

The “Guarantees” business sector covers all transactions related to the processing of an undertaking (guarantees and standby L/Cs). The guarantees/ undertakings differ in the way they are handled. Accordingly, each purpose of message type will be described separately since not all of the
available transactions can be used in a similar manner with each type.

For outgoing (direct and indirect) guarantees, the guarantee texts specified Advanced Text module by the legal department are stored only once in the master data system according to the type of guarantee (e.g. advance payment guarantee, performance guarantee),legal form, language and frequency of use, and they can then be used as often as required for issuing undertakings.

SWIFT 2021 regulatory changes for Guarantees and Standby L/C's have been introduced to improve the communication efficiency and to support STP (Straight Through Processing) through highly structured and clearly defined messages. This means that the SWIFT messages (MT760, MT767 etc.,) for Guarantees and Standby L/C's consist primarily of structured fields and fields with coded options (such as amounts, parties, expiry details etc.).

The messages for issuance and amendment of undertakings are divided into three blocks:

Sequence A: is mandatory and contains general information, such as the Purpose of Message (Tag 22A) which basically drives the whole subsequent flow.
Sequence B: is mandatory in interbank messages and indicates either the details of the directly issued undertaking or the details of the (counter) counter-undertaking resp. the counter-counter-undertaking.
Sequence C: is optional and indicates the details of the requested local undertaking when Sequence B is used for the (counter) counter-undertaking.

Guarantee Types / Purpose of Message :

The following types of processing are supported in 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 Guarantee Undertaking types available on DOKA SaaS are,

Bid Bond
Performance Bond
Warranty Bond
Payment Guarantee(Financial/Other)
Payment Guarantee(Goods/Services)
Credit Card
Credit Facilities
Advance Payment Guarantee
Direct Pay(Reinstatement)
Documentary Credit

Guarantee Workflow - 

Pre-Open Guarantee -

The 'Pre-opening of draft' is not actually the final set of Guarantee created as this contains only the draft version that is used for discussion in the contractual negotiations between the parties.
The following type of request is allowed by the Application in the Pre-opening process, Draft, Pre-advice, Declaration of readiness  To Pre-open a Guarantee , GITPOP transaction is used.

Guarantee Open -

'Guarantee' means any signed undertaking, however named or described, providing for payment on presentation of a complying demand. To create/advise a new contract (Guarantees and Standby L/Cs), GITOPN transaction is used.

Guarantee Amendment -

The 'Amending' refers to the modifications carried out to the terms and conditions (for instance changing the New Expiry Date, New Expiry type, New Liability type, Amount Increase/Decrease,
and other related amendments) of an existing Guarantee contract. To Amend an existing open Guarantee contract(Guarantees and Standby L/Cs), GITAME transaction is used.

Request of Amendment -

The 'Request of Amendment' refers to the Guarantee Amendment request with detrimental changes(such as amount, expiry & liability date, beneficiary and delivery details) that are made to
the terms and conditions of the existing Guarantee contract. The changes are detrimental to the beneficiary and hence an acknowledgement is needed from him (acceptance/rejection) for the
amendment to become effective. To do Request of Amendment for an existing open Guarantee contract(Guarantees and Standby L/Cs), GITRAM transaction is used.

Register a Claim request -

The 'Guarantee Claim' means registering a claim request under a guarantee/standby L/C in the application with the Full undertaking amount or Partial amount of it. There is a possibility to request more than one claim under a guarantee/standby L/C. To Register a claim for an existing open amount Guarantee contract, GITCRQ transaction is used.

Pay a Guarantee Claim -

The registered claim under a guarantee contract is allowed to settle/pay in the application. To Settle a claim for an existing open Guarantee Claim contract, GITSET transaction is used.

Reject a Claim -

The registered claim under a guarantee contract is rejected with valid reason of Rejection. All the parties under the contract to be notified with the rejection and closes the claim. To Reject a claim for an existing open Guarantee Claim contract, GITCRJ transaction is used.

Cancel/Close a Guarantees/Standby LCs -

The Created Open Guarantee contract can be closed at any time for several reasons. The Reason for Cancelation is the reason notified to the parties for the Guarantee cancellation.
To Close an existing open Guarantee contract, GITCAN transaction is used.

Reopen of Closed Guarantee -

There is a Possibility to reactivate a closed Guarantee contract in the System in order to process other transactions. The closing date of the contract is deleted after reactivating the Guarantee.
To Re-open a closed Guarantee contract, GITROP transaction is used.

Workflow - Snapshot 

Copying guarantee data (Seq.B to C)

As per Standard release changes of 2021 introduced sequences B & C in the SWIFT, Within these sequences, there were repeated or connected tags, which carried the same values. Therefore, the user had to repeat manual input of the same value in the respective panels for both the sequences.

To eliminate this dual effort, values of certain fields/tags have been enhanced to be copied between the sequences, with conditions such as, if the target fields are not already filled or modified.

Identical values are copied within sequences in the issuance transactions (GITOPN, GITOPR, GITPOP) and in the amendment transactions (GITAME, GITRAM, GITAMR).

Examples of fields copied: 50 Applicant, 51 Obligor, 32B Amount and Currency, 40C Applicable rules etc.

Outgoing Messages -