Financial Information Systems

Integration

The goal of all this technology is to allow automated straight-through processing of all transaction-related messages thus reducing time, costs, errors and risk while increasing security. Ultimately the unbroken chain of automated message handling will include bid/offers, transaction initiation (maybe directly by customers), risk management, settlement, confirmation, accounting, reporting and cash management.

Increasingly, processing of transactions amongst and between institutions and customers will involve direct connection of their systems with internal systems. Messaging Middleware will be the glue that holds it all together.

As a rule of thumb, licensing for the software accounts for approximately 50% of the total cost of ownership. Thus, serious consideration should be given to peripheral investments to cover management, configuration, training and maintenance of the applications.

The ability to perform such tasks with minimal effort should mitigate towards a particular solution based upon the in-house expertise of a financial institution that wish to deploy a new messaging solution.

A survey based upon SWIFT Solutions directory shows around 80 potential solutions that can support messaging middleware to a greater or lesser extent. Many of these solutions provide specific functionality such as SWIFT Access Gateway. Others offer a fully integrated solution with many other inter-related functions. Only solutions that support all SWIFT message types are considered for inclusion in the tables on the basis that Payments, Treasury and Securities are a pre-requisite for any Message Middleware solution in order to support typical financial institutions product offerings. This reduces the number to around 50 applications.

In order to make sense of what is available, the solutions have been categorised based upon what operating system they support. This is usually an important selection criterion to facilitate integration with other related applications, e.g. back-office systems. Further, in order to provide some indication as to the scope of functionality offered by each —solution“ the key messaging functions have been identified (by S.W.I.F.T.) and the vendors were asked to indicate if their solutions supported such functionality.

In 2004 there were a total of 8 Windows XP solutions. All are common to generic Windows environments. There were a total of 10 HP-UX solutions.

As integration technology matures, it can be expected that the marketing of EAI message middleware from the vendor community to converge around many of the same business themes. Selecting an integration provider will be nearly impossible based solely on a request for proposal (RFP). Due diligence also requires a successful proof-of-concept (POC) to test a vendor‘s capability beyond its sales and marketing abilities. The vendor‘s domain expertise for standardised messaging, how independently a vendor can operate, and the timeframes with which it can complete the test are all key components of the POC. Once the vendor has sold its software and moved on to the next customer, the availability and cost of developers with the incumbent skills to configure and maintain the integration components will determine the total cost of ownership, and ultimately the ROI.

Evaluating EAI solutions is a complex proposition that must consider the balance between the vendor‘s grasp of the business process within financial services and the technical capabilities of the software. In the marketplace today there is often an inherent tradeoff between these two points of differentiation. Vendors with a strong focus on financial services generally have an older or more proprietary messaging architecture, while vendors with a better technical architecture often lack the domain expertise and configured adapters needed for financial services. When it comes to selecting a player, it‘s not a matter of which vendor is better but which one is more appropriate, once the skills, project scope, and specific requirements of the institution are considered.