White Paper www.temenos.

com

Core banking systems for large banks

The packaged solution comes of age

Copyright © 2009, TEMENOS. All rights reserved

page | Contents
1 Executive summary
3 Traditional objections to ‘buy v. build’
6 How to build a business case?
7 Temenos Operational Performance Study (TOPS)
Executive Summary
A CIO of a small bank in Canada recently remarked in public that now may be the best possible time for him to be
working on a core system replacement, because demands from the business have temporarily gone quiet …

McKinsey, in a presentation with the title ‘core banking systems transformation – the packaged solution breakthrough’,
suggests that there may be evidence to show a correlation between the performance of banks and whether they have
successfully implemented new core banking technology – packaged core banking software, to be precise. [see Fig 1]

In a Bank Systems and Technology article, a seasoned industry commentator remarks that ‘small banks typically spend
10 percent of their non-interest expense on technology. Large banks spend 18 percent and more of their non-interest
expense on technology.’

Of course these are only the latest rumblings of a debate that has been going on for some time.

The pressure for larger banks to consider replacing legacy core systems has been increasing as it becomes clear that
traditional ‘surround’ strategies – whereby the worst issues with legacy core banking systems were overcome by
investments in distribution channels – cannot ultimately by themselves deliver the improved agility and cost savings
that the business is looking for. And, IT departments within large retail banking businesses are finding it increasingly
difficult to continue justifying in-house development when their international operations have successfully resorted to
vendor-sourced solutions.

For some banks – like KBC in Belgium for example – the business outside their traditional home base is now larger than
their domestic business, raising questions about an ongoing strategy of building systems in-house which are typically
not flexible enough to accommodate these international activities.

Add to this the growing scarcity of COBOL programmers, as the generation that built these legacy mainframe systems
retires, and it is easy to see why there is an increasing sense of urgency.

The move to off-shore development briefly re-ignited the hope that ongoing in-house development might yet be
possible. However, the reduced cost and increased capacity – once it has been established – does not necessarily
deliver a new architecture or introduce real business innovation such as flexible product definition and its associated
parameterization to enable genuine agility.

Moreover there is a growing consensus in the industry that Service Oriented Architecture (SOA) might provide the
way forward. It holds out the promise of the gradual modernization of core systems, with agility being achieved on the
basis of service orchestration.

As we move from the SOA hype to what Gartner calls ‘the slope of enlightenment’ and maybe eventually to the
‘plateau of productivity’, the real challenges associated with the governance of an SOA environment made up of
components sourced from many different vendors have become apparent, questioning how long a transformation
roadmap – one service at a time – might take. [see Fig 2]

This realization is starting to introduce the notion of a core banking ‘platform’, in other words an environment that puts
in place the basic core banking capabilities quickly – those one might consider ‘commodities’ – and does so in a way
that ensures the necessary compliance with SOA principles and open standards to make future investments focused on
differentiation possible.

So let’s explore for a moment what the way forward may look like.
White Paper 2

Fig. 1 | McKinsey & Company

Hype Cycle for Application Architecture, 2008

Fig. 2 | Gartner
White Paper 3

Traditional objections to ‘buy v. build’

It is probably sensible to start with some of the traditional objections raised by businesses that have always built systems in-house.

Scale
For teams that have typically built their legacy systems on mainframes scalability was for a long time the most obvious cause for
concern. After all, many of the original implementations of core banking packages were for much smaller banks. However, as non-
mainframe platforms have caught up with the traditional mainframe in terms of performance characteristics, but in general at a much
lower total cost of ownership, we have started to see the first instances of larger banks implementing packaged core systems.

A good example of this is the implementation of T24, Temenos’ leading core banking packaged software solution, at Bank of Shanghai –
one of the typical Chinese banks that operates primarily in one city but nevertheless has in excess of 11 million customers on its books.

Other high profile projects with a distinct ‘packaged solution’ focus, such as SAP at Commonwealth Bank of Australia , confirm that
these are no longer isolated cases.

And then of course there are some of the large projects which are loosely based on packaged software with a lot of source code
customization – such as the new Nihon Unisys banking bureau service, a flagship implementation for the Microsoft platform taking on
genuinely mission critical roles.

Similar highly customized projects in emerging markets by some of the leading Indian vendors again confirm that these are not
isolated instances.

Sophistication
It was also held for a long time that the level of sophistication required of a domestic retail core banking system was such that core
banking packages were unlikely to be able to address this sector.

Some vendors have sought to address this concern by making source code available on site and taking the route of least resistance by
introducing massive levels of customization.

Of course the downside to this approach is that a future upgrade to the next release of the product is likely to be more akin to a new
implementation. The scope for ongoing improvements, as a result of the productization of new capabilities which emerge from other
implementations, is often lost with this approach.

By contrast, some vendors have the confidence and experience to show that it is feasible to build core banking software which is so
flexible that it can meet requirements without source code modification, or where the ‘core’ is protected and what customization is
required is achieved through extensions of ‘the platform’. This remains a relatively small ‘club’ of vendors – but it can easily be seen that
this claim is convincing, when one looks for example at the installed base of Temenos T24 and its predecessor Globus – more than 700
banks in 120 countries – and comes to the realization that all of this has been achieved from regular releases of a single code base.

What more and more traditional adherents of the ‘build in-house’ policy have come to understand is that the resulting code is often far
more sophisticated than that which a single country implementation would achieve.

The only banks who have been able to successfully sustain a ‘built in-house’ policy are of course the truly international brands like
Citibank or HSBC, where the sheer number of countries they operate in have often forced similar design constraints on their large
teams of developers. But this just serves to confirm the point about the sophistication of truly productized core banking software. And
how many banks remain that can justify an in-house IT investment on this scale?

Architecture
In larger banking organizations the role of the enterprise/application/technical architect has become more prominent and essential in
order to ensure that IT investment decisions are made in a way that aligns with a future architecture vision of these complex IT environments.

Because the concept of an SOA has gained currency relatively recently, it is easy to see why some architects assume that core banking
systems with a longer track record must, of necessity, have architectures that are unaligned with SOA principles.

However, nothing could be further from the truth.

White Paper 4

The design and cost constraints under which a system like T24 has evolved have long necessitated the notion of re-usable services
which are consistent across many different business domains.

Evidence for this assertion can be found in the fact that Temenos has succeeded in introducing flexible product definition in T24 – based
on the re-use of common ‘component’ services – much earlier than has proven possible for the majority of banks who still operate
legacy in-house core systems.

Also, the need for a highly productized core banking platform like T24 to be integrated in a large variety of different contexts has
meant that the architecture had to accommodate a very disciplined way of interacting with the outside world – a way that would not
endanger the integrity of the system.

And so it should come as no surprise that Temenos was one of the first vendors to introduce fundamental SOA features avant la lettre
in its ‘application gateway’ – upon which it became possible to expose all of the business functions in the T24 platform as ‘services’
described in WSDL (Web Services Definition Language).

What is more the first major implementation of T24 where these services are orchestrated through BPEL – the standard ‘business
process execution language’ is making good progress.

Of course there is another dimension to SOA and one which most architects will recognize as requiring a more gradual approach. This
concerns the ability of core systems to consume services provided by others, as well as expose their own services.

Temenos was a founding member of BIAN – the Banking Industry Architecture Network, together with leading vendors in this space
such as SAP and Sungard. BIAN works in close collaboration with international banking groups like ING, Credit Suisse and Deutsche
Bank on the definition of standardized banking enterprise services.

As BIAN starts to publish services – starting with ‘business partner’ – the vendor community – including Temenos – is getting ready to
consume services …

For a more detailed look at the architecture roadmap of T24 and how this addresses such issues as:

• Multi-channel architecture with both atomic transactions and long-running cross-channel processes;
• User interface composition;
• Workflow, Business Process Management and the use of a Rules Engine for service orchestration;
• Event processing and Business Activity Monitoring;
• Enterprise Service Bus, message-oriented middleware and data transformation;
• Declarative configuration and management instrumentation;
• Governance, including tooling, versioning, monitoring of SLAs;
• Security, reliability, scalability and high availability.
… refer to a forthcoming Temenos white paper.

Control
An oft heard objection concerns the possible loss of control. After all, there is a certain element of unpredictability as to what may need
to be done at short notice and who guarantees that a vendor will be willing, or able, to recognize the priorities of an individual customer.

The reality for many banks is that their IT teams are unable to respond to the business at the speed they demand – because legacy
systems simply cannot be changed at such short notice. They often have product variations or processes ‘baked’ into the source code
and any code change can only be undertaken with due diligence and testing.

By contrast, modern core banking packages have – of necessity – externalized customization capability to such an extent that
many typical requirements like a change in regulatory reporting, the introduction of a new product or a change in a process, can be
accomplished without coding.

In fact, what the best core banking packages do is to take care of those aspects of the bank’s operations which are non-differentiating
and by doing so free up the time of the IT team to respond to the business when it comes to changes which are targeted at competitive
advantage through differentiation.

So in a way – rather than creating an issue over control – they actually empower IT teams and give them a basis for taking control over
that which matters.
White Paper 5

Vendor risk
The relationship with a core banking vendor is often likened to a marriage in that it is important to not just look at the core banking
product today, but also to have a clear perspective on what it will look like in the future – in other words what the product vision and
roadmap look like.

It is an old saying in the industry that many banks will consider the decision to team up with a core banking vendor using similar criteria
to the ones on which one might decide to make a long-term investment or extend a credit line.

Important in that respect is also the extent to which the business model of the vendor delivers the anticipated continuous
improvement to the product.

For example, where the main source of revenue is derived from the services delivered to customize a partially productized offering, this
is unlikely to create the necessary focus on productization of newly added features.

One of the best means of assessing the extent to which a vendor is able to deliver the benefits expected from a long-term relationship
is to see what percentage of its user base operates on the most recent releases – assuming there is a single version in the first place.

In support of the objective of ensuring that as many as possible of its users can benefit from the innovation and R&D investment in
its latest product release, Temenos has recently announced a new feature called T-Verify, which complements the existing off-shore
upgrade service by fully automating the processes associated with a parallel run between the live system and the upgraded version –
including the verification of results. The aim of this new initiative is to make it much easier for banks to achieve an annual upgrade cycle.

Temenos invests around 20% of its revenue in R&D; one of the highest spends as a percentage of revenue in its sector. In 2008
alone, it invested US$ 74.9 million in enhancements to the product, an increase of 31% on 2007. Nevertheless, an important
requirement for larger core banking implementations is the available capacity to customize. With this in mind, Temenos has
significantly expanded its TAM (Temenos Application Management) group in line with the many on-going T24 implementations.
Based in Chennai, India, TAM is now more than 400 strong and has the flexibility to grow quickly when required.

Project Risk
Probably one of the biggest obstacles to core banking legacy replacement is the serious risk of disrupting the business. Unfortunately
large scale in-house core system replacement projects have a very poor track record and have on a number of occasions failed to deliver.

The other problem that is often associated with such projects is the fact that they can take many years to complete and the business
requirements tend to change during that period.

Whereas any project – including the implementation of a packaged core banking application – incurs a certain element of risk, there is
ample evidence that package implementations have a much better track record.

What is more, typical core banking vendors who have a product focus rather than a services focus, see it as being in their interest – as
well as the interest of their customers – to constantly focus on simplifying implementations and reducing the time and effort required
to implement the system.

In the case of T24 that focus resulted in the creation of the Model Bank initiative. T24 Model Bank delivers the best practice of a large
number of T24 implementations in many different countries, crystallized in recommended settings for parameters, workflows and
domain specific or regional requirements, aimed squarely at accelerating the implementation by focusing end-users on adopting best
practice processes rather than trying to re-create legacy ones.

Closely associated with T24 Model Bank is a key part of the Temenos Implementation Methodology which focuses on a process-driven
assessment of the functional gaps which need to be resolved during the project.

In recent years Temenos’ focus on simplifying implementations has brought average implementation times to under 12 months and the
use of the Model Bank approach has delivered savings of up to 40% in the time taken to implement T24.

Cost
There is no doubt that a core system replacement project can be expensive.
In-house project attempts, reported in the public domain, have often been denominated in US $ hundreds of millions.
Even though the average initial licence cost for a core banking package for smaller banks is now reported by industry analysts as being
in the range of $2M to $4M, the actual cost of a project includes many more dimensions.
White Paper 6

To understand the total cost of ownership of a core banking implementation requires a detailed analysis which is beyond the scope of
this paper.

Suffice it to say that important ingredients which should be considered include the annual maintenance fees and the initial cost of
implementation and possibly more importantly the initial cost of customization – given that this cost is likely to be repeated to some
extent – for those systems which are not fully productized – at each upgrade.

What is evident is that for most legacy core system environments the cost of maintaining the system often consumes 70%-80% of the
available budget – severely constraining the ability of IT to innovate.

By contrast and assuming a highly productized implementation, the annual maintenance cost of a core system becomes highly
predictable and is made up of the annual maintenance fee and – ideally – an annual investment in the effort associated with upgrading
to the latest release.

So assuming we have succeeded in addressing some of the typical concerns … the next task is how to build a solid business case.

How to build a business case?

In summary, the business benefits of a core banking package implementation are easy to list in terms of the three key competitive
differentiators and the unavoidable cost of compliance:

• Time to market;
• Customer service;
• Operational efficiency;
• Compliance.

Time to market
Product innovation in the majority of legacy core banking environments is constrained by IT.

Whether the business initiates a change in response to customer demand or a competitive threat, invariably the timescales associated
with changing the many different legacy systems to support the revised feature – bundling, pricing, process or distribution channels –
and ensure continued compliance result in a competitive disadvantage against those banks who already benefit from:

• Parameterized product definitions;

• Externalized process and workflow orchestration;
• Multi-channel integration.

Customer service
Customer service is a function of the combined experience of interactions with the bank and, in most legacy banking environments, the
inconsistencies imposed by different business silos and channel processes. This often results in an inability for staff in practice – despite
best intentions – to deliver the values promised by the brand.

By contrast an integrated core banking platform has the ability to deliver a ‘single view of customer’ which brings together all of the
different products and services and a consistent set of processes which operate seamlessly across all of the different distribution channels.

In doing so it allows the bank’s staff to deliver the kind of responsive customer service which opens the door to successful cross-selling
of additional products and services.

Operational efficiency
Operational efficiency has a lot to do with cost but also with how effective the return is on the investment made.

Banks with legacy core banking environments often have a very high cost of IT which impacts the overall cost/income ratio – the most
commonly used means of measuring operational efficiency.
White Paper 7

Modern core banking platforms seek to improve operational efficiency through:

• The use of lower cost commodity hardware;

• Re-use of common enterprise services;
• Ability to outsource non-differentiating processes in the value chain;
• Capability to fine-tune processes on an ongoing basis;
• A shift in the balance of IT spending from maintenance to innovation.

Compliance
The ongoing cost of compliance with regulations and corporate governance requirements is an aspect of running a banking
operation which results in non-discretionary spending.

In legacy environments a single regulatory change often impacts a large number of different systems and as a result the cost of
achieving compliance can be excessive. This, rather sadly, means that many compliance projects fail to achieve a genuine change in
the underlying operational efficiency and risk management practices that could benefit the bank and instead simply seek to do the
least possible to obtain approval.

One of the clear advantages of a core banking platform that has been implemented in a large number of banks and countries is the
way in which the cost of compliance is spread across many organizations.

Good examples of this could be seen at the time of the Y2K efforts where every in-house system carried the full burden and
cost of ensuring the system was ready for the next century, whereas the cost of upgrading a core banking package was generally
rather modest.

Misys, for example, charged its customers on average about £ 100,000 for Y2K compliance at the time. That amount clearly
stands in stark contrast to the budgets set aside for Y2K projects in larger banks.

Temenos T24
What makes T24 unique is that it is able to deliver these benefits based on a fundamental commitment to a pure ‘product’ focus which
has resulted in the creation of a highly flexible, open and customizable ‘core banking platform’, which delivers the benefits of a rapid
core banking implementation without the longer term risks and costs associated with a more services–based business model.

This core banking platform addresses a large number of the basic processing requirements of a ‘universal’ bank – across retail, corporate
and private banking operations as well as more specialized areas such as Islamic banking and microfinance.

Combined with an open architecture and tooling this then becomes the basis for gradually shifting IT investment from
maintenance to innovation.

But here is the tricky question…

Whereas it is a relatively straightforward task to express the business benefits of a modern core banking platform in qualitative terms,
how do we proceed from here towards the quantification required to deliver a solid business case for taking on a large legacy core
system replacement project.

Temenos Operational Performance Study (TOPS)

So what if it was possible to spend a modest amount of time and money quantifying the benefits which would arise by comparing
current ‘as is’ processes against what would be delivered by T24 Model Bank processes …

In recognition of the need, particularly in the current climate of constrained investment in IT, to help prospective customers put
together a solid business case for a legacy core system replacement project, Temenos has built a small team of management
consultants armed with a fully documented set of T24 processes and a tool designed to help with this kind of analysis.

This team is keen to engage with larger banks who are ready to start building the business case.

Details of what TOPS offers and how it works are the subject of a separate white paper.
White Paper 8

About the author

Koen Van den Brande

Group Strategy and Marketing Director at Temenos
He advises the board of BIAN* on strategy. Prior to joining Temenos he
held senior positions as Worldwide Industry Manager for Core Banking
at Microsoft, President of the Polaris Intellect product group and
Product Director of the Misys Equation product group.

* BIAN – Banking Industry Architecture Network www.bian.org

About Temenos

Founded in 1993 and listed on the Swiss Stock Exchange (SWX: TEMN), Temenos Group AG is a global provider of banking software

systems in the Retail, Corporate & Correspondent, Universal, Private, Islamic and Microfinance & Community banking markets.

Headquartered in Geneva with 52 offices worldwide, Temenos serves over 700 customers in more than 120 countries. Temenos’

software products provide advanced technology and rich functionality, incorporating best practice processes that leverage Temenos’

experience in over 600 implementations around the globe. Temenos’ advanced and automated implementation approach, provided

by its strong Client Services organisation, ensures efficient and low-risk core banking platform migrations. Temenos annually invests

around 20% in R&D, significantly more than its peers, into a single fully packaged upgradeable software release, which ensures all

Temenos customers benefit from modern technology and support indefinitely. Temenos is top of the IBS Sales League Table 2008,

winner of the Best Core Banking Product category in Banking Technology magazine’s Readers’ Choice Awards 2008, winner of the

Financial-i Leaders in Innovation award for the most innovative core banking systems solution 2008 and is listed in the American

Banker top 100 FinTech companies. For more information please visit www.temenos.com

Copyright © 2009, TEMENOS. All rights reserved