| No. | Field | Field name | Field DOKA | Question | Answer | Comment |
|---|---|---|---|---|---|---|
| 1 | 43P | Partial Shipments | SHPPAR / SHPPARS18 | How does it work for the old contracts after activating Swift2018? | There will be a new field “SHPPARS18” (visible) next to the old one “SHPPAR” (invisible) and the logic is if “SHPPARS18” is empty it looks for “SHPPAR” and check if it is filled, then if the content matches the new fields codes then it copies it, otherwise it shows it as conditional with hint for the content of the “SHPPAR” | P.S. 1-No need for migration, 2- if “Conditional” has been chosen a warning will appear to ask adding the details in the LC, only in the transactions “LITOPN”, “LITPOP”, “LETNOT” AND “LTTOPN” |
| 2 | 43T | Transhipment | SHPTRS / SHPTRSS18 | How does it work for the old contracts after activating Swift2018? | SAME LOGIC AS IN QUESTION 1 | P.S. 1-No need for migration, 2- if “Conditional” has been chosen a warning will appear to ask adding the details in the LC, only in the transactions “LITOPN”, “LITPOP”, “LETNOT” AND “LTTOPN” |
| 3 | 121 (UETR) | Unique-end-to-end-reference in MT1xx & MT2xx | When will we be able to test the headers for MT1xx & MT2xx | Outgoing: When outgoing payment messages are created in DOKA (MT103, 103STP, 103Remit, 202, 202COV, 205 und 205COV), that will create UUID (systdt.tduuid) and use the UUID in all payment messages for the current transaction in SWIFT Header 3 Tag :121: . No Prettyprint integration. If Banks want to forward the UETR (UUID No.) to their customers, this can be requested and build as an additional service in the banks overlay. See dngdev.001273. Incoming: As Doka usually does not handle incoming payment messages there is no standard mapping (SWH). Bank can create and decide for their own mapping. +Recommendation on an individual SWH for 121/UETR is to 'ignore' it. In a pretty print, this UETR will be visible. | ||
| 4 | How will Doka deal with old contracts after changing the amount with tolerance for all business sectors.(LI, LE,LT,RM)? | There are no changes in the tolerance, tag 39a remains the same. But tag 39B with the code 'not exceeding' will not be supported in SWIFT 2018. In the amendment transaction it will not be possible to select an “amount specification”. Tag 39B is not part of the amendment message any more. | ||||
| 5 | How will old amendments be illustrated? | The narrative of old amendments will still be displayed in field “historic overview of amendments” when processing an amendment with SWIFT 2018. Amendments that were processed before SWIFT 2018 for the fields “goods description”, “documents required” and “additional conditions” are displayed in the respective panels as “historic amendment”. | ||||
| 6 | How will new amendments understand the old ones (in terms of content)? | All the information about previous amendments are available in the “historic amendment” fields when processing an amendment transaction. If necessary, the contract data of the fields “goods description”, “documents required” and “additional conditions” can be updated by setting the checkbox “Modify Text Internally”. This will enable the respective field and allow the user to update the content of the contract field with data of the “historic amendment” field. | ||||
| 7 | How should content of a previously filled field be deleted? | As empty fields cannot be sent, one option is to change this with an MT799 or not recommend, to fill the delete-information in fields 48 or 72z | ||||
| 8 | How to deal with incoming MT744? | The SWIFT MT744 (Notice of Non-Conforming Reimbursement) can be routed to the common messages transactions. There it is possible to select the MT744 as “Related MT”. No further mapping is provided for the message. | ||||
| 9 | How to generate outgoing MT744? | MT744 is generated in the transaction RCTCAN. The checkbox “send a message” must be checked along with filling the fields “Reason for non payment” and “Disposal Claim” | ||||
| 10 | What handling is planned for the new MT759, both incoming and outgoing? | All MT 759 will be handled in common messages transaction xxxFRE. In outgoing, after selecting the message type 'Ancillary Trade Structured Msg' | it is important to understand Swift Network Validated Rules C1 | |||
| 11 | 48 | Presentation Period | PREPER18 and PREPERTXTS18 | How to change an old content? | After SR2018 active: The previous content will be shown on the “Amendment” panel on the left side. In case of days after shipment, only the number of days will be sufficient. Otherwise a clause up to 35 characters can specify details. Before SR2018 active, “Amendment” panel will show old content and modified content has to be stated, as before,on the “Details” panel. | |
| 12 | 39B | Maximum Credit Amount | LIDGRP/CBS/MAX | How will DOKA deal with contracts, those are “Not Exceeding” after activating release 2018? | ||
| 13 | 71N | Amendment Charge Payable By | TRNCHATO and SWIADD\TRANFEETXT | How will DOKA deal with the new field 71N? | In the transactions xxxAME or xxxRAM in the Panels “Amendment” or “Request of Amendment” there is a new field TRNCHATO labeled “Amendm. charge by” with a list of the options “Beneficiary, Applicant, or Other”. Those will be mapped to MT707 F.71N as per Swift coding. Using this field, effects only the current amendment but not other ones. Genera changes of charges conditions for the L/C have to be made in field CHATO = 71D. Note: Specification descriptions differ between Interbank and other channels/formats. Swift Interbank says 'Amendment charge', others mention “amendment charges or charges arrangement”. Currently the Doka products switches the charges of the current amendment transaction, not only standard charge LIFAME. | if “Other” has been selected, a new field SWIADD\TRANFEETXT will be shown below the field on the panel named “Details for Charges” for Narrative. |
| 14 | character '*' various block fields | e.g. goods descriptions, additional conditions, documents required | How will DOKA handle the character '*'(Asterisk) in future? | Please refer to explanation below | ||
| 15 | 49H | Special Payment Conditions for Beneficiary | SPCBEN | The purpose of this field is not described suffiently in the Swift User Handbook. More info required. | One additional scenario from Swift: ““If Beneficiary seeks financing, and as the Applicant pays all the charges, there can be conditions set by the Issuing bank for financing in 49H.”” | |
| 16 | MT719 | Question from Enrico/DZB: To which transaction is this message routed? | ||||
| 17 | 58a in MT770 | Swift Interbank = Requested Confirmation Bank Score = Advising Bank | Why is field 58a in unmapped for an incoming MT770? | For MT770 there is an inconsistency in Score. The Index part of an MT770 uses 58a for optional Advising Bank and in the main MT770/700 body field 58a is also optional for Requested Confirmation Bank. There is the Score-Guideline “GUID: this field should not be used by the Applicant except if there is specific requirement to have the credit confirmed by this party”, but technically the sender/applicant can use this field twice. Therefore, it must be manually decided, if the 58a is used correctly by the sender. | ||
| 18 | 72Z in MT707 Interbank | Sender-to-Receiver Information | ADDSTR | Why is this field filled by default with a “.” dot? | The dot is in field 72Z of an LITAME/LITRAM/LITAMR on purpose. If you would like to stay with this option, please close this ticket. If we shall remove the “dot” which might, in rare cases, could cause a NAK, please let us know. Reason: Swift Network Validation Rule C2 for MT707 says “At least one field must be present after field 22A”. This avoids NAKs when sending an MT707 without changes. Implementing this C2 was much to complicated. Therefore, we decided for that workaround.Opt | Possible comment: If you would like to stay with this option, please close this ticket. If we shall remove the “dot” which might, in rare cases, could cause a NAK, please let us know. |
| 19 | 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 MT 707 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 LETRAM. | |
| 20 | 23X in MT759 | File Identification | Non visible field. | Field 23X is mandatory for FileAct attachements with MT759. 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 needed. 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. | |
| 21 | 45A / 45B, 46A / 46B, 47A /47B, 49G / 49M, 49H / 49N | div. | div. | The field(s) are not splitted after 100 lines, but earlier. Why? | At first DOKA needs to check the 10.000 character rule. In case a single message exceeds the maximum quantitiy of characters, those fields which can be splitted earlier and DOKA will do so. There is no rule saying, it must be 100 line before this field should appear again in another consecutive (701/708/711/721) message. Or to say it otherwise. As much content as possible will appear in each message before the next message will be used. | |
| 22 | 23H | Funtion of Message (MT759 / Bolero 4881) | TAG23H | How can a user identifiy and select the correct code per electronic channel? E.g. there are specific DTA and Bolero code. | See DNGDEV.001880 and under https://surecomp1072547.sharepoint.com/:x:/g/GlobalDelivery/Legislation/EeT22XE1M9pJj4WoAOOkdcwBN-Gem96x4caPAl4bTFXqzg?e=dKz1lW | |
In the past and still so at the moment, the character ‘*’ is used throughout DOKA as a character to mark text module names and as place holder in text modules where free text shall be entered manually by the user (e.g. ‘packing list in *-fold’ where the * shall be replaced by a valid number).
Now with SWIFT 2018 the * may get part of normal text asit is allowed as character in fields using the SWIFT character set ‘Z’.
As there are many usages in text modules in the existing customer databases and the users are used to handle the * we decided _not_ to change the usage of that character in the product version of DOKA at the moment.
The typical arguments of customer to change the * to a different character are, if we need to forward the original unchanged text (which now may hold a *) how can we do that.
Our answer and our solution is as follows:
1. The original field of the incoming message is available and if it is needed to quote the original message, this is possible by using the original field. This has the positive side effect, that this field has not passed through any editable field, where user may intentional or not intentional changed something.
2. The blocking and text module calling functionality of the * character is configurable and might be switched off on level 5 rules. Thus if a customer wants to be able to switch this function off he is able to do that. Thus only in input fields where text modules shall be used the special text module identification character has his meaning.
3. The character used to identify text module references is defined in TXSMOD in the Rule GetTxmRefChr. Thus if the customer wants to a. Change the text module character b. Update all defined text modules c. Retrain all his users then this can be simple implemented by changing this character. We do_ not_recommend to do that.
The customer should be aware that the change described in 3. will create significant internal inner departmental workload. For the product we think that due to 1. and 2. we stay with the current implementation and usage of the * as text module identification character.
We will implement an extension to TradeDesign to allow the redefinition of the special stop character (where currently “*” is used). In TradeDesign this character leads to an automated positioning of the cursor to that character to easily replace the character with manual input.
When the TradeDesign enhancement will be available, the Rule in TXSMOD will default wise use the special character as defined in TDPARA (or stay with “*” if nothing is defined).
Relevant for:
To do:
Scource:
““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
Bolero:
plus
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.
“Definition: Identification of the electronic address where the electronic presentation must be done.”
By default COR-TF and DOKA are using the <boleroRID> of the Issuing Bank. Optional change on sourcecode level 5: Instead of the BoleroRID of the Issuing bank this default can be changed to different defaulted BoleroRID or a specified email-address.
With activation of SR2018 the defaulted latest EUCP Version will be Version 1.1. Before that it is Version 1.0.
Changing the default can be handled under CTF level 5.
Becoming live in November 2019. DOKA incoming Guarantee-Interbank MT759 have to be manually converted to DOKA-to-Bolero outgoing message 488.
Quoting Bolero
““4882: This will be introduced in 2019 when we update our document types for the SWIFT guarantees release. Until then the 488 should be used for guarantees. Structure of 4882 will be very similar to 4881.””
Doka developer guides for Swift 2018 are here Swift Release 2018
Swift 2018 release guides:
Overview about existing specifications for
Official Swift timeline with links https://www.swift.com/standards/standards-releases/mt-release-2018