SWIFT (Society for Worldwide Interbank Financial Telecommunication) is one of widely accepted way to do financial transaction between financial institutions. It has over 8,300 banking organizations, securities institutions and corporate customers in more
than 208 countries.
If you look at the SWIFT evolution in the market they cover overall market in financial institutions; from securities to cash to treasury, etc. And all of these communities have one common problem – Integration Problem.
They are many large financial institutions and many of those are aware of those problems. The middleware project/implementation that they have been running – most of the projects they have is to do message validation of the messaging platform and are big
project that goes long and are risky. They also have problem to find right expertise for that. Even after years, if you ask them today, they are still working on standardization and getting to a more stable system.
In the ever increasing competitive market when everyone is trying do cost cutting, many banks have already started using SWIFT standards for there processing outside SWIFT Network (mostly for their internal branches). They also need to make available SWIFT
interfaces for many legacy line of business applications, which is another challenge.
Many major banks are still relying on their legacy systems for validation and processing SWIFT and other messaging standards. SWIFT and other messaging related IT cost is one of major issues. What would you do if your regulators required you to implement
a new standard?
One of very common, major and important activity at all financial institution carry our every year is updating their systems with new messaging standards (SWIFT, SIC, SECOM, etc). Many do these updates with help of their in-house IT teams whereas many take
help from various service providers. In both cases, doing updates every year remains a pain point. It is a challenge to keep your existing systems updated at the same time when you expand you operations; you will have to start supporting new standards. Interestingly,
SWIFT software and hardware becomes legacy the day it is installed. You don’t want to touch them from the day it is implemented!
We will see these problems growing more with time because most messaging standards and still evolving especially SWIFT.
SWIFT have already announced that they are moving towards XML based SWIFT messages (ISO 20022) from their existing MT (ISO 15022) messages. Technically, it will be easier to handle XML based messages but will still be one major upgrade for existing
system that processes MT messages. What do you do in such situations? This is not the end of it. We will see such major changes in future as well..!
An ideal solution for above problem spaces would need:
· Adaptability: No matter what technologies you use but it is extremely important how adaptable your system is.
· Expandable, extensible system: you would want to work with existing standards but the platform should also be extensible when it comes to support new once.
Microsoft's BizTalk Server 2004/2006 and its Financial Accelerator for SWIFT can provide seamless solution to process SWIFT messages. Many
banks have already started using BizTalk Server for this requirement. Finextra News has
Italian Bank and
KAS Bank in its list. BizTalk Server also help you to tackle other integration requirements.
Click here to see a typical
diagram to show how BizTalk and A4SWIFT solution would look like.
P.S. A4SWIFT is not replacing SWIFTAlliance Access (SAA) or any of SWIFT software. It is a complementary solution to SAA or the SWIFT gateway.
About me: I do not represent or work for Microsoft in any form. I have worked with multiple messaging products and have been involved in evaluation of products that can process SWIFT messages. Purpose of this post is to share my thoughts and findings.