Previous Post: The Basics Of SWIFT MT798 || :Next Post
The Following Blog Post Was Made On:
My Own SWIFT MT700 Parser And Some More Stories
In my last post, I discussed how MT798 message flows between bank and corporate and how the MT798 structure differs from a bank to bank swift message (e.g. MT700 etc.). Today I will focus on the more technical details and FileAct protocol.
When I was in bank, I used to think swift server (at the bank) as an encrypted one that no one but SWIFT can read. I used to think; if somehow, I can open that database, I could generate a lot of reports. What I failed to realize at that time, is that, the SWIFT server is not a database. It's merely an ftp folder where you put the message in plain .txt file. You can actually read it in notepad. If anything was encrypted, that was my bank's trade finance module.
So, the basic process of sending message is; we place a plain text file (with all those crazy swift tags!) into the outgoing folder, swift pickup that file, does some validation and places a similar text file in the incoming folder of the recipient. The recipient's internal software then parses that coded file and gives a meaningful message. That's pretty much it.
It's so simple that I designed my own crude MT700 parser. If you download this text file (which is actually a swift LC message) and upload it to the following link, it will parse all the data. You can try your own MT700 file and let me know how it worked :).
SWIFT Message Parser
Another thing that bothered me a lot at that time was the validation. The software I was using at that time, often gave error that there an error in a particular field. But it didnt mention what was the actual error. If the field was a multiline field, it was nightmare to find the error. But it was not swifts fault. It was the software we were using.
When we actually transmit the bank to bank message, swift again performs that same validation and gives us the ACK / NACK feedback. That means, even if you decide to discard your crappy software, like the one I used, and create the .txt file in notepad, you still need to follow the swift standard. Otherwise it won't be transmitted.
But this is not true for MT798 series. In MT798 series, swift does not validate the message against the swift standard. That means, if your software does not validate, you can send pretty much anything. Now I don't know why it's like that. But it does come with some opportunities; i.e. you can define your own fields. For example, if you want to have dedicated field for country of origin, all you have to do is to put a new tag (say :C75:Canada) into your message and send it. Your counterpart will also receive it as ":C75:Canada". If they teach their system to read C75 as country of origin, then in their software, it would appear as "Country of Origin: Canada". The catch is, both sender and receiver must agree that :C75: = country of origin.
But it is not always as simple as it sounds. Because, configuring any system to read and write a custom tag (e.g. :C75:) requires time and money. So, in most cases, we stick to the standard.
Another important utility on swift network is the fileact. It's like an email attachment but sent over swift network. Files could be of almost any format or size and could be up to hundreds of MB. Here is a example of its uses -
Say I am applying for a letter of credit. I don't want to retype all the data from the proforma invoice. So, in the MT798 application, I will key in only the basic data and then in the attachment field, I will mention the file name I will be sending as the attachment. When the bank's system receives the MT798 application, it will know that there is a file coming from the same sender with xxxx name. when the system receives that file, it will tag the file to the original application and together they will appear on the monitor of the banker.
That's MT798 in a nutshell. When I first heard about this couple of years back, I was quite excited. But, today, witnessing what's going on around, I know for sure, this is not the future. What is the future? I don't know. But I know what might be the possible future. I will discuss this in the next post.
Regards
Shahriar