Documentation - DOKA-NG (Functional availability is per selected plan)

Book Creator

Add this page to your book

Book Creator

Remove this page from your book

Manage book (0 page(s))

Help

General information on SWIFT Release 2021

FAQ

The chapter covers

background info about message usage
background info about swift fields
general and often asked questions for inside Surecomp and from customers

Especially the background info are based on meeting notes of Swift's Trade Finance Working for MT maintenance. For questions about this, ask dirk.middeldorf@surecomp.com

tbc.

Information per field / tag

Field	Field name	Field in DOKA	Question	Answer
44H	Governing Law and/or Place of Jurisdiction	JURLAWS20 + JURPLC Seq.B + Seq.C	Understanding 'and/or'	Swift clarification “From a validation point of view, the country is mandatory, if 44H is used. From a business/legal point of view, if you enter “NY court” in place of jurisdiction, although you have enter US in country, what really matters is “NY court”, so in fact you only have a place of Jurisdiction, this explains the 'and/or' ”
44H	Governing Law and/or Place of Jurisdiction	JURLAWS20 + JURLAW. Only Seq.B	What happens with previous content (before SR2021) of field “JURLAW” ?	It will be shown, but the field remains disabled. The user must manually select the ISO country code, if required. If field Place of Jurisdiction (JURPLC) was filled in the legacy contract, it will be shown and the field remains disabled. To modify/update JURPLC, the ISO country code needs to be selected. Banks should check how that works with their guarantee texts, as this field is often used to place the content into the guarantee text.
15C	Sequence C	Seq.C panels	MT767 - rule C3: Sequence C must be present if Purpose Codes ISCA or ICCA are used. What to do, if only a change in one sequence is required but not both?	Swift clarification: It is most likely that a change in the counter/counter-counter interbank guarantee (Sequence B) will also effect a change in the local guarantee (Sequence C) or vice versa. This assures, that the subsequent amendment numbers are always syncronized for both sequences. Changes within only one Sequence are to be considered as extremly rarely used. Therefore a change outside the MT767, preferably by an MT 759, is recommened.
23F 78 26E 31S	Automatic Extension / Auto-Extension fields in sequence B and in sequence C	panel RNWP (seq.B) and panel RNWPC (seq.C)	How different can Auto-Extension be between seq.B and seq.C.?	- There are no direct dependencies related to Auto-Extension in sequence B and sequence C, except the expiry dates. But that is the same as without Auto-Extension. - Only the expiry/liability dates are checked. - In case further checks are requested, they should to be done on customer level. - Diary entries and outgoing documents are based on the input on Auto-Extension panel for sequence B.
39D in MT 769			details in SER dngdev.002381
23X	File Identification	Non visible field	Field 23X is an optional field but it is mandatory for FileAct attachements with MT759 and other Swift Interbank and Swift Score messages. As per Swift specifications it allows also other codes. Where can I select them and enter the additional information for each codeword?	23X is an optional field. Only the code FACT for FileAct attachments is used in DOKA. The correct content is generated automatically with service Swift (SRVSWT). As this is only an optional field, we decided for the DOKA product, not to support the other codewords yet. In case you want to use it, please provide us with a your chargable change request.
22A	Purpose of Message	PURPOSIN PURPOS	DTA / DTG does not allow purpose code ICCO in 22A. Why?	The German Trade Finance Commitee investigated, found out and decided that the Counter-Counter a) is a rare business case for them b) confuses the corporates. Corporates are usually are just expecting that a (local) undertaking in favour of a Beneficiary is issued. They shouldn't care about the intermediary parties, liabilities and responsibilities. It can be compared to 'clean payments': When you want to remit an amount to a person, than just their account serving institution plus beneficiaries account number plus the currency and amount are suffient. It is generally up to your bank to decide through which channel(s) the bank will transfer the remittance to the beneficiary. Or in other words: The German DTA committee tried to make the guarantee business as easy for the applicant as possible.
77U + 77L			What is the difference of 77U and 77L between Issuance/Advice and Amendment.	Handling of amending 77U/77L cannot be compared to amending long text fields in L/Cs. No codewords like REPALL, ADD or DELETE exist. Each change of the text has manually to be described. Copying the 'full guarantee text' is possible via a checkbox. Different scope of fields 77U and 77L compared between amendment and the original issuance or advice message. a) For Issuance and advice fields 77U and 77L carry explicitly only the undertaking text. b) In amendment messages fields 77U and 77L carry any changes to the fields that are not in structured fields (e.g. Presentation Instructions, Confirmation Details etc.)
71B of Score MT781	Charges and Swift Code	in DBxFEE: SFTCOD	Is this field necessary to be changed by the bank?	As long as the bank only uses fees, set up by DOKA (which is most likely nowhere the case) the bank does not need to change anything. IF the bank has the own FEE structure for guarantees, than please read the chapter below this table about “Charges in MT 781”
72Z in MT707 Interbank	Sender-to-Receiver Information	ADDSTR	Codeword BENCON was removed from the Swift specifications. Why is it still there?	BENCON had been deleted in the Swift specifications. Nevertheless, we will still default it, as this is a Trade Finance community wide used codeword for decades. As Codeswords in MT777 field 72Z are not validated by the Swift network, we keep it there. The benefits are expecially for the receivers. In case BENCON is filled in an incoming message, then it allows the receiving system to route messages to specific transactions. In Doka terms it would be for example GITRAM.
24G	Delivery to	DELTO + DELTOADR	Usage and defaulting?	GITOPN (GITOPR, GITPOP): If Purpose Code PURPOS = ISSU and Incoming Corporate Order Flag INCCORMSGFLG is set and no incoming C2B message is processed that has mapped to DELTO (and DELTOADR) then default Delivery To/Collection By DELTO to Beneficiary BENE instead of OTHR If not filled with 'BEN', 'DELTO' now will be empty.
Tag 23H in MT759 a new code REXTMATU is introduced	Function of Message	“NEWMATDAT” in xxTFRE for BR, BE and BT modules	How to process the request to extend the maturity date (REXTMATU)	In the xxTFRE transactions of BR, BE and BT module, the new code REXTMATU is added to the dropdown field 'Function' in the MT759 panel. If the user selects this code, a new 'Maturity Date' field will be visible and enabled for input. Upon saving this common message an auto registration for the relevant xxTTEN will be created. The requested new maturity date will be defaulted in the auto-registered xxTTEN transaction. Based on which the user could update the maturity date in the Liability panel.

Interbank messages

tbc

Score messages

Revised reference numbers 21A/21T and 21P/21S:
- Customer References - 21A + 21T
- Bank References - 21P + 21S
- Both references are mandatory for the sending party.
- The first reference of the sender is considered as 'technical reference'
- The second reference of the sender is considered as 'business reference'.
- Additionally, the guarantee number might appear in some messages.
- Details are in “Score specification, chapter 1.5” plus in the message description.

Tag 29B 'Issuing/Guarantor Bank contact', will be ignored in DOKA-NG and not populated in the Score messages MT745, MT743 and MT729. These score messages are sent from the Advising bank to the Beneficiary. The Beneficiary does not require the Issuing/Guarantor Bank contact detail, as there is no direct relationship between Beneficiary and Issuing bank. Therefore tag 29B will be ignored in the specified messages.

MT712 cannot be routed to GITCRQ. Why?
- Problem: Incoming MT712 is routed to SPTROU, but not to GITCRQ.
- Reason:
  In the index part of MT712 is no field, where a beneficiary can add a Bank reference or contract number. \ Not even the undertaking number is part of the MT712-index.
  Therefore, Doka can only route this message to SPTROU.
- Handling recommendation:
  A user must identify from the joint MT712/765 the correct undertaking number and route the MT712/765 manually to the correct contract in GITCRQ.

MT755 not implemented for Guarantees. Why?
- Reason: Currently DOKA-NG uses MT755 for usance/deferred export LC and not for sight LC. Since Standby LC in Guarantee will always be considered sight, support of MT755 is not required in product.

Dependent Undertaking / Surety / Bürgschaft

Usage of MT759, MT719 and other messages

These types are not allowed to be issued via Swift Interbank MT760/761. Although the application and notification messages allow “Dependent Undertaking / Surety / Bürgschaft”.
Here are some info, given by Swift in the FAQ for MT719

In case of application to issue a dependent undertaking (DEPU/SURT/SPDM in field 22D of 760/G01), 
the "drafting flow" will use MT 798 <784, 760, (761)>, <762, 760, (761)>, <719> as for independent undertakings. 

If the bank issues a dependent undertaking, 
- it will notify the issuance by MT 798 <762, 760, (761)> to the corporate. 
- If the dependent undertaking is issued by paper, the bank could also provide a paper copy to the applicant. 
- If the dependent undertaking is issued and sent electronically by swift to another bank, it must be by MT 759 as it cannot be issued by MT 760!
- The different elements agreed during the drafting in sequence B of 760 will be copied in field 45D of 759 and sent to another bank.  
  
Please note: 
This is not the majority. Many dependent undertakings are issued domestically (without usage of MT760/761) and/or on paper. 
Amendments to dependent undertakings are also less frequent than amendments to L/Cs or standby L/Cs).

… tbc. …

Bolero

The below mentioned Bolero messages are new.

402 Undertaking Extend Or Pay Query
403 Undertaking Extend Or Pay Response
404 Guarantee Reduction Request
420 Undertaking Application Refusal
421 Undertaking Amendment Request Refusal
424 Undertaking Amendment Response Advice
432 Undertaking Advice
433 Undertaking Amendment Advice
458 Guarantee Reduction Request Refusal
4999 Conversation Message → sep SER: DNGDEV.004591

Will DOKA and COR-TF support them?
No. Even though these messages have a Swift Score equivalent, there is no need to implement them in DOKA.

Reasons:

Only those messages which are are already supported, will be updated for maintenance.
b) There is no need to support new Bolero messages.
Doka and COR-TF do not underly any police or any requirement to fulfill the full spectrum of Bolero messages. That is unlike to the 'Swift Certified Application Label' for messages from Swift, where the label itself implies that all messages are supported.
The only exception is 4999 Conversation message. The DOKA product decision for 4999 is that this message is considered as relevant to be implemented.

Implementation of the new Bolero messages can be done upon chargeable change requests by clients.

Fields, used commonly in several messages

tbc

Other FAQs

Migration of Standby LC from LC module to guarantee module

No automated migration needed, on adhoc basis only. When a Standby LC that was issued as a MT700 has to be amended, the contract should be closed in the LC module and reopened in the guarantee module (maybe using the migration trn). The old LC reference can be entered into 'Old reference' field of the guarantee module.

How to convert an ‘alternative’ mapping to a regular mapping after SWIFT activation date has passed?

This does not have to be solved now as the alternative mappings that are established for SWIFT 2018 and 2021 affect different messages. A solution must be found only when SWIFT changes the mappings in the future, e.g. in a SWIFT 2021 release. There are currently no changes announced that indicate this.

What happens to the Sequence B & Sequence C fields on receiving a MT 760 with an incoming purpose code ISCO

On receiving an incoming ISCO, sequence B fields are set to unmapped and sequence C fields are mapped to sequence B panels using sequence B mappings. This switch happens in the transaction SWITSK while importing the message. For the tags that do not have a corresponding sequence C tag for e.g. Tags 56A, 57A, 20 etc. must be removed from this logic for the sequence B mappings to work as usual, if not they will be set to unmapped in general.

Autoconverting SWIFT MT799 to MT759

In transaction DBxSYS, on panel “SWIFT Release”, a new checkbox “SWIFT Autoconvert to MT759” with the following functionality is implemented: For Letters with no dedicated SWIFT message type of category 7 (MT7xx), DOKA-NG uses autoconvert to MT799. Based on the SWIFT recommendation, MT759 should be used instead of MT799 and usage of MT799 shall be reduced. On selecting the checkbox “Swift Autoconvert to MT759”, messages will be autoconverted to MT759 instead of MT799.

Outgoing Message with Purpose code ICCO for DTA/Bolero

As DTA does not support the ICCO(Issuance of a Counter Counter Undertaking), the messages G02, G04 will be auto converted to a Free format when code ICCO is used.
As Bolero 419,422 does not support ICCO scenario, DOKA-NG will Auto convert the message to a letter when the code ICCO is used.

Topics, to be discussed with clients:

Bank-to-Bank-Information, which should not appear in Bank-to-Corporate communication

Relevant for: all banks To do: Bank's need to decide within the implementation project, if the< accept the products suggestion for the appearance of fields or if less or more fields should not appear/appear in the bank-to-corporate messages.

Scource: Category 7 Interbank Message Field Removal Guidelines (as per Score MT Implemenation Guideline, chapter 1.5: ““When an actual interbank MT, sent or received, is included in an MT 798 flow and sent to a corporate, certain fields that are specific to the bank-to-bank communication and have no relevance to the corporate, may be removed.””

In particular (but not exhaustively): Score and DTA

72Z: Sender to Receiver Information
49H: Special Payment Conditions for Bank only
78: Instructions to the Paying/Accepting/Negotiating Bank
Bank Accounts
Bank Charges
23X File Identification
… tbd by bank…
… tbd by bank …
Notifications about bank-to-bank-counter-guarantees

Swift Score MT781 "Settlement of Guarantee / Standby Letter of Credit claim for payment and/or charges"

MT 781 had been revised. There are several changes in the definition of the codewords. As before DOKA supports the usage of Swift/Score codes, based on the entry in the FEE settings. If no specific code is defined there, DOKA will use as 'fallback' the code /COMM/. To Do for banks:

Banks shall check their usage of codes for the Guarantee code. Usually the FEE itself starts with GIxxx, but it can differ, depending on the general FEE setup.
Note: This applies only for guarantee fees. Therefore, commonly used FEEs are not effected and shall be changed carefully.

Bolero:

Bolero - same as above

plus

Bolero - Import L/C: Beneficiary Reference
Bolero: … tbd by bank …

DNG and CTF: All fields are developed inside the source code. The client needs to be informed that hat should check and verify the DNG product suggestion. The usaage in outgoing communication can easily optend out or in, but must be made by Surecomp staff.