What does the shift from FIN-based standards to XML-based standards mean for SWIFT users and how are you communicating the change to your network?
DeWeirdt: The old FIN-based standard was created back in 1973 and now lives side by side with our XML standards. These XML standards were put in place to provide richer data and meet more complex business requirements for our users. In order for FIN users and XML users to communicate, we have to provide mapping rules so that whoever is doing the translation from one standard to the next is doing it in the same way, otherwise there might be data lost in the transaction.
Who needs to be educated in these mapping rules?
Everyone in the community, though people are moving at different paces in the adoption of XML. Unlike the migration to the new ISO15022 standards, we are not making the migration to XML a mandatory requirement with a deadline for conversion. Instead users need to make the switch based on their business requirements - driven by a willingness to tap new revenues and expand their businesses. XML is in place and we have developed new messages for customer payments, bulk payments, and cash reporting. In the securities industry, we have started working on pre-trade and managed funds messages. Very few users have implemented XML to date, but we are piloting the standard in closed user groups.
When is full implementation likely and which groups will be the first across the line?
We expect implementation will take from five to 10 years. The first across the line is likely to be the securities industry because this is a field where there is less automation and very few heritage systems in place. Adopting XML will be easier for this crowd. The payments industry, on the other hand, has a lot of heritage systems already in use.
Is Asia ahead of or behind the game?
In Singapore there are people that have already implemented our XML standards such as the Monetary Authority of Singapore. In Australia my colleagues are working closely with the managed funds sector to effect the transition. So, Asia Pacific is definitely not behind the rest of the world. One sector where we see a lot of interest in new standards in this region is in trade finance, which is a market SWIFT is actively pursuing. We are prototyping a trade finance product which we will be revealing at the Sibos conference in Atlanta in October. Essentially, it is a system which allows the matching and reconciliation of purchase orders, invoices and certain transport documents. When we develop the full commercial platform it will cover everything from open account to letters of credit. This is interesting because it is the first time that banks have approached us to simplify how business is done.
What is meant by business modelling methodology when it comes to standards development and why is this practice important?
Business modelling refers to way in which business requirements are captured and turned into concrete standards solutions. An analogy I like to use is Lego blocks: each institution has its own Lego or data objects. Our initiative is to first standardize those data objects and make sure that everyone has the same understanding of the different elements of the business. The second step is to make sure that these data objects fit together and then to draw a model of a message. Once, and only once, this is done should you move to XML or FIN message presentation. In other words, the method of communicating shouldn't drive the standard. The standard should be based on the needs of the business. The reason this is so important is that things like XML may not exist in years to come, but the models will still be there.
Is this the key message you have been passing on to users on your tour of Asia?
Yes, I have been telling people that if they need to do something with their existing infrastructure they should base it on the needs of the business not on hard coding. XML happens to be the technology that we use to represent data currently, but organizations should be syntax independent with systems that are based on the business, not on the standards themselves. This will relieve the headache when it comes to updating their back offices.
How can XML standards translate to cost-savings to the financial services industry?
The only proof we have of cost savings is what has been achieved at SWIFT. XML has a unique capability whereby upgrades and modifications can be deployed without extensive physical handling. They can be injected into a system automatically. This means that the deployment of standards is significantly shortened and any subsequent maintenance is a lot easier. Of course, this requires that the application or system concerned needs to be capable of accepting XML. So while there is an initial investment in moving to XML, any subsequent upgrades can be achieved quite cheaply.
What is happening with the issue of convergence and avoiding the duplication of standards around the world?
This is one of our biggest battles. We don't want to dismiss other standardization bodies, but it would help the financial industry if we had as few standards as possible. The industry would benefit because it would save money on implementation costs. We don't expect everyone to use SWIFT, but of course we are encouraging them to use ISO20022 standards which cover trade finance, securities, payments and treasury. This is XML based. In June this year we signed an MOU with ISO and UN/CEFACT where the three organizations have agreed not to duplicate effort any more. This is a big step forward in terms of convergence.
How do different market practices locally impact the development of universal standards?
Obviously market practices have great potential to cause fragmentation. We have people in our securities division that sit on market practice groups around the world to keep an eye on what practices are being implemented. The first step for these people has been to document the differences but now they are starting to look at ways of harmonizing the practices. We want to keep the market practices variances down to a minimum and make sure that cross border communication remains as generic as possible. We are also encouraging closed user groups in each country where there are specific issues to deal with.
