Issuance of counter-undertaking and request to issue local undertaking (ISCO)

The DOKA-NG Bank receives the instructions from the corporate to issue a counter undertaking, requesting the issuance of a local undertaking to the ultimate beneficiary. In this case, both incoming and outcoming purpose of message will be ISCO and the messages will include both Sequence B and Sequence C.

When the 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 could be received via Score (MT784) or DTA (G01) or Bolero (429).

When “Incoming Purpose” of Message from the Corporate is 'ISCO', the Outgoing “Purpose of Message” be defaulted to 'ISCO' in the application. The user is still allowed to select other “Purpose of Message” codes – ISSU or ICCO providing more flexibility to the user. This message is then sent by us, the Counter Issuing bank, to the Local Issuing (ISS) bank. The “Handling type” is defaulted according to the selected Purpose of message.

• The incoming and outgoing message will contain both Sequence B and Sequence C where Sequence C will include the local undertaking details. The Sequence B from the incoming will be mapped to Sequence B panels and Sequence C to Sequence C panels.
• In this case, the application identifies the incoming message type (Score/DTA/Bolero) and sets the checkbox “Incoming Corporate Order”.
• The role ‘Applicant’ of sequence B from the incoming message (Tag 50) is mapped to the role 'CTR'.
• The role ‘Obligor’ of sequence B from the incoming message (Tag 51) is mapped to role 'APL'.
• For an incoming corporate order, the checkbox “Suppress party in Outgoing SWIFT MT 760” in sequence B parties panel is set by default when both parties applicant and obligor are filled. In such cases, tag 51 (seq. B) of the outgoing MT760 is not printed and tag 50 (seq. B) will be filled with the party entered in field obligor of sequence B.
• The role ‘Applicant’ of sequence C from the incoming message (Tag 50) is mapped to the role 'CTC'.
• The role ‘Obligor’ of sequence C from the incoming message (Tag 51) is mapped to role 'APC'.
• For an incoming corporate order, the checkbox “Suppress party in Outgoing SWIFT MT 760” in sequence C parties panel is set by default when both parties applicant and obligor is filled. In such cases, tag 51 (seq. C) of the outgoing MT760 is not printed and tag 50 (seq. C) will be filled with the party entered in field obligor of sequence C.
• If role CTR is set, then Tag 50 of sequence B (Applicant) in the outgoing MT760 will contain details from role CTR, else it would contain details from role APL.
  Similarly, if CTC is set then Tag 50 of sequence C (Applicant) in the outgoing MT760 will contain details from role CTC, else it would contain details from role APC.
• Incoming mapping of Tag 52a (Issuer) of Sequence B for corporate messages is set to unmapped.
• A new role BEC (Intermediary Beneficiary) is introduced to capture Beneficiary details (Tag 59) of Sequence B when Sequence C is present. Although it captures details about Sequence B Beneficiary, this party is visible in “Seq.C: Parties” panel in the application.
• The Ultimate Beneficiary will always be set to Role BEN in the application which will be in this case Beneficiary from Sequence C.
• 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) of Seq.B is received from the corporate, the party is mapped to Role AVB (Available with Bank).
  This role is available in the “Additional Parties” grid.
• For Standby L/Cs, when 'Available with' (Tag 41a) of Seq.C is received from the corporate, the party is mapped to Role AVC (Available with Bank C).
  This role is available in the “Seq.C: Parties” panel.

The party role mappings remain the same, for a manual input by the user as before SR2021 apart from the additional BEC role. Point to note is Beneficiary of Sequence B (Role BEC- Intermediary beneficiary) must be filled in the 'Seq.C: Parties' panel. And Ultimate Beneficiary (Role BEN -in this case Sequence C Beneficiary) must be filled in the Parties panel as before. In this manual case, the checkbox 'Incoming Corporate Order' is automatically set for the proper handling of the outgoing message for both seq.B and seq.C. When the Issuing Bank is filled in Sequence C Parties panel, the Intermediary Beneficiary (BEC) is defaulted. The user can change the details, if required. This defaulting is in place, as in the outgoing ISCO scenario, Intermediary Beneficiary and Issuing bank would be the same party.

is shown below.

• Receiver of Message:
  • Local Issuing Bank(ISS)
• Incoming Corporate Order:
  • This checkbox is set when the message is received from a corporate.
  • In this scenario the incoming is based on an “Incoming Corporate Order”, hence the flag is set. This means that, if role CTR is set, then CTR will be populated in Tag 50 of the outgoing MT 760 else role APL.

The DOKA-NG Bank receives instructions from a Counter-Counter Issuing Bank, requesting the issuance of a counter undertaking and requesting a local undertaking to be issued towards the ultimate beneficiary.

When the 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). As the incoming order is from a bank, “Incoming corporate order” checkbox is not set.

When “Incoming Purpose” of Message from the bank is 'ICCO', the Outgoing “Purpose of Message” will be defaulted to ‘ISCO’ in the application. The user cannot select any other “Purpose of Message” codes as the selection is restricted only to ISCO. This message is then sent by us, the Counter Issuing bank to the Local Issuing (ISS) Bank. The “Handling type” is defaulted according to the selected Purpose of message. The incoming and outgoing message would contain both Sequence B and Sequence C where Sequence C will include the local undertaking details. The Sequence B values from the incoming will be mapped to Sequence B panel and Sequence C values to Sequence C panel.

• Tag 50 of sequence B (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.
• Tag 51 of sequence B (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.
• Tag 50 of sequence C (Applicant) from the incoming message will be mapped to role 'CTC' (Accountee Seq.C) and will then be filled in the Tag 50 of the outgoing MT760.
• Tag 51 of sequence C (Obligor) if received from the incoming message will be mapped to role 'APC' (Applicant Seq.C) and will then be filled in the Tag 51 of the outgoing MT760.
• The Issuing bank from the Incoming message will be mapped to party role 'Applicant' for the liability booking, this remains same as before SR2021.
• The Ultimate Beneficiary will always be set to Role BEN, which will in this case be Beneficiary from Sequence C.
• 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.
• The intermediary beneficiary is the party on whose favor the undertaking or a counter-undertaking is issued, which means that in an Interbank message where Sequence C is involved, the intermediary beneficiary will always be the receiver of the message.
• When a bank using DOKA-NG receives MT760 with ICCO from another bank, they will be mentioned as the Beneficiary in Sequence B which will be mapped to role BEC in the application. In such cases, if BEC is mapped to OWN, the data is cleared and data from Issuing Bank is filled into BEC automatically.

The party role mappings remain the same, for a manual input by the user as before SR2021 apart from the additional BEC role. Point to note is Beneficiary of Sequence B “Intermediary Beneficiary BEX (Tag59 of Seq B)” must be filled in the “Seq.C: Parties” panel. And “Beneficiary” (Role BEN) must be filled in the “Seq. B:Parties” panel as before and will also be auto populated to “Ultimate Beneficiary” on “Seq.C: Parties” panel.

When the Issuing Bank is filled in “Seq.C: Parties” panel, the Intermediary Beneficiary (BEC) is defaulted. The user can change the details, if required. This defaulting is in place, as in the outgoing ISCO scenario, Intermediary Beneficiary and Issuing bank would be the same party.

is shown below

• Receiver of Message:
  • Local Issuing Bank (ISS)
• Incoming Corporate Order:
  • This checkbox is not set when the message is received from a Bank.
  • Based on the SWIFT network validated rules Tag 50(Seq.B) in the outgoing MT 760 is not mandatory for an outgoing ISCO, so CTR is not mandatory here.
    If CTR is filled, only then we populate Applicant (Tag 50 seq.B) in the outgoing.