Back to all announcements

Using an ASP: A Sound Policy or Risky Venture?

Speed of products to market and cutting costs are two of the features driving banks to using Application Service Providers (ASPs). TCA Consulting's Stewart Bell discusses both the drivers and challenges banks need to consider when looking for an ASP partner.

The growth of the global market for ASPs over the next few years is expected to be rapid. Whereas in 1999 the market was worth around US$1 billion, a recent survey by Ovum predicts an increase to US$136 billion by 2006. Banks of course form only a part of this overall market, but they too are expected to take up ASPs in increasing numbers.

The ASP model
With the promise of remotely supported and managed applications delivered over a network onto client desktops and financed on a pay as you go basis, ASPs are a service that banks are becoming increasingly interested in using. The advantages that an ASP can offer appear clear-cut. Using them can leave the client free to concentrate on their core competencies and refocus internal IT departments away from simply supporting applications and towards adding real value to the business. The use of ASPs can reduce the one-off costs associated with traditional system installations: packaged ASP solutions require less expenditure on hardware and offer shorter implementation timescales. The latter reduces the time to market and consequently enables business benefits to be realised earlier. Running-costs may also be lower, with less need for dedicated in-house support and lower maintenance costs.

The cost characteristics of the ASP model enable banks to both reduce their upfront capital commitments and at the same time predict more accurately their future budgetary requirements for systems expenditure, smoothing the economic profile over time. The technical freedom afforded by ASPs gives banks the opportunity to run with new technology that previously may not have been supportable internally. The ASP can also often provide a range and sophistication of functionality that internal expertise simply could not match, such as advanced pricing models or industry leading portfolio-wide risk tools and analytics.

The potential benefits of taking up the services of an ASP are thus clear. However, not all in the garden is rosy. The decision to incorporate an ASP into a bank's overall IT architecture is not a straightforward one as there are several important barriers and risks to implementation as well as potential benefits. Perhaps the most significant challenge is the integration of the ASP service with the bank's legacy systems - for example, linking a trade capture and risk management ASP into the settlement and general ledger systems. Selecting an ASP that supports a suitable messaging standard will also be a key decision as will deciding on the type of interface or middleware to adopt.

Another important consideration is speed. The response time and performance throughput of an ASP's connections via the Internet and the ASP host servers must be sufficient to handle the bank’s peak demands. Indeed, if a number of banks are sharing the services of a single ASP, the ability of each bank to participate in the market in an effective and controlled manner may be most threatened during periods of high activity or market crisis. There are further considerable concerns. For example, the dependency of the client on the ASP puts it in a potentially precarious position - especially if the ASP fails to provide near complete up time, or, even more drastically, if it goes out of business.

Hidden Dangers and Poison Asps
The use of an ASP, as with any other new IT, may raise security fears within organisations about the safety of data from external tampering - even though they can actually reduce the opportunity for the more common type of security breach, internal fraud. Similarly, there is currently some debate on the suitability of using the Internet as a medium for secure and reliable transfer of business critical data. Some ASPs have suggested that the only truly reliable solution is to install a bespoke network on the client site and link it directly with the ASP. Although clearly more robust, the increased cost of this solution may dissuade all but the largest banks - reducing the size of the target market by relegating second and third tier banks. Other barriers to the decision to take up the services of an ASP include the difficulty of drawing up watertight service level agreements. There can be no room for ambiguity when the client is wholly dependent upon the service and support provided by the ASP. It is first necessary for the bank to understand and accurately measure its own requirements, scope and capacity before agreeing to any ASP's interpretation.

A further challenge is deciding on the type of ASP that provides best value for money. Since there is no common pricing policy, organisations have to make complex decisions on what form of charging would best suit them, whether that be cost per transaction, database size required or some other parameter. All this makes the cost-benefit analysis involved in assessing the benefits of the ASP versus the traditional install, or self-developed application extremely complex and one for which the jury is still divided.

The future of ASPs within the banking sector depends on how many financial institutions decide that the cost benefits and convenience of using an ASP outweighs the potential risks and problems. ASPs will only continue to grow by adding new functionality and supporting changing market and regulatory requirements - compliance with the FAS 133 requirements on derivative hedging accounting is a timely example of such a challenge. Some ASPs may thrive by partnering others in their search for the best application. However, not all will succeed: many will fall by the wayside as clients seeking more functionality and cost-savings switch from one ASP to another, ironically with greater ease than they could previously with an installed system. The question remaining is what models of ASP look set to succeed?

The Choices
Despite the multiplicity of ASP vendors in the banking sector - there are close to 100 - and the claims of each to offer a unique suite of functionality or a differentiating feature, the reality is that the majority of ASPs can be put into one of four categories. The distinct business models of each are a pointer to their chances of success.

- The first and largest category is the ASP offered by re-invented software vendors that have 'web-enabled' a traditional install product. Such a vendor utilises its market experience and client relationship expertise, but the technical design of the product needs to be fully examined to ensure its architecture is truly scalable. Products originally designed with a component based architecture requiring only a minimal install on the desktop PC are more suitable as ASPs. Similarly, systems capable of supporting multiple legal entities are also at an advantage.

- Internal bank processes that are spun off as commercial enterprises or value-added services form the second ASP category. Although perhaps functionally suitable, the cultural challenges faced by externalising a previously internal function and making it client facing cannot be underestimated. The success of these ASPs may depend more on their success at managing client relationships and sales and marketing than the solving of the technical challenges. Although few in number at present, this is a model that investment banks are increasingly evaluating with a view to either using or emulating themselves. Additionally, there are signs that specialist ASP start-ups, some with full banking licenses, are about to hit the market.

- Partnerships of like minded banks and software vendors, pulling their technical and business resources together, form the third category. Although this model can allow the partners access to a ready made market share, the rival motivations and competing objectives of the previously competing members need to be harmonised to ensure a competitive and viable ASP offering. Managing the conflicting priorities of different partners - perhaps over instrument coverage or release cycles - will require strong and independent leadership if the internal wrangling is not to result in missed opportunities and disenfranchised clients.

- The final ASP category are 'enablers' who typically provide the technical platform and tools to facilitate others in delivering an ASP offering. This offers a faster route to ASP delivery for those wishing to compete in the market, but the rival technical architectures need to be compared. The level to which a client using the enabler can differentiate their products and dynamically meet the changing requirements of the market place also needs to be fully assessed.

Selecting the right ASP from the wide range competing for investment banking budgets involves a careful evaluation of the bank's current and future requirements and then an appraisal of the ASP’s ability to meet them. Speed, security, dependency, integration, service level agreements, and assessment of the buy / rent equation are all key aspects that must be fully explored before a preferred ASP can be chosen for any specific business area. However, the work involved in the evaluation process could bring impressive dividends as the advantages offered by ASPs are realised. The central factor that will separate the winners from the losers among the various models will be their capacity to deliver secure functionality to the level demanded and their ability to react quickly to meet their clients’ new and increasing requirements.

Author: Stewart Bell (TCA Consulting Ltd.)
Publication: Conspectus