Issuance of Undertaking (ISSU)

The DOKA-NG Bank issues an MT760 undertaking (Purpose of message as “ISSU”) advises it further via one or more advising banks to the beneficiary. The issuance can be based on the receipt of an incoming electronic order from the corporate (e.g. SCORE or DTA) or a non-electronic order (paper based).

When the application for issuance is received electronically, the tags are mapped to respective fields as defined in the Incoming mapping (in Maintaining Field Mappings for Incoming Messages (DBISWH) transaction). The incoming electronic order can be received via Score (MT784) or DTA (G01) or Bolero (429).

When “Incoming Purpose” of Message from the Corporate is 'ISSU', the Outgoing “Purpose of Message” will be defaulted to 'ISSU' in the application. The user is still allowed to select other “Purpose of Message” codes – ISCO or ICCO providing more flexibility to the user. The “Handling Type” is then defaulted according to the selected “Purpose of Message”.

As per SWIFT scope:

• Field 50: Applicant –“This field specifies the party named in the undertaking as the applicant.”
• Field 51: Obligor/Instructing Party – “This field specifies the party obligated to reimburse the issuer.”

Hence, to meet the expectations for “liability” bookings with the application, there is a role exchange for Tag 50 & 51 with internal party roles APL and CTR.

• The role ‘Applicant’ from the incoming message (Tag 50) is mapped to the role 'CTR'.
• The role ‘Obligor’ from the incoming message (Tag 51) is mapped to role 'APL'.
• If role CTR is set, then Tag 50 of (Applicant) in the outgoing MT760 will contain details from role CTR, else it would contain details from role APL.
• The application identifies the incoming message type (Score/DTA/Bolero) and sets the checkbox “Incoming Corporate Order”.
• Incoming mapping of Tag 52a of Sequence B for corporate messages is set to unmapped as that would always be the bank issuing the undertaking i.e. role OWN. In this case, 52a in the outgoing will always be set to the OWN address of the bank.
• For an incoming corporate order, the checkbox “Suppress party in Outgoing SWIFT MT 760” is set by default when both parties applicant and obligor are filled. In such cases, tag 51 of the outgoing MT760 is not printed and tag 50 will be filled with the party entered in field obligor.
• When Confirmation instructions are received from the corporate, the corporate might have suggested a Confirming bank (tag 58a). This is mapped to Role CNR (Incoming Confirming Bank) and stored as incoming information. The bank user has to decide if to follow this suggestion or to overrule the corporate. The bank user must then add the party to field Confirmation Party (CON – Confirming Bank) which would then be populated in the outgoing MT760 for tag 58a as Requested Confirming Bank.
• For Standby L/Cs, when 'Available with' (Tag 41a) is received from the corporate, the party is mapped to Role AVB “Available with Bank”. This role is available in the “additional parties” grid.

The other party role mappings for BEN, ATB, AT2 remain the same.

The party roles for outgoing remains the same, for a manual input by the user as before SR2021. The user has the flexibility of selecting the parties based on the incoming non-electronic order. In this manual case, the checkbox “Incoming Corporate Order” is automatically set for the proper handling of the outgoing message. To make the checkbox more prominent for usage and to avoid any errors in the outgoing SWIFT MT 760, either setting of checkbox “Incoming Corporate Order” or setting of role ‘CTR’ is mandatory for ‘ISSU’.

is shown below.

• Incoming Corporate Order:
  • This checkbox is set when the message is received from a corporate.
  • In this scenario the incoming is based on a corporate order, hence the checkbox is marked.
    This means that, if role CTR is set, then CTR will be populated in Tag 50 of the outgoing MT 760 else role APL.
• Receiver of outgoing Message:
  • If available, Advising Bank (ATB) else Beneficiary (BEN).

The DOKA-NG Bank issues an MT 760 undertaking (Purpose of message as “ISSU”) based on an incoming MT 760 received from the Counter Issuing Bank requesting them to issue their local undertaking towards the beneficiary.

When the Issuance is received electronically, the tags are mapped to respective fields as defined in the Incoming mapping (in DBISWH transaction). As the incoming order is from a bank, “Incoming corporate order” checkbox is not set. The Outgoing Purpose of Message will be defaulted to ‘ISSU’ when the incoming code is ISCO. The user cannot select any other “Purpose of Message” codes as the selection is restricted only to ISSU. This message is then forwarded by the Local Issuing bank directly to the Beneficiary (in case of a direct relationship) or via one or more advising banks. The “Handling type” is defaulted according to the “Purpose of message”.

• The incoming message will contain both Sequence B and Sequence C where Sequence C includes the local undertaking details. As the outgoing will be an ISSU (only Sequence B with local undertaking details allowed), we map Sequence C tags from the incoming to Sequence B panels. In such cases, the application maps the tags from Sequence B that are same in both Sequence B and Sequence C to Unmapped fields.
  For e.g. tags like 56a,57a do not have corresponding sequence C tags hence it will be mapped to the panel.
  Whereas tags like 50,51,59 etc. have a sequence C tag as well which will then be set to unmapped and content from sequence C tags will be mapped in sequence B.

• The Issuing bank from the Incoming message is mapped to party role 'Applicant / APL' for the liability booking. This remains same as before SR2021.
• Tag 50 (Applicant) from the incoming message will be mapped to role 'CTR' (Accountee/Obligor) and will then be filled in the Tag 50 of the outgoing MT760. Hence in case of an outgoing ISSU, role CTR is mandatory, an error message is generated when role CTR is not set.
• 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.
• When Confirmation instructions are received, the Confirming bank (tag 58a) is mapped to Role CNR (Incoming Confirming Bank). This is to store the incoming information; the user must then add the party to field Confirmation Party (CON – Confirming Bank) which would then be populated in the outgoing MT760 for tag 58a.
• If the incoming purpose code of message is ISCO and if outgoing purpose code ISSU, then the content is mapped into field “Undertaking Text” (field GIDTXT) in Sequence B. In all other cases field 77L is mapped into “Undertaking Text” (field GIDTXTC) in Sequence C.

The other party role mappings for BEN, ATB, AT2 remain the same.

The party roles for outgoing remains the same, for a manual input by the user as before SR2021. In this case, role CTR is mandatory and the user must set CTR for the Tag 50 in the outgoing MT 760.

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. Role CTR must be set when the message is received from a bank. Only then, Applicant (Tag 50) in the outgoing MT 760 will be populated, hence Doka-NG mandates to fill CTR in this case.