Tuesday, October 02, 2018

Making SWIFT changes

While browsing through the wide world of the web, I chanced upon several documents released by SWIFT over the last couple of years. One of the documents that I was happy to locate, and read from the first page to the last, was called “SWIFT Standards - Category 7 - Documentary Credits and Guarantees - For Standards MT November 2018-2019. Message Reference Guide. Advance information”. The document was dated 26 February 2016. Just what I’d love to preserve and have ready at hand on my computer. Of course, I read the document with considerable interest. My reaction, observations or suggestions, call it as you may, are based on this document and are as follows:

The first point I wish to draw the attention of SWIFT to, and my pet grouse, is with regard to MT700 Fields 31D and 41a. I had written about it before. Nothing has happened, not yet; there’s no reaction from SWIFT. I am still hoping that SWIFT, in its wisdom, will some day respond in a positive manner, and agree to delete “…and Place of Expiry” from its definition of Field 31D. The requirement to mention “place” here is a duplication and should have been dropped long ago, for Field 41a serves the purpose with regard to ‘place where LC is available’ quite nicely. The unwarranted definition of MT700 Field 31D continues to cause unnecessary confusion. My blog, https://rnbose.blogspot.com/2017/09/availability-and-expiry-under-article-6.html, will convince you of the reasons why I want the definition of Field 31D modified immediately.

The next issue is with regard to the placement of Incoterms rules in MT700. The ‘Definition’ against Field 45A states, “This field contains a description of the goods and/or services”. The “Usage rules” that follows stipulates that, “Terms such as FOB, CIF, etc. should be specified in this field.”

More often than not, the required Incoterms rule is placed immediately after the amount (e.g. USD50,000 CIF Singapore Incoterms 2010). So, why not append the chosen Incoterm rule to the amount under Fields 32B or 39B? Wouldn’t that make more sense?

My next point is about “Format Specifications”. The column titled “Status” (say, in MT700) displays choices limited to M (=Mandatory) or O (=Optional). The footnote too reiterates this. However, against “Presence” under “Field Specifications” the requirement is stated to be M, O or one of the four “C”s. Incidentally, the “MT 700 Network Validated Rules” provides four variations for ‘C’ viz., C1, C2, C3 and C4 (interpretations provided in the SWIFT document). Why this anomaly? In my opinion, the ‘Status’ column – instead of limiting itself to, and erroneously mentioning throughout the SWIFT documents, only M or O – should be modified to reflect the actual options accurately. In other words, wherever the “Status” is for any of the Cs – C1 to C4 – to be applied, this Field should display accordingly.

Those who are familiar with the ICC document UCP 500 may remember the completely illogical, ungrammatical and arbitrary use of capitalization throughout that document. It was frustrating. This was corrected in UCP 600. SWIFT, however, appears to continue to suffer from the same malady even to this day. All over the document one would find words starting with capital letters anywhere, everywhere, often mid-sentence, for no rhyme or reason, English grammar be damned! Check the narrations under ‘MT Name’ or ‘Field Name’ and you will forget what you learnt at school.

Finally, a brief suggestion about ‘MT 707 Amendment to a Documentary Credit’. Fields 33B and 39C are about “Increase of Documentary Credit Amount” and “Decrease of Documentary Credit Amount” respectively. While this is OK as far as it goes, I would have preferred a somewhat expanded format that went something like the one below:
  • Increase/decrease: from amount -
  • Increase/decrease: by amount -
  • Increase/decrease: to amount -
  • Original amount:
  • Amount increased/decreased by:
  • Amended amount:
The presence of the information in the above format in an amendment advice would help to ensure continuity and accuracy, especially where amounts were concerned. If the beneficiary missed an amendment, he would be alerted immediately. The above would also give completeness to the message, especially where amount was concerned.

Incidentally, could someone please explain why certain alpha-suffixes - like in 31D, 47A, 43P, 42P, 44A, 45A, 49G, 49H, 71D etc. – are in capital, but the likes of 41a, 53a, 57a, 58a have their suffixes in small type? If there is some deep significance attached to it, I would love to be enlightened.

And, by the way, any overwhelming reason why the European way of marking decimals (comma instead of a decimal point) should be imposed on the rest of the world? I should think that ‘decimal points’ are there to denote decimals, aren’t they?

The note contained on the title page is encouraging. It says, “This document contains advance information on the Category 7 Documentary Credits and Guarantees which is due for release in 2018 and 2019. The messages are still under review and changes are likely to take place.” It also states that, “The final documentation will be available in December 2017, when the Standards Release Guide 2018 is published.” I do not have the final documentation in my hands. But I hope that the necessary improvement as outlined above have been carried out. If not, I sincerely hope those at SWIFT HQ responsible for the revision of message standards will take a close look at the foregoing and do the needful.

No comments:

Post a comment