Vous êtes sur la page 1sur 4

Collateral Implementation:

SunGard Adaptiv Collateral CASE STUDY

This paper is one of a series of case studies written as part of work undertaken by CubeMatch personnel. For details of the
other papers found in this series, please email us at consulting@cubematch.com. This particular case study looks at work
performed by CubeMatch on the implementation of a collateral management programme in a large global bank. It
documents how a strategy for the implementation programme in the bank was put in place which covered the business
architecture, policies, operational procedures as well as technical infrastructure and how CubeMatch helped the bank define
and achieve its goals.

The Contact
In early summer 2001, the head of Credit Systems Financial Markets approached CubeMatch to project manage the
implementation of a Collateral management programme in the bank. The project was to cover not only systems integration,
but also to establish the environment in which they would operate. The bank in question is rated among the top 20 financial
intuitions in the world and had a programme already running since 1998. However, the programme had only achieved
limited success and due to a re-organisation in the bank the original programme team made up of IT personnel and external
consultants was disbanded.

The 1998 Collateral initiative


The 1998 collateral programme was an initiative from the Treasury department looking to reduce its risks to counterparties. It
was also strongly supported by the Head of Derivatives Trading who saw it as a mechanism to extend trading. The drivers of
the programme were the reduction of credit risk, the expansion of business with existing counterparties and the development of
new business with lower graded counterparties.
The Collateral programme embarked on a requirements gathering mission that lasted 2 years. Other than to main European
offices, trips were also made to the main global offices in Asia and the Americas. Despite the length of time spent on the
requirements, there was a lack of documentation and no conclusive decision was made that allowed all the different
requirements gathered to be met (the requirements ranged from Wholesale Lending, Project Finance, Repo, Derivatives, Stock
lending etc). Furthermore, no decision was made upon whether to implement an enterprise collateral management
programme incorporating multiple business lines (Derivatives, Repo, Stock Lending, FX margining etc) or to take a phased
approach.
Finally, in order to move the programme forward, a system was agreed on and was installed with the primary server in London
with access from a team of users in Amsterdam. The collateral system in question was the market leader and a good,
reputable piece of software. It was planned that a link be made to Brussels which managed collateral via spreadsheets. There
were also plans to rollout access to the Americas and Asia.

Situation as at 2001
Despite all the plans for access to other sites, the collateral system was not extended. The main problem was the usage speed
of the system. There were complaints from Amsterdam that certain screens took 4-5 minutes to load and that the system was
frequently unavailable (from the users point of view it was unknown if this was a network issue, a software or a hardware
issue). In fact the issue was that the infrastructure wasnt stable, and the latency was due to the fact that screens were loaded
via a Wide Area Network.

Collateral Implementation:

SunGard Adaptiv Collateral CASE STUDY

On the business side, after three years, there were only a total of ten collateral agreements managed from London by the
derivatives operations department and four agreements managed from Amsterdam centre by the special projects department
in Finance. Only cash collateral was placed /accepted in Amsterdam and collateral calls were done weekly. There was no
analysis of the costs or benefits of implementing the programme. There was not a cohesive policy on collateral and no means
of prioritising new collateral agreements to be negotiated. These factors severely constrained the level of new business that
could be made. There was a list of over 100 requests for collateral agreements that were outstanding.
As with the case sometimes, all the blame is put on the IT systems.
Other issues include the fact that when cash was received, in Amsterdam this was placed/borrowed from the treasury
department but in London cash was placed/received by any desk that wanted the collateral agreement in question and
securities were just held in a custody area and not re-used. As such there was not optimal use of the collateral and one centre
could be long in a particular currency while the other would be short of the same currency.
The causes of the problems were
The original programme team only concentrated on systems selection
There was little focus on the business drivers for implementing the programme
Limited buy-in from the businesses
Poor implementation of the original software
No proof of concept for the business processes nor a definitive policy on collateral
Individual departments managing their business separately (London managed its Collateral from the Operations
department, Amsterdam managed it from their Finance department and Brussels via their Credit department)
Lack of communication between collateral centres
Lack of communication between the Front Office, the Legal department the Credit department, Operations and IT
No cohesive plan of action

How the situation was turned around


The bank decided that the key use of their collateral system was to be as a part of credit mitigation and control was therefore
given over to the Credit department. Also by locating the derivatives collateralisation function in the credit department, this
laid the potential for subsequently migrating the collateral or margin operations of other departments into a single enterprise
collateral management function. While the move of responsibility to another department doesnt necessarily solve problems, it
allowed a fresh look at the issues. The head of Credit Systems Financial Markets set about getting together a steering
committee made up of senior management from Financial Markets, Credit, Legal, Operations and IT. This committee had the
capacity to represent all the global interests and decide on the best way forward. A Project Co-ordination Committee was
created with the mandate to solve problems. Jacob Koshy of CubeMatch was appointed Project Manager and reported to
both committees.
The first objective was to re-evaluate the system decisions. After a short evaluation period, the Credit department decided that
it made sense to re-align the Collateral system with the Credit systems and decided on a new collateral infrastructure based on
the SunGard Collateral system. This system not only provided the required functional richness, but there were clear benefits to
be gained from implementing a collateral management system that was fully integrated with the incumbent credit limits system
and from partnering with a large and reputable supplier such as SunGard.

Collateral Implementation:

SunGard Adaptiv Collateral CASE STUDY

CubeMatch worked closely with SunGard and Risk IT to first create a test environment, to ensure all the functionality of the old
system was available and to test the migration of all the trades across to the test environment. In parallel, work was done to
build the full fault tolerant Production environments. Key to building the parameters was that all screens needed to be
accessible globally within seconds or sub seconds. A full User Acceptance test was conducted in London, Amsterdam and
Brussels. With a lot of work by all parties (Users, Risk IT, SunGard), the system went live within 6 weeks of the start of
implementation.
Next, work proceeded on standardising all the Operational processes in existing collateral centres. With the assistance of a
senior SunGard consultant (an experienced collateral professional previously with JP Morgan and Bank One), this was
achieved. We defined the operational procedure flows and defined the relationships and responsibilities of the various
departments including Credit, Legal, Operations and Front Offices. Procedure manuals and process documentation were
produced. Despite internal politics and local opposition, all collateral administration was aligned and moved to a new
department that reported into Credit Risk management called Collateral Administration Function (CAF).
In tandem with the above, work was undertaken to prioritise outstanding agreements and a streamlined process to handle the
interaction between Front Office, Credit, Legal and Settlements was implemented. The new process also handled any new
requests globally and was called the Request for Collateralisation Program (RFCP). It ensured smooth working between
departments especially Legal. They had previously complained of no involvement in the programme, and sometimes only had
poor information on the Credit term agreements, and werent updated on the urgency or priority of the agreements. The new
RFCP process also provided an audit trail and sign-offs. This reduced legal and operational risks within the collateral
application process.
Work was also undertaken with Risk Measurement, the Treasury department, Legal and the Credit Analyst team on improving
the collateral policy, especially in areas of adding known Legal opinions, credit thresholds, acceptable haircut, and collateral
eligibility, the re-use of collateral and operational roles.
This model was first implemented in London and Amsterdam and proved ideal to roll out to the other geographical locations.
Thus the creation of a new collateral centre became simply a case of applying the franchise rules to the new locations.
Procedures and policies were already in place.
Once the systems, operational process and application processes were ironed out, it was relatively straightforward to
demonstrate the use and benefits of the new system. Next, work turned to setting a central global Collateral Asset
Management (CAM) function for the programme. After much discussion, and several papers showing the cost benefit of such
a desk, the CAM desk was set up in the Treasury department working with the Repo and Cash Management desks. The CAM
desk proved profitable with the re-use of collateral and the leveraging of the Repo and Cash areas. Within a year of the desk
being set-up, it managed over $6billion USD in movements with a net positive asset position of $2billion.USD.

Collateral Implementation:

SunGard Adaptiv Collateral CASE STUDY

What were the reasons for success?


A Steering committee with teeth.
Close involvement from all parties via the PCC.
A solid infrastructure platform.
Keeping close contact with the vendor (SunGard) and calling on their experience.
Creating a virtuous circle. As more agreements were signed, confidence in the programme grew.
Defining a strong operational process with clear definitions of responsibilities thereby helping to minimise the operational risk
and maximise the efficiency of the programme.
Replicating these processes in new locations to ensure that high standards were maintained throughout.
Benchmarking. Met up with clients, the bank was more involved in the ISDA Collateral committees etc
Rigour. Ensuring that things were chased up and only the highest standards were acceptable.
The close link between CAF and CAM.
A single Collateral Asset Management function globally - ensuring the most efficient allocation of collateral assets, maximising
P&L opportunities.

Position at the end of 2003.


Number of agreements doubled every 6 months and the target of clearing the backlog of outstanding agreements achieved
(from a base of 14 agreements in 2001, including the asset swaps, the bank had more then 100 agreements monitored).
Ability to manage different types of collateral and the merge into CAF/CAM of the Repo collateral area.
Global coverage via rollout of the Asian Collateral centre and initial establishment of the Americas Collateral centre.
The same single system used in all areas and a single global collateral pool Expansion in agreement types.
There is a global head of Collateral now and all teams are working to a single strategy.

What did CubeMatch do?


Our role was mainly one of being a catalyst in bringing the pieces together, assistance in formulation of the strategy and in
providing the drive. Once there was a clear vision we obtained senior management's approval to bring all the participants
round the table. We worked hard and by using experienced resources from all different areas, we were able to demonstrate
success right from the start. This success kept momentum going until we achieved all aspects of the implementation. The
original problem was that there was too much emphasis on the systems and not enough on the full collateral vision. Software
should always be a tool and not the driver. We helped balance the picture and provided the impetus for the project.

Vous aimerez peut-être aussi