Blog article
See all stories ยป

Unique Client Identifiers and SWIFT

As the financial markets veer reluctantly towards reconstruction (mainly because of political objectives) the major obstacle the industry has of "identity standards" looms like an ogre. The lack of standard industry identifiers at fund account client level has been a long standing problem. It has been debated for decades within all market sectors with no hope of a solution being implemented. However, the time is nigh, when like it or not the finance industry must agree a solution, be resolute on its design, make definite implementation plans and most importantly tell the market what it is. Anything less, will be like a large threatening cloud over the political objective of "a single European market"   and the potential of creating a truly efficient, cost effective industry, with a high percentage of industry wide straight-through-processing (STP), will remain a forlorn hope, rather than an anticipated result.

When this subject arises in either the payments or securities markets, SWIFT is normally embedded as a large part of the solution. However, this is always a one sided view by the banks, rather than that of the corporate and retail market investors. The vast majority of the world's financial activity does not go over the SWIFT network. A visualisation of global financial services messages would show a massive series of unconnected networks (some large commercial and others proprietary), as financial services (FS) firms have chosen the network best suited for their business, with the Internet as the growing common denominator between them and their clients.

The FS firm has to cope with all these connectivity issues in an attempt to achieve STP and will continually fall a long way short of true STP. The integration capability developed within banks own systems, can achieve a certain STP capability within their own processes, but will never get sight of the "Holy Grail" of industry-wide STP. Surely this must be the aim!

Within the wholesale banking community, many have created what looks like a connectivity hub of a number of networks, which are used by their clients, offering better services to their customers, as a result of which they have made significant operational gains. Should SWIFT copy this model and become a hub of networks? That looks like another Blog!

The wholesale markets visualisation is to extend SWIFT connectivity to the mass of financial clients that are currently outside the SWIFT network, however; unlike the retail market, it will already have some type of integration software translating inbound counterparty/client electronic message into ISO15022. If electronic standards like ISO15022 can bring the advantages it has already proved, then why not simply use this same thought to bring forth an ISO Unique Identifier. It would be network neutral like ISO15022 and allow freedom of choice of networks, by both wholesale and retail markets. Networks would compete commercially and by value added services.

To give SWIFT its due, it has been working hard to create a commercial and technology solution attractive to non banks. The problem with this strategy is the time it will take to get the lion's share of non banks onto the network. I am not sure the industry can wait this long.

The SWIFT solution also demands that clients change their processing and/or invest in new technology and this is a big repellent for the buy side. A previous example of this in the securities market was GSTPA. One of the biggest development disasters of recent times, that dwarfed TAURUS in its cost for those foolish enough to invested in systems.

The problem with GSTPA was it was designed as a solution for the wholesale market, which relied on their clients input and volume. Unfortunately the GSTPA design required investment by clients who were totally unwilling to change or undertake systems development and subsequently although the GSTPA solution looked good on paper it failed totally. So any industry solution to build interconnectivity and gain industry wide STP has to be controlled within the markets and should not involve any significant costs or changes to the retail investor. This goes for payments as well as securities. With this in mind the industry-wide solution for STP is narrowed to a few logical possibilities and accepted global standards feature very high.

If the finance industry could agree a new unique electronic identifier at client level the possibility of network interoperability would become a possibility within the technical architecture of both the wholesale and retail markets. SWIFT would not be a part of the solution but would remain in their existing position.

SWIFT is vulnerable long term unless it opens up its network to interoperability to other networks. Although much of the industry knowledge resides within SWIFT from a wide industry perspective it is politically sensitive. SWIFT should not be presented as a single solution provider to non SWIFT customers if a final answer to this problem is to be found. A unique client identifier therefore should not include BIC numbers but be a new completely new design. Matching the old with the new would be too difficult and expensive and creates too many protectionist arguments. A complete redo would be quicker and cheaper in the long term.

The role of SWIFT has to be redefined; it does have fundamental benefits to the market, but it is also an impediment to finding and implementing an industry solution for a unique client identifier.

IdenTrust has been leading the way, presenting a sensible way forward and creating an acceptable solution for the end clients. It might be time for SWIFT to take a step back, so the industry can take a step forward to finally resolving industry wide STP, putting unique identity codes at the top of the development budget.

Ultimately SWIFT would benefit as traffic would surely explode upon implementation of a unique identity library. But can SWIFT be big enough to take a step back? History says otherwise and this might lead to yet another political directive and don't we have too many of those already!     

 

 

 

5252

Comments: (1)

A Finextra member
A Finextra member 05 March, 2008, 08:14Be the first to give this comment the thumbs up 0 likes

Hi Gary,

a nice blog post concerning this subject is on swiftcommunity.net. I has been written by Jean-Marie Eloy, from SWIFT Standards department.

 

Now hiring