Approach To Building Asset Management

Ana-Data Consulting

Approach to Building

Asset Management Systems

June 11, 2008

One Exchange Place, Suite 308, Jersey City, NJ 07302 [email protected] (201) 780 2790 www.ana-data.com

Ana-Data Approach to Buildin g Asset Management Systems

Ana-Data Approach to Building Asset Management Systems USAGE PROTECTION NOTICE The purpose of this document is to inform companies and people about approach taken by Ana-Data Consulting (ADC) to analyzing, designing, and implementing systems for its clients This document is property of ADC. AD C. It contains intellectual property belonging to ADC. It shall n ot be duplicated or distributed by any means — means — in in whole or in part — part — without without a written permission from ADC. The document shall not be used for any purpose other than explicitly expressed in the document. Any form of reading of this material beyond this place is considered acceptance of the obligations described in this Usage Protection Notice. Should this be unsatisfactory, please close this document and destroy any files created by the in conjunction with opening the document. If ADC and the business entity represented by the reader of this document are parties to a current confidentiality or non-disclosure agreement that covers the material described in this document, or a contract is awarded to ADC as a result of — of — or in connection with — this — this document, the information disclosed in this document shall be subject to the confidentiality, proprietary rights and nondisclosure provisions of such agreement. All information contained in this document is preliminary and non-binding. ADC shall have no liability of any kind to any person or entity with respect to this document or any of the contents hereof. Nothing in this document shall constitute an offer capable of acceptance or create or be deemed to create any legally binding obligation. This is informational but not a binding agreement. Any liabilities and obligations of the parties will be set forth in a definitive agreement. The pricing and technical is set forth in this document represent ADC's good faith estimate based upon limited information set forth in the documents provided to ADC. Accordingly, ADC reserves the right to revise its pricing and technical proposals following an appropriate due diligence period. © Copyright 2008 Ana-Data. All rights reserved. ADC and the ADC logo are trademarks of ADC and are registered in the USA and other countries. All other trademarks contained in this document are the property of their respective owners.

Page 1


Table of Contents TABLE OF CONTENTS

........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ........................... .............2

BACKGROUND BACKGROUND ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ................ 4 PROJECT DRIVERS DRIVERS ............................ .......................................... ............................ ............................ ............................ ............................. ............................. ........................... ........................... ............................ .................. .... 5

REQUIREMENTS REQUIREMENTS ........................... ......................................... ............................ ............................ ............................ ............................. ............................. ............................ ........................... ........................... ......................... ...........6 SYSTEM SUPPORT OF BUSINESS FUNCTIONS ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ........................... .............6 Business Functions ........................... ......................................... ............................ ............................ ............................ ............................. ............................. ........................... ........................... ............................ .................. .... 6 SYSTEMS DEVELOPMENT OBJECTIVES ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ...................... ........ 6 PROJECT SCOPE........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ................ 7 BUSINESS REQUIREMENTS ............................ .......................................... ............................ ............................. ............................. ............................ ............................ ........................... ........................... ......................... ........... 7 Data Store........................... ......................................... ............................ ............................ ............................ ............................. ............................. ............................ ........................... ........................... ............................ .................. .... 7 Data Feeds.......................... ........................................ ............................ ............................ ............................ ............................. ............................. ............................ ........................... ........................... ............................ .................. .... 8 Data Treatment.......................... ........................................ ............................ ............................ ............................ ............................. ............................. ............................ ........................... ........................... ......................... ...........8 Target Applications .......................... ........................................ ............................ ............................ ............................ ............................. ............................. ........................... ........................... ............................ .................. .... 8 Golden and Distributable Copies of Data ....................................... ..................................................... ............................ ............................ ............................ ............................ ........................... .............8 Securities of Interest ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ................ 8 Scheduling of Delivery, and Ad-Hoc Requests ..................................... ................................................... ............................ ............................ ............................ ............................ ...................... ........ 8 Automation of Processing in the Data Store........................ Store....................................... ............................. ............................ ............................ ........................... ........................... ......................... ...........8 Metadata ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ .................... ...... 9 Data Traceability............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ .................... ...... 9 D ata Quality Management ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ .................... ...... 9 Data Store Status, Data Quality and Data Tracing Reporting ........................... ......................................... ............................ ............................ ............................ ...................... ........ 9

DESIGN CONSIDERATIONS CONSIDERATIONS........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ .................. .... 10 DATA STORE DESIGN ASPECTS ............................ .......................................... ............................ ............................. ............................. ............................ ........................... ........................... ............................ ................ .. 10 SUMMARY OF VENDOR EXPERIENCE........................... ......................................... ............................ ............................. ............................. ............................ ........................... ........................... ....................... ......... 11 SECURITIES MANAGEMENT SYSTEMS AND THEIR VENDORS ............................ .......................................... ............................ ............................ ............................ ........................... .............12 DATA IN THE DATA STORE............................ .......................................... ............................ ............................. ............................. ............................ ............................ ........................... ........................... ....................... ......... 15 SYSTEMS INTERACTING WITH THE DATA STORE ............................ .......................................... ............................ ............................ ............................ ............................ ............................ .................. .... 15 DATA STORE ARCHITECTURAL CONSIDERATIONS ........................... .......................................... ............................. ............................ ........................... ........................... ............................ ................ .. 16 DATA FLOW TO AND FROM THE DATA STORE ........................... .......................................... ............................. ............................ ............................ ........................... ........................... ....................... ......... 18

PROPOSED PROPOSED SOLUTION DELIVERY MODEL.......................... ........................................ ............................ ............................ ............................ ............................ ............................ .................. .... 20 PROPOSED APPROACH............................ .......................................... ............................ ............................ ............................ ............................. ............................. ........................... ........................... ............................ ................ .. 20 STREAMS (PER EXAMPLE) ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ......................... ........... 20 DELIVERABLES AND DOCUMENTATION ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ .................. .... 22

ANA-DATA’S BUSINESS PRACTICES .......................... ........................................ ............................ ............................. ............................. ........................... ........................... ............................ ................ .. 23 BUILDING DATA STORE ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ........................... .............23 FUNCTIONAL AND TECHNICAL REQUIREMENTS ........................... ......................................... ............................ ............................ ............................ ............................ ............................ .................... ...... 24 DESIGNING PROCESS FLOWS, ARCHITECTURE, AND DATA MODEL............................ .......................................... ............................ ............................ ............................ .................. .... 25

ANA-DATA’S SOLUTION RESOURCES ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ......................... ...........27 PROJECT ACCELERATORS ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ......................... ........... 27 EXPERIENCE IN FINANCIAL INDUSTRY ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ .................... ...... 27

PROJECT PLAN............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ......................... ...........31

Page 2


RESOURCES RESOURCES ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ .................. .... 32 PROJECT STAFFING FOR ANALYSIS STREAMS ........................... .......................................... ............................. ............................ ............................ ........................... ........................... ....................... ......... 32 PROJECT STAFFING FOR REPORTS ENHANCEMENT STREAM .......................... ......................................... ............................. ........................... ........................... ............................. ................. 33 STAFF PROFILES ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ ......................... ........... 35

PRICING/COSTING PRICING/COSTING MODEL ............................ .......................................... ............................ ............................. ............................. ............................ ........................... ........................... ............................ ................ .. 37 CLIENT REFERENCES REFERENCES ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ........................... .............38 GOLDENTREE ASSET MANAGEMENT (GTAM)............................ .......................................... ............................ ............................ ............................ ............................ ............................ .................... ...... 38 STONE HARBOR INVESTMENT PARTNERS (SHIP) ............................ ........................................... ............................. ............................ ........................... ........................... ............................ ................ .. 38 MERRILL LYNCH GLOBAL COLLATERAL DATABASE ............................ .......................................... ............................ ............................ ............................ ............................ ......................... ........... 38

ASSUMPTIONS ASSUMPTIONS AND DEPENDENCIES DEPENDENCIES............................ .......................................... ............................ ............................ ............................ ............................ ............................ ........................... .............40 APPENDICES APPENDICES............................ .......................................... ............................ ............................ ............................ ............................. ............................. ............................ ........................... ........................... ............................ ................ .. 42 ABOUT ANA-DATA ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ............................ .................... ...... 43

Page 3


EXECUTIVE SUMMARY Ana-Data Consulting (ADC) is pleased to present its approach for Data and System Architecture for Asset Management companies and departments. We strongly believe that we have the capability to successfully undertake strategic architectural challenges as well as building systems and databases for this kind of companies. We know environment, processes, and needs. Our team can hit the ground running. We have in-depth understanding of the technology/framework used for systems of this class of companies. Ana-Data as you may know was the pioneer in establishing web and reporting framework on which many general and specialized asset management systems have been developed. Typical challenge faced by companies is that of making the existing employees time available for the required tasks. Broad experience with multiple teams and environment settings (in Technology, Operations, and business) will definitely help towards understanding business needs and existing system evaluation. Ana-Data is quick to adapt to various SDLCs. We have undertaken various system implementations with asset management companies and divisions, including AIG Investments, Merrill Lynch, UBS, Stone Harbor Investment Partners, One William Street Capital, and GTAM. Together with our investments in establishing Asset Management Solution Practice; we have created a noteworthy competency. We have developed adapters and gateways to third party vendors for rapid implementation of asset management systems. ADC has extensive experience in analysis, architecture, design, and development of a wide range of financial services applications using advanced technologies. ADC assembles teams with the relevant experience, including both the technical expertise and in-depth understanding of securities investment domain. A team is comprised of people that have worked closely together many times to successfully develop and implement asset management systems, including developing the accelerators accelerators for the rapid securities application deployment. ADC technical staff understands the challenges of architecting, designing, developing and implementing asset management systems. Example of break up of pricing ADC typically proposes:     

For GAP/Requirement Analysis For architectural design For the central Data Store design For the central Data Store implementation For the Reporting Services

The total cost for delivering the system per requirements is calculated. ADC people are always eager to start a project and bring it to successful completion, working together with the client’s teams and delivering first-class systems.

Page 4


BACKGROUND Ana-Data is a dedicated consulting firm committed to catering to financial companies offering them technical solutions and products designed and implemented by Ana-Data’s Ana-Data’s highly capable and experienced staff. AnaAnaData’s clients are major investment and brokerage houses, successful hedge funds, and other other capital management companies. Part of Ana-Data’s Ana-Data’s clients, that have extensive set of sophisticated modern and legacy systems, wish to advance capabilities and technology further and need a result-oriented vendor able to bring fresh approach, understanding of needs, and contemporary technology to complex business and systems environment. Other clients lack comprehensive technology utilizing modern developments in building applications and data stores needed to meet the requirements of different business user groups. Vital necessity to be competitive, especially in the today’s world with economic shocks, instability of underlying assets, increasing internal/external audit, and regulatory requirements for controls around financial company processes, is driving perpetual need to implement extensions, enhancements, and reengineering in the systems essential for the business.

PROJECT DRIVERS Architectural deficiencies: Some companies have many information technology processes manual; systems are

insufficient, incongruent, and poorly talk to each other. Understanding of that is an important first step to retooling system sets. System approach: It is imperative that a company reaches clear understanding that only holistic approach,

integrated architecture, and controlled systems development process can provide adequate support of its business operations in today’s dynamic environment with rapid asset flow, swinging from booming markets to recession, regulatory changes, and technological advancements adopted by competitors. Business requirements: Unified architectural approach lets build systems that not only satisfy immediate

business needs, but can be scaled to support growth and changes in the business. Controlled customizations of processes to support specific business needs should be done in a manner that does not contradict to overall architecture and built-in principles, and therefore allow for growth and changes without creating a mess of programs, reports, and manual labor-intensive processes. company’s business grows to a degree at which Centralized Approach to Data: It is common that a successful company’s approach to information support based on mixing data taken from different systems and manually maintained spreadsheets can’t provide conformed consistent traceable information needed for business management and regulatory regulatory reporting. Beginning from that point the company can’t adequately function without centralized data stores capable of collecting cleansing, conforming, aggregating, and distributing data, able to support needs of business today and its future growth.

Page 5


REQUIREMENTS A company needs to have information systems that support its business, for example of asset management. It is typical that the company has systems providing for some important business functions, like trading, accounting, pricing, etc. Nevertheless it is common that the systems in general are disparate, without standardized interaction protocols. Each system possibly could or could not provide intra-system data consistency, but very often the company lacks integrated presentation of diverse information reflecting the business. The most damaging for a company engaged in asset management type of business is absence of single view at its positions, trades, and related information aggregated as needed for reporting, evaluation of performance, risk, forecasting, etc. It is common to prefer architecture built with a data store, real or virtual, in the prominent place. The data store accumulates information from specialized company’s systems, cleanses and integrates it, and provides current and historic information for reporting, analysis, forecasting, operations, business process management, and other consumption, as needed to make the company’s business highly effective and profitable. Based on detail analysis of current business needs for conformed data and evaluations of data assets, a decision should be made about architecture of the data store that could be presented as a data warehouse, an operational data store, one or multiple data marts, virtual store with access to the underlying data sources at request time, or some combination of them.

System Support of Business Functions A typical asset management company should have systems supporting its business functions. Business Functions             

Trade processing Accounting Operational reporting Regulatory reporting Securities modeling Pricing Analytics Risk management Performance evaluation Obtaining information from various sources Information reconciliation Keeping account of customer capital Customer relationship management

Systems Development Objectives

Page 6


The main objectives of a typical proposal of architectural approach include: 









 

  



Take centralized architectural approach to building and enhancing the set of system used to support company’s business. Allow growth and expansion of systems reflecting growth of business. Make architecture flexible, not dictating specifics and not rigidly restricting building additional systems, applications, and their elements. Take conceptual approach to data architecture that allows for clean consistent conformed data properly timed and going through a traceable managed path from its creation or obtaining to presenting or using further. Make sure to incorporate in the architecture a position and trade data store. Analyze in detail current and future business needs for conformed data and design a data warehouse, an operational data store, one or multiple data marts, or some combination of them. Design and implement new systems or integrate with existing systems that are providers of data to the position and trade data store. Among such systems are accounting and trading systems, Security Master, Price Master, and others Design and implement new systems or integrate with existing systems that are consumers of data stored in the position and trade data store. Among such systems are Reporting Services, Analytics Master, Risk Analysis System, and others. Determine role of existing data stores and their coordination with the position and trade data store. Provide full range of management tools to control data movement between systems, including into and from the position and trade data store, with capability to identify data deficiencies and errors, and report discrepancies and deviations from standards. Make data movement and processing fit tight timeframes. Provide robust audit trail completely tracing each important element of data Incorporate data standards and rules specifying data quality and timing. The rules should conform to various regional requirements, providing reliable verifiable compliance with expressed business objectives and regulatory requirements. Provide data availability as needed for the business, up to 24x7.

Project Scope Based on requirements and feasibility, a project scope should be specified. Each project phase should include steps towards integrated system and data architecture and filling gaps for supporting the business functions. Phases also should include storage of consistent conformed data representing company’s position, trade, analytic, and related information.

Business Requirements Various approaches to building overall system architecture for the company can be taken. Here is an example of architecture with a central data store on a prominent place. Such architecture emphasizes and makes it easier to accomplish supply of conformed data to business consumers. The description in the example concentrates around the data store itself. Data Store

Page 7


A data store, real or virtual, should be available for accessing by reporting services, analytic engine, risk and performance assessment systems, and other consumers interested in reliable data. Data Feeds

The data store should be fed by systems producing data, consolidating data coming from external feeds, and occasionally directly external suppliers. Data Treatment

The data store is responsible for data cleaning, feed integration and making the data conformed, and for data transformation in order to present it in easily consumable format providing high degree of data availability and high performance access. Target Applications

The data store should be designed with target applications in mind, including reporting services, analytic engine, risk and performance assessment systems, and others. Nevertheless it should not be necessary to define target applications in advance. Any application that needs reliable easily accessible data may take advantage of the data store consuming its data. Target application is based on business purpose that depends on client, department, user group, portfolio, process, etc. Golden and Distributable Copies of Data

The current data in the store, as a reflection of data in source systems, is a distributable copy. Cleansed and integrated data becomes a golden copy of such. The historic data obtains status of golden copy too. Any system that needs data should be going for golden copy unless it is not available or not suitable for the application’s purpose, in which case the application may pick up a distributable copy which is the closest to the golden copy and is the best fit for the need. Securities of Interest

The data store keeps position, trade, and other information about securities that are of interest for business users. It could be securities in which the company has or is planning to have position, evaluates possible benefits and risks, their underliers, index constituents, or just all existing securities of a particular type. Scheduling of Delivery, and Ad-Hoc Requests

Generally the information kept in the data store is made available directly in the database. A consumer gets it by running SQL queries against the DB. This way the consumer benefits from the organization of the data in the DB that provides high performance access. Running programs getting the data can be scheduled by the means of the data store or externally. Some consumers require data in a file of a particular format, for example, csv or xml, via e-mail, message queue, etc. Functionality to for this can be either added to the data store or provided by another system. Automation of Processing in the Data Store

Page 8


The data store should contain mechanisms for managing process of loading data without human intervention, based on metadata and schedules. Those mechanisms should report the data store status in regard to data load, and let manual intervention if needed. Metadata

The data store should contain elaborate metadata structures describing data elements, their business and technical domains, relationships with other data elements. Data elements should be clearly defined. Steps of processing, including loading and consuming of the data, should be defined, and processing should be logged creating complete audit trail. Data Traceability

The data store should be able to trace each piece of data presented to consumers to its source, including to each instance of load of feed item, for example a file. Data Quality Management

The data store should be able to identify deficient data, including inconsistent, out of range or not in lookup list, with missing elements, excessively volatile, etc. Data with errors should not be made available to consumers. In cases of minor deficiencies data can and should be made available for consumption, but with warnings about which consumers should be alerted. In each case error and warning information should be made available and error correction opportunity provided. This should be done by exception handling mechanism built in the data store. The exception handling mechanism should use load managing and data traceability functions of the data store. Data Store Status, Data Quality and Data Tracing Reporting

The data store should provide reporting to a business user and operational personnel, as needed for them, about status of the store in regard to loading the data, exceptions and their resolution. The data store should present logs and other auditing information, sources of data elements, etc.

Page 9


DESIGN CONSIDERATION CONSIDERATIONS S Ana-Data has considerable experience in architecture, design, and implementation of asset management solutions. This chapter draws from that experience to offer some insight into further considerations and challenges that a system architecture makeover project may encounter. The example of architecture with a central data store started in the previous chapter continues here.

Data Store Design Aspects The purpose of the data store among the company’s systems is to store security description, position, trade, and accompanying data to be used by other systems. The data provided by the data store is cleansed, made consistent and conformed, presented on appropriate granularity levels, and in such form that access by reports, for analysis, for export, etc. is fast. Time Aspects

The data store keeps and provides to consumers current and historical information. The data store keeps periodic snapshots of the data. The periods, reflecting business needs, could be day, month, quarter, etc. Therefore, after the end of a period, the data store has stable clean consistent data representing state at the end (or any other fixed moment) of the period. The data store built as a data warehouse has reasonably final version of the data. As a general rule, the data, since the moment it is made available for consumption in the data store, is not changed. Nevertheless occasionally business requires the data to be changed, for example, to make a correction of a major error. In such cases changes in the data warehouse can be made, but should be a part of a change procedure with reports, systems, and processes, that are consumers of the data and rely upon its stability, involved. Opposite to such change a normal process is to add to the data warehouse or mart a snapshot of data representing the next time period. Architectural Aspects

In order to satisfy business operational need to know its current up-to-the-moment state, and at the same time not to add to the data warehouse volatility that would interfere with retrieval of stable data, an operational data store can be offered in addition to a data warehouse. The purpose of the ODS is to load operational data from multiple systems, partially cleansing and conforming it. In the setup when the lowest time granularity in the data warehouse is day, the ODS can represent intra-day state of the business. Another option is to have an ODS instead of a data warehouse. This can be done when business needs only the functionality specific to ODS but does not need functionality specific for a data warehouse, as described above. The data store built as a data mart, in regard to how final is the version of the data, could be either more similar to data warehouse or to an operational data store. The data mart can contain a smaller more specialized set of data than another type of the data store. Business needs could possibly be satisfied by

Page 10


multiple data marts. It can be found out that a combination of a data warehouse and one or multiple data marts is the best for the business. If there is no need to provide historical data, then data conformity and access performance requirements in some cases can be satisfied by a virtual data store. Such data store is just a logical construction. It provides data by accessing data sources at the data request r equest time. Source Data

As a general rule data will not go to the data store directly from external (for the company) sources unless the external vendor prepares data in the way an internal specialized system would do. Exclusions from this rule are acceptable, but in most cases a specialized system that deals with the class of data receives the data from an external source, enhances it, and then submits it to the data store. For example, a price master system gets price data from vendors, then either automatically based on rules or with user intervention, creates golden copy of price from received and possibly overridden prices. This is the price sent to the data store. In order to accelerate implementation of the project with a central data store, in some cases interim processes for obtaining data directly from the vendors can be developed. Data Consumption

In order to have project with a central data store succeed, systems for receiving various classes of needed data from the data store have to be developed.

Summary of Vendor Experience Ana-Data has worked with multiple market and reference data vendors. Ana-Data’s Ana-Data’s specialists developed automated interfaces for various classes of data and types of securities. The following section illustrates intra-company and external data vendors with which we have previous experience in developing automated interfaces, together with the security types supported. Accounting Systems

For support of such asset classes and types of data as:       

Positions FX Contracts Market Values Accruals CF Prices SMF data FX Rates

Custodians

Page 11


For support of such asset classes and types of data as:     

Positions Balances Trans Market Values Accruals

Yield Book

For support of such asset classes and types of data as:   

Benchmark holdings Security level analytics Country of Risk & Currency

Bloomberg

For support of such asset classes and types of data as:        

SMF data Bonds Equities Derivatives Contracts Prices Benchmark & fund returns Market rates Ratings

Market Data Providers

For support of such asset classes and types of data as:        

Mortgages Economic Data Index & country level returns & weights Sector level returns & weights Security level returns & weights Prices Security level analytics Security sectors and other classifications

Securities Management Systems and Their Vendors

Page 12


There are companies offering off-the-shelf, usually requiring complex configuration and adjustment, systems and services working with securities. Here is a list of vendors of commonly used systems and services known in the industry, and their products. Trade Order Management Systems             

Advent Software (Moxy) Bloomberg Portfolio Trading System and Data License Charles River Development (Charles River Investment Management System) CheckFree Investment Services (CheckFree APL) DST International Eze Castle Integrated Decisions Systems, Inc. ITG Inc. (Macgregor XIP) Fidessa Latent Zero (Capstone) Linedata Services (LongView) SS&C Technologies, Inc. (Antares) Sungard Trading Systems Sungard/Shaw Data (Portfolio One) Thomson Investment Software (PORTIA Trade EQ)

Portfolio Management and Investment Accounting              

Advent Software (AXYS, APX and Geneva) CheckFree Investment Services (CheckFree APL) DST International (HiPorfolio) Eagle Investment Systems (Eagle STAR) - Implementation Partner Financial Models Company, Inc. (Pacer) FRI Corporation (Raison SPS) Integrated Decisions Systems, Inc. (GIM2) Princeton Financial Systems, Inc. (PAM) QED Financial Systems, Inc. SimCorp USA, Inc. SS&C Technologies, Inc. (CAMRA) SunGard (InvestOne, APS2, Series 2, Phase III, Others) Thomson Financial (PORTIA) Vestmark

Data Management and Middleware      

Asset Control (CDM) Citadel Associates (CADIS) CorrectNet, Inc. Eagle Investment Systems (Eagle PACE) Evare (Financial Data Transformation Service) Financial Models Company, Inc. (FMCnet) Page 13


       

GoldenSource Corporation (EDM) Informatica Mercator Netik One-Ten, Ltd. Portfolio Dynamics Sungard Integration (Mint, InteliMATCH) Tibco

Performance Measurement and Performance Attribution        

Portfolio Management Systems integrated Performance Plus Barra, Inc. Base-Two Investment Systems, Inc. (PAS) Eagle Investment Systems (Eagle Performance) Russell Performance Attribution SS&C / Financial Models Company, Inc. (FMC Sylvan) Stat Pro Portfolio Analytics Thomson Financial (Peform)

Risk Management Software  

Algorithmics (Algo Suite) BlackRock Solutions (Aladdin and Risk Analytics)

Analytics and Data Providers            

Barra, Inc. Bloomberg Data License Capital Management Sciences, Inc. (BondEdge) Interactive Data (FI Interactive) Hub Data FactSet (Cornerstone) FT Interactive Data GAT Muller Reuters Risk Metrics Thomson Financial

Straight Through Processing (STP) Software   

Advent (Rex) Checkfree (Accurate) Electra Information Systems (STaARS, RecCollect) Page 14


   

Netik (TDMS) Omgeo (OASYS / OASYS Global / ALERT / TradeSuite) SS&C / Financial Models Company. (TotalRecon, FMCRecon, FMCNet) Smartstream

Data in the Data Store Classes of Data in the Data Store

Data store used for asset management should include the following classes of data: 

                 

Security (instrument, deal) descriptive for multiple security types, including Bond o Equity o Derivative o Index o Rating Country, currency Rate Schedule Price Security classification Security-to-security relationship (like underlier, index constituent, TBA constituent, etc) Position Trade, transaction, activity Cash Analytic Party Party hierarchy Party role for security Portfolio, fund, strategy, account Portfolio system structure Reporting definition and schedule Metadata

Organization of Data in the Data Store

The data in the data store should be presented in the manner allowing clear understanding of its organization by the consumers. It includes personnel working with the consuming systems as well as automated processes getting data from the data store, for example reporting programs. Very likely dimensional model should be selected.

Systems Interacting with the Data Store

Page 15


This section presents approximate list of systems that a company has or should have that are sources of data flowing into the data store and systems that consume the data. Data Sources

Systems providing data to be loaded into the data store:          

Accounting System Security Master Price Master Cash Management Analytics Master Party Master Fund Master Reconciliation Other data stores Document Management

Data Consumers

Another important prerequisite of such a data store success is development of systems using data provided by the data store. Initial set of the most important and urgent such systems should be rolled out at the time of rollout of the first cut of the data store. Consumers of the data:      

Reporting Services Analytics Master Reconciliation Performance Analysis System Risk Analysis System Compliance and Policy Master

Data Store Architectural Considerations Decision of the data store architecture, whether it is a data warehouse, an operational data store, one or multiple data marts, virtual store with access to the underlying data sources at request time, or some combination of them, depends upon such factors as usage of the data, number of sources and quality of the data they provide, etc. Benefits of Architecture with Data Warehouse

Advantages of data warehouse:

Page 16




 



 

 



The data warehouse publishes the data assets of the company to most effectively facilitate decisionmaking. Data is specifically structured for query and analysis. Data warehouse is oriented to presentation of a specific group of subjects. It contains data that gives information about particular subjects instead of about a company's ongoing operations. Data warehouse can contain or be related to single-subject data marts. Data warehouse contains integrated data gathered from a variety of sources and merged into a coherent whole. Data contained in data warehouse is time-variant. It is identified with a particular time period. Data in data warehouse can be made clearly non-volatile. The data is stable, and more data is added but data is never removed. This enables management to gain a consistent picture of the business. If needed the data can be made volatile specific well defined way. Data warehouse has capability to capture history. Data model of data warehouse allows for reporting tools to work without extensive programming work. Data structure of data warehouse allows for high performance data access for reporting and other consumption.

Data warehouse, properly designed, will provide: 

 













Understandability. When structure of well designed data warehouse is presented to the end user, it is accepted as immediately understandable, simple, recognizable, and intuitive. Performance. Fast response time on users' mouse clicks requesting reports. Implementation cost. With a well designed data warehouse, work on implementation can be well planned and controlled thus letting planning its cost and adhering to the plan. Hardware and software technology cost. Data warehouse approach allows for careful software and data design, usage of industry known software running on broadly used hardware. This decreases the costs of application development and the chances that end users will encounter complexity. Data warehouse facilitates creation of a scalable solution where only growth of number of kept attributes and volume of data requires additional investments, and they can be incorporated. Daily administrative cost is controlled by performing the routine loading of data into data warehouse tables through standard ETL processes and included production of standardized reports distributed to end users. Cost of surprises. Data warehouse model provides standard techniques for mitigation of little surprises such as late-arriving feeding data or corrections to existing data. Those surprises always can and will happen. They are addressed when data is received. Big surprises, such as new dimensions, dimension attributes, facts, and granularity of a data source, requiring alteration of database schemas while in production, can be gracefully addressed without disrupting work of existing applications and data channels. Prevention of irrelevant results. Tight cooperation of designers of data warehouse with end users, extensive and continuous business requirements gathering at the beginning and throughout the life of the data warehouse are at the top of the list of ground rules of data warehouse design. Following these rules allows creating data warehouse containing data relevant to its objective. Centralization combined with decentralization. A data warehouse can be built on a set of principles, standards, rules, processes, and patterns, being at the same time diverse and built piece by piece, supporting its own growth and reflecting ever expanding and changing business needs.

Page 17


Architecture with Data Marts

This architecture has a lot of similarities with architecture with data warehouse. The same can be said about benefits and drawbacks. Because a data mart is a smaller scale more specialized analog of a data warehouse, it concentrates on subset of general data in many cases, and is more suited to a particular system, set of applications, or user groups. Business needs can be addressed by one or multiple data marts. The data marts can coexist with a data warehouse being independent of it, be a part of it, or exist instead of it. Operational Data Store

Operational data store can be added to the blend or exist as just the only data store constituent. An ODS can be used to partially clean and conform the data on the way from sources to a data warehouse or data marts, as storage of intra-day data, or as storage of data that was not finally settled as needed to become eligible to be inhabitant of a data warehouse. Virtual Data Store

This is architecture without a real data store. Data requests are directed to the data sources; the data is cleaned and conformed on the fly. Advantages:    

Lightweight solution Absence of need to maintain databases for the data store Assurance that the data always is the same that in the sources Good performance in many cases

Drawbacks:  

 

Dependence on sources being up, online, and in good consistent state Need to directly reflect current state of a source rather than being able to use state at specific time, for example end of a previous day, unless it is provided by the source Limitation on data transformation Possible performance issues

Data Flow to and from the Data Store With any architecture selected for the data store, data flow to and from it should be organized, controlled, and audited, so that all processes of loading the data and many processes of getting the data run in automatic mode presenting full picture of the state of processing to the interested personnel. Data Flow Organization Principles

Principles of organization of ETL, the process responsible for population of the data store:

Page 18






 



 

The data store has production area where the data is exposed for consumption. It has structure understandable by consumers and provides good data retrieval performance. On the way from sources, with production area as ultimate destination inside the data store, the data is loaded into staging area. The staging area is organized so that it reflects the data as it comes in. Processes of loading source data into the staging area are standardized to a high degree. Processes of loading staging area data to the production area use standard (for the data store) technology and design approach, with processing organized standard way, but logic specific for particular transformation type and case. The data store contains control area with metadata of two types. Defining the storage model and processing elements. o Logging ETL process and reflecting the data store state. o ETL processes are driven by metadata, schedules, and source data availability. Data exceptions identified during ETS are logged. The data store has facility to address them.

Principles of organization of data consumption from the data store: 





 

Only data exposed by the data store in production area and declared in good state can be accessed by or sent to target applications. Data access is done such way that the consuming system, access date and time, and data store’s state are known to the data store and are logged. Typically the data is retrieved using database stored procedures whenever it is possible and feasible. Notable case of a data consumer querying database directly is tool, for example reporting, building query automatically. Standard reporting tools are used to generate reports. Regular requests for the data are scheduled and coordinated.

Page 19


SOLUTION DELIVERY MODEL Approach ADC usually treats self-contained major parts of a project as separate but related streams, for example:     

General system architecture Data store architecture Data store design and implementation Design and implementation of each system - data consumer And so on

ADC’s engagement methodology is simple, effective, and tailored specifically to use all extensive capabilities of its highly skillful staff for the client’s benefit. The effectiveness comes because of the ADC team’s competency in asset management and related domains coupled with technology expertise.

Streams Here are details of the streams outlined in the example in the description of the approach above. General System Architecture

This stream includes analysis of existing system set and business r equirements, and building new architecture. The following steps in enhancing the IT setup should be implemented: Identify business needs in informational support Assess existing information systems and manual processes Identify gaps and deficiencies of existing processing Architecture system set structure with long-term horizon in mind Identify priorities in building the systems Architecture system set structure with short-term horizon in mind Identify sources of information for the data store Identify systems that will consume data from the data store        

Data Store Architecture

The following steps in designing the data store architecture should be taken: Create detailed list of systems, services, and user groups consuming the data store information Identify specific information query classes needed to the data consumers Identify constraints for the data store Make decision about the best architectural approach to the data store Make decisions about platform, environment, and hardware     

Page 20




Build detail architecture of the data store

For analysis and architecture, as applicable: Assemble existing documents Interview key personnel and conduct JAD sessions Set metrics Assess risk Evaluate alternatives Make architectural decisions Document the solutions Plan design (and later plan implementation)        

Data Store Design and Implementation

The following steps in the data store design should be implemented: Analyze in detail information elements up to attribute level needed by each consumer of the data store Based on the data store architecture and the required information elements build data model of each major component of the data store Construct metadata Create database(s) with the objects per the data model Specify ETL processing requirements 



  

The following are steps of the data store implementation: Develop load of data from every type and case of source into staging area of the database. Develop movement of data from staging area to production area effectively representing the rest of ETL process responsible for data cleansing, transformation, conforming, and other necessary steps for each type of the data. Develop controller programs responsible for management of ETL process. Develop UI and supporting programs for observing and influencing the ETL process, and resolving exceptions.  

 

For each implementation, as applicable: Design functional specification Design report presentation Map report fields to the database and design additional data structures as needed Design code, and unit test the application Develop and execute system test script Support UAT      

Design and Implementation of Systems - Data Consumers

Page 21


The following are steps of design and implementation of each system that should consume data from the data store: Set priorities for design of the data consumers based on business needs, availability and need for resources Make decision on distribution of functionality fu nctionality between phases of development of each system Develop external specification for the first phase Develop functional specification Design UI screens Design code, and unit test the application Develop and execute system test script Support UAT 

      

Deliverables and Documentation Notable deliverables: Current state general architecture, data and process flows, and data model documents, as applicable General architectural document Architectural document for the new data store Detailed functional requirements document for the data store Detailed technical requirements document for the data store Target state general architecture, data and process flows, and data model documents, as applicable Recommendation Recommendation for Implementation Approach Detailed project plan (tasks, deliverables, dates, and not-to-exceed price) for the architecture, design, implementation, testing, and deployment phases        

Page 22


ANA-DATA’S BUSINESS PRACTICES Based on extensive experience gained working with numerous clients, deep understanding of client business needs and the best ways to address them, Ana-Data, when designing data stores and systems working with them, follows the best business practices.

Building Data Store When building a data store Ana-Data takes approach that results in rapid development of system greatly improving effectiveness of the business. Approach  









  



 

Interview the end users. Substitutes for direct exposure to the end users may not be accepted. Make sure the source system administrators are effective partners with the data store team in downloading the data and uploading cleaned data. Training sessions, newsletters, and ongoing personal support of the end -user community to be part and parcel of the first rollout of the data store. Recommend that the data store support people to be physically located in the end-user departments, and devote their time to the business content of the departments they serve. Have first user training when rollout of the data store is ready to go live on real data. Keep the first training session short and focus only on the simple uses of the tool. Train 50 percent on the tool and 50 percent on the content of the data. Plan on a permanent series of beginning and follow-up training classes. Make sure development of applications using the data store data is scheduled so that they are ready with the rollout of the data store. Start with lightweight data store architecture and build the data store iteratively. Get support of the senior executives at the very beginning. Maintain clear stages of each major iteration of development: The requirements-gathering stage, in which every suggestion is considered o The implementation stage during which changes can be accommodated but must be o negotiated and will generally slip the schedule The rollout stage, where the project features are frozen (to avoid scope creep) o Focus for the first deliverable on a single source of data and do the more ambitious data store parts later. Serve the end users' needs. Build cost-effective, simple systems, distributed rather than centralized, and add incrementally to the logical and physical design.

Avoiding Pitfalls

When designing data store, Ana-Data will make sure to avoid:   

Unavailability of data needed for decisions Lack of partnership between IT and end users Lack of explicit end-user-focused cognitive and conceptual models

Page 23


          

Delayed data Unconformed dimensions Unconformed facts Insufficiently verbose data Data in awkward formats Sluggish, unresponsive delivery of data Data locked in a report or dashboard Prematurely aggregated data Excessive focus on ROI of the data store Sliding into creation of an enterprise data model A mandate to load all existing data into the data store

Functional and Technical Requirements It is important to note steps taken by Ana-Data when approaching requirement gathering phases of this type of projects. Understanding of Current State      

Assemble and review existing documents Interview key personnel Review functions and features of existing systems Review enhancements in progress Identify gaps between existing documents and real state of the systems Get understanding of the system design

Bringing up-to Date Current State Documents     

Business domain description Process flow Data flow Data models Architecture

Gathering Business Requirements

Identify:      

Pain points Deficiencies New business challenges Opportunities Needed enhancements Time constraints

Page 24


Work with business and IT representatives:  

Interview key personnel Conduct JAD sessions

Analyzing Business Requirements     

Assess feasibility Prioritize Formulate desired target state Identify detail project scope Specify required performance, scalability, and availability

Establishing Metrics         

Number of inputs Number of outputs Volume of data Processing timings Number of users Complexity of processing Completeness of processing Degree of operational personnel manual participation Degree of IT personnel manual participation

Identifying Technical Constraints and Requirements        

Review any existing technical blueprints Collect information about technical practices in the company Identify mode of interaction with external systems Processing power Parallelism Disk space Database Complexity

Designing Process Flows, Architecture, and Data Model Highlight of steps taken by Ana-Data during design for this type of projects. Current State Deficiencies   

Identify missed functionality Identify manual processes Identify inefficiencies Page 25


Functional Process Flow    

Use cases Identify activities Arrange activities Identify future expandability points

Application Architecture    

Conceptual model System sequence diagram System process flow UI look and feel mockups

Data Architecture and Models   

Identify high levels of data flow Design conceptual data model Design logical data model

Page 26


ANA-DATA’S SOLUTION RESO URCES Project Accelerators Vendor Gateway

ADC has developed a Vendor Gateway component for handling interactions with electronic data vendors. It provides a common interface for submitting requests to vendors and retrieving data back from them. It performs the preparation and transmission of request files, and the download and processing of the data and error report data from the vendors – vendors – essentially essentially handling all vendor-specific processing. ADC’s Vendor Gateway Gateway has been used in conjunction with Ana-Data Pricing System. The clients report complete success of the combination. Vendor Gateway includes the following features:  







A full-featured scheduler (for sending/receiving vendor files), with automated retry on failures. f ailures. A GUI administration console for reviewing current job status and performing manual one-off resend/fetch actions. Extensible SSIS-based architecture, allowing support for new vendors to be added on a modular basis. Automated email notifications, announcing failure events and successful file transfers to the support groups. Transmission methods supported: FTP, HTTPS, Email.

While not strictly productized, the ADC Vendor Gateway has been designed to be suitable for reuse with various systems. It is a standalone process with its own data model that can be adjusted for specific data formats. It has no client- or system-specific environmental dependencies. Effective Architecture/Framework Architecture/Framework Built on .NET 2.0/Smart Client

ADC has architecture of multiple systems and a framework built using the best practices for developing an enterprise application using Microsoft’s CAB UI Toolkit and Infragistics Presentation Toolkit. Some of the key features of the architecture are:    



Command based controller. This allows entitlements, auditing etc to be added easily. Clear interfaces with Vendor Gateway and other interacting systems. A user interface based on normal flow and exception processing. Embodies the repeating routine life cycle, with the ability to show clients where they are in the workflow. File watcher. It monitors a directory and notifies if a new file have been placed there.

Experience in Financial Industry

Page 27


Ana-Data specializes in information technology solutions for financial industry. Thanks to extensive success record based on expertise, experience, and dedication, the company stands out among the competitors. This guarantees that a project of this class will become one more success story for Ana- Data’s client and Ana-Data Ana-Data itself. Some systems designed and implemented by Ana-Data can be incorporated in a solution for a client with insignificant adjustment effort by Ana-Data’s Ana-Data’s developers. Price Master

Price Master System allows the client to request and receive securities prices from multiple vendors, depending depending on security type, company’s opinion about the vendor in regard to a particular price, and other factors. Client can use trader’s, appraisal company’s, and others prices. Rules can be set prioritizing pricing sources for automatic price selection for a security type or a security. Rich web-based user interface can be used to override, select, approve, submit, and other way manipulate prices and also rules. Pricing system is perfect in conjunction with Vendor Gateway used for direct interaction with price vendors. Cash Management

Cash Management is a strategic asset management module that addresses the following functions: 









   







A Cash Allocation rule engine that eliminates need of manual, tedious and error prone cash flow entries to the account management system. A Cash Flows engine that handles (client selection, unified view, rule overrides, editing, approvals, security) cash flows (e.g. subscriptions, redemptions, contributions, withdrawals, expenses etc.) from custodians, transfer agents and client instructions. A Cash Flow distribution channel that allows cash administrators to distribute pertinent flows to various business groups via an extremely sophisticated distribution rules engine that allows portfolio and user selection, rule and content management. Cash admin meta-data management screens allow power users to dynamically change the behavior of Cash Management system by modifying the data model behind the scenes. Cash flow reports that provide various customizable reports like client-portfolio relation integrity violation, system allocation rules snapshot and cash flows. Beginning of day cash retrieval from the accounting systems. Capture pending settlement from the trading system. Allow adjustments to beginning of day cash balances from custodian cust odian reconciliation Maintain an intra day cash balance by portfolio and currency that allows portfolio managers to act proactively. Generate intra day balance reports to various manager and provide drill down to portfolio level detail. Implement querying system for net cash flows (trade and non trading) with the details of flow providing securities identifier, description and quantity. Project end of day cash flow to enable cash management team to gain a projected early view of the system for complex analytical calculations.

Page 28


Major technologies and products used in Cash Management:  

   

Framework: Microsoft .Net Framework, Ana-Data Framework Design: N-tier Distributed System Architecture Design Principles, Object Oriented Programming, Interface programming Language: C#, Java Script, XML, XSLT Tools: Microsoft Pivot Table, Microsoft Visual Studio .Net .NET Core Technology: ASP .Net/ADO .Net, Windows .NET Database: Microsoft SQL Server, Entity Relationship Diagrams, Stored Procedures

Reconciliation

Reconciliation system provides a mechanism of comparison two sets of financial data. Important example is cash reconciliation between an asset management company and banks. Another example is reconciliation with custodians. Reconciliation handles properly time-series data, it allows adjustment for different timing of the being compared sets of data. Discrepancies are shown on security – portfolio, – portfolio, security, and portfolio levels. The system provides opportunity to have legitimate exceptions and comments. The systems allows to put breaks in multiple buckets and setting different priorities for resolving, for example permanent, one-time, resolved, pending, intra-system breaks. CRM

CRM system, besides standard functionality for this kind of systems allows following multiple sides of customers beyond just related to dealing with prospects and tracking communications with them. This system follows a prospect becoming a customer, provides links to Pipeline and Accounting systems thus maintaining a complete representation of the the customer’s image from his/her business with the company point of view. Pipeline

Pipeline Application allows an asset management company to collect and track prospective intra-fund transfers (withdrawals and contributions) by the company funds. This system introduced a workflow process that collects the investor information in a web front-end GUI with workflow services and a database repository, allowing Client Service to enter and verify pipeline transactions. Accounting only needs to review review the original pipeline along with some additional additional fields as a checklist item and update a confirmation flag when proceeds are received from investors. This potential list of pipeline transactions drives the Accounting Allocation Sheet import and the New Accounts for fund management system. Client Service management management signs-off on checklists, and requires Accounting management management to sign-off afterwards. The process works works as follows: Client Service representative enters, fund accountant verifies, Client Service and Accounting managers review and sign off fund potential list information. Client Service uses the list viewing it various ways and exporting. Pipeline application is developed using the following technologies:

Page 29


    

Microsoft Smart Client Architecture Microsoft Win-form, Microsoft Composite Application Block Infragistics Presentation suite Web Services SQL Server 2005

Page 30


PROJECT PLAN Examples of Ana-Data’s Ana-Data’s approach to putting together a project plan. General System Architecture

Data Store Architecture

Data Store Design and Implementation

Page 31


RESOURCES Ana-Data has talented people capable of engaging in a project needed for a client and bringing the project to successful completion

Project Staffing for Analysis Streams Project Manager for Analysis Stream

Project Manager is a single point of contact and responsible for the delivery delivery of the GPS Analysis Stream. This individual works closely with the client’s business leads/project managers and vendors. Project manager schedules, tracks, manages, and synchronizes the activities/tasks to ensure that program remains on track. He/she is also responsible for managing the overall program cost, schedule and resources. Data Architect

Data Architect is responsible for putting together the data specifications for the target state, including but not limited to the architecture, design and implementation of the data model and data integration platform. This individual with in-depth in-depth knowledge of securities provides data strategy and model to support the client’s current and proposed solutions. Business Analyst

Business Analyst is responsible for analyzing and reviewing the existing systems and workflows. He/she also coordinates the effort to determine the future needs for the system. The business analysts also develops the scorecards, coordinate coordinate the activities with the system vendors including measuring vendors’ products and applicability to the client’s needs. Business Analyst works on developing specs for the reports including analyzing and determining data sources and report columns.

Page 32


Project Staffing for Reports Enhancement Stream Team Lead/Senior Developer

Team Lead is the single point of contact, responsible for the delivery of all results. This individual works closely with the client’s business leads/project managers and database managers. man agers. Team Lead schedules, tracks, manages, and synchronizes the activities/tasks to ensure that program remains on track. He/she is also responsible for managing the overall program cost, schedule and resources. Very often Team Lead also performs Senior Developer or Systems Analyst functions. Database Developer

Database Developer is responsible responsible for developing developing processes for storing and and extracting data. This individual works closely with the Team Lead and client’s database personnel. Database Developer executes exe cutes the activities/tasks to fulfill specifications related to the database and suggest data schema changes. Senior Developer (Specialized)

Senior Developer is responsible for the design and development. He/she is specialized to work with a particular area of development using a particular group of technologies. He/she performs elements of systems analyst’s functions covering, together with Technical Architect, this technological functionality completely. This individual works closely with the Team Lead and users. This developer executes the activities/tasks to ensure fulfillment of specifications in relation to the reports. Typically this individual is also responsible for testing. Technical Architect

Technical Architect is responsible for understanding the existing system architecture and designing the architecture for the target state. Technical architect assists in system strategy, process engineering, solution options, trade-offs, and design. This individual is responsible for integrating the proposed solution within the client’s environment, including integration with the exiting up/downstream systems, review and incorporation of third party solutions or tools. Engagement Manager

Engagement Manager is responsible for overseeing the entire engagement (multiple projects and streams), ensuring the engagement is on track to meet the agreed schedules and delivery, for mitigating risk, and for ensuring effectiveness of ADC personnel’s work towards meeting project objectives. This individual with in depth knowledge knowledge of securities ensures that the client’s business needs are met with the proposed solution. This individual is the final ADC escalation point relating to address change in scope, restrictions, and engagement model. Business Advisor

Page 33


This business domain expert can be made available on as required to basis to resolve any issues and provide guidance on the project direction and strategy.

Page 34


Staff Profiles Following are resume summaries of some Ana-Data associates possessing the requisite skill sets for Ana-Data’s Ana-Data’s engagement. These are the actual examples of real company’s personnel who have successfully worked on multiple projects. Please note that in no way Ana-Data’s Ana- Data’s human resources are limited just to these people. Project Manager – James has over 20 years of experience in financial service industry – recently having

completed multiple projects at GoldenTree Asset Management. James has been delivering value-based projects working with both buy-side and sell-side clients including a boutique hedge fund, JPM Chase, Merrill Lynch, Morgan Stanley, Fidelity and many others. His expertise is in solutions delivery with emphasis on project risk management, business requirements analysis and leveraging methodologies that expedite time to delivery - such as prototyping and SOA architecture. His success and leadership is based upon team communications, client/executive expectation management, change control and quality control management. Prior to 2001, James had many successes in working with capital markets clients during the s ix years with Deloitte Consulting.

Business/Systems Analyst - Mark has over 7 years of software development and delivery experience. Mark

has first hand experience of architecting, design, coding and implementing various asset management systems. He works closely with the users to understand the existing systems and designing new systems that allow companies significantly expand and expedited performance of their business functions. Prior to joining AnaData team, Mark was employed by Bearing Point. Data Architect - Eugene is a highly experienced data architect and modeler, data warehouse designer,

systems and business analyst, and database and systems developer, capable of meeting the most complex data challenges. He has over 20 years of professional experience. During years of work with data in securities industry designed data architecture, including strategy, logical and physical data models, and metadata, designed data and technological standards, and implemented best practices for data warehouses and other data stores. Business Analyst - Mahesh is a strong Financial Services domain Business Analyst capable of meeting the

most complex challenges. He has strong experience in the areas of Investment Banking, Equity Research and Fund Management. Mahesh was involved implementing asset management and pricing systems. He works closely with the users to understand existing systems, needs, and gaps, and to design new systems that allow enhanced accelerated performance. Prior to joining Ana-Data team, Mahesh was employed by Genpact (previously a General Electric Company). planning Engagement Manager - Mohan has over 25 years experience as an IT executive with strategy, planning and management skills and a proven track record of implementing large scale mission critical enterprise technology solutions from idea through conceptualization to commercial product delivery. He has in-depth understanding of core business processes and business functional requirements of the Securities Services industry. Mohan is a strategic thinker who can bring value and leadership at the executive level to drive tactical and strategic initiatives in support of the imperatives of the firm. Technical Architect - Bob is an enterprise software engineer, a hands-on person, who manages teams of

developers to deliver technology solutions for the financial industries. As the Chief Application Architect for ADC, with 20 years of working experience, he helps clients bring about effective software solutions from early inception to final delivery. Robert’s expertise in enterprise design patterns and n-tier n-tier frameworks continues to set new standards in rapid application development. Robert is a graduate from Devry Institute in electronic engineering and got continued education at Fairleigh Dickinson University in Knowledge / Rule Base systems and other advanced computer science disciplines.

Page 35


Senior Developer Vipul has 7 years of extensive Microsoft .NET experience in commercial applications

development involving development (system, analysis, design, testing, quality control and implementation), product customization and implementation. Vipul has experience developing various securities systems. He works closely with the users to gather and implement business requirements. Senior Developer - Julio has 8 year of experience developing commercial applications. Julio was a key

developer in developing and implementing the accelerator components of core Ana-Data systems. He has indepth understanding of the rules engine to extract and manipulate the data based on the user defined rules. Pricing Business Advisor - John is a seasoned Financial Services Professional, with extensive business

knowledge and experience. John has experience working at AIG Investments, BlackRock, Bloomberg, UBS, Standards & Poors and others.

Page 36


PRICING/COSTING MODEL Pricing challenge is address by Ana-Data by gaining enough knowledge about the current and future-state applications, creating project schedule schedule and budget with a degree of certainty. Gap Analysis benefits pricing through significantly improved level of requirements definition, and mitigation of risk associated with pricing assumptions. The benefit to a client is the prospect of predictable pricing and more more importantly, the reduction of risk. Upon completion of assessment and preparation phases ADC is pleased to discuss with the client a Risk Reward model pricing for the implementing the systems. Ana-Data evaluates human resource needs for the projects, and based on quite reasonable compensation requirements calculates total cost of the project for the client.

Page 37


CLIENT REFERENCES Following are some of the references wherein ADC has provided services. Due to the confidentiality reasons we have not provided names and contact details of the references for these client’s. However, we will glad to fix a call with any/all of these client’s should a prospect desire to speak to them.

GoldenTree Asset Management (GTAM) Client Profile: GTAM is a New York based institutional asset manager with a broad investment purview.

Middle market lending, European investing, real estate investing and broader exposure to equities. Engagement Profile: ADC was retained by GTAM for the development and delivery of a new Pricing

Application to support automated daily pricing of all holdings using several electronic pricing vendors (IDC/LPC/MarkIt/Bloomberg) across two regions (US and Europe). This also included support for manual overrides, price quality alerts (e.g. price variance), complex fund-specific pricing policies (e.g. aggregation of multiple broker quotes), pulling holdings from an upstream system, pushing final prices to a downstream system, auditing/reporting and support for month-end adjustment activities. Technology Used: C#, SQL Server 2005, Web Services, .NET Remoting, .NET Windows services, Infragistics,

Composite UI Application block (CAB), Enterprise Application Blocks, Smart Client Software factory (SCSF)

Stone Harbor Investment Partners (SHIP) Client Profile: SHIP is a New York based fixed income investment manager. SHIP was a spin-off from

Citigroup Asset Management originally Salomon Brothers Asset Management. Engagement Profile: ADC was retained by SHIP for the development and delivery of Stone Harbor Business

Application Manager (SBAM). The SBAM workstation was designed and developed provide a competitive advantage to SHIP to provide investment professionals with more accurate and timely investment data and improving client service. Some of the applications hosted under SBAM are:       

Securities Pricing Systems Security Master and Best of Breed Reconciliation Manager Performance Attribution Manager Risk Analytics Manager Contact Management Marketable Composites

Composite Application Block, Block, SCSF Technology Used: Microsoft Visual Studio 2005, .Net 2.0, Smart Client, Composite (Smart Client Software Factory), Enterprise Library, Infragistics and Pivot table, SQL Server 2005, SSIS, SSRS.

Merrill Lynch Global Collateral Database

Page 38


Client Profile: Merrill Lynch together with its subsidiaries provides broker-dealer, investment banking,

financing, wealth management, advisory, asset management, insurance, lending, and related products and services worldwide. Its Global Markets and Investment Banking segment provides equity, debt, and commodities trading; capital market services; investment banking; and advisory services to corporations, financial institutions, governments, and institutional investors. Engagement Profile: ADC was retained by Merrill for the development and delivery of Collateral Database

Workstation. The Collateral workstation was designed and developed to provide a reporting infrastructure which can accommodate multiple types of business audience, for example Dashboard style reporting for senior management, Cube drilldown/drill through capability for analysts, reporting for stock loan desk, Repo desk desk etc… The workstation provided the authentication and authorization to tailor the environment to a given user group, which themselves can customize on an individual bases. Composite Application Block, Block, SCSF Technology Used: Microsoft Visual Studio 2005, .Net 2.0, Smart Client, Composite (Smart Client Software Factory), Enterprise Library, Infragistics and Pivot table, SQL Server 2005, SSIS, SSRS.

Page 39


ASSUMPTIONS AND DEPENDENCIES ADC understands that any development effort involves some unknown circumstances. Successful completion of a project depends not only on ADCs work, but also on the client’s effort to provide proper conditions for that. As such, we make the following reasonable assumptions in order to accomplish the activities related to a project in a timely cost-effective manner. 









A client should provide the following resources for facilitate, guide, and direct the project team and to review and approve the deliverables: Client’s Business Analyst is dedicated to the project. He/she has extensive subject matter o knowledge of business operations to assist Ana-Data Consulting (ADC) in writing requirements/specifications requirements/specificatio ns and testing. Project manager to manage the client’s participation in the project (unless this work is also o given to ADC). Typically ADC provides project management of its participation in the project itself. Operations manager if needed in the case operations are in the scope of the project. o SMEs as and when required during the project. o Work is usually performed at the client’s location and no travel will be required. Ana-Data o works with clients in Manhattan, Jersey City, and nearby. Arrangements can be made to perform work at other locations or at Ana-Data’s Ana-Data’s Jersey City office. The client provides standard developer’s desktops to the Service Provider personnel for use on o the project. The client provides necessary access and privileges to use its infrastructure, computing and o communication resources, application software, office facilities as well as expertise and knowledge available with the client for the entire duration of the project. The environment should be set-up and configured to enable ADC to start work promptly. o The client provides all documentation of current state process flows, architecture, and system o specifications to the Service Provider project team in a timely manner. The client provides all non-documented relevant information. o The client provides all needed support to ADC personnel for understanding business as well as o technical environment. The client provides its existing SDLC documentation templates which ADC will conform to for o the Target State deliverables. Content of the reports in terms of the source details including the input data fields in the data o store, and the report columns are provided by the client. The client provides access to the necessary staff (Subject Matter Experts, Users) in a timely o manner for the entire duration of the project. The client supports timely resolution of issues and responds to queries encountered during the o project execution. The client provides timely sign-off on the documents where it is needed. o Definition of acceptance criteria and acceptance test cases are agreed upon between the client and ADC.. Changes in the data schema or any other change in the existing systems which can have impact on work on the project are communicated to ADC and are managed through a change control process if required. Release to production environment is usually managed and implemented together with the client. The client validates the accuracy of the data. All signoffs are completed as per mutually agreed schedule.

Page 40






Any changes to the scope are managed through a change control process. A change record includes effort expended by resources as a result of delays. Language of all the screens, reports, and application documentation is typically English only.

Page 41


APPENDICES About Ana-Data

Page 42


About Ana-Data Ana-Data Consulting Inc. (ADC) was established in 1993. ADC provides services in the areas of business analysis, technical architecture and software development in the financial services industry. ADC’s developers and analysts have architected, built, and implemented applications leveraging their deep financial services knowledge and advanced Microsoft .NET based Application Development framework for leading Financial Services companies. ADC founders and principals are expert finance industry and software professionals who recognize the opportunity to leverage cost-effective, advanced technologies to solve business problems which conventional systems fall short of. ADC has specific expertise in the areas of Portfolio management Systems, Securities Pricing Systems, Corporate actions, Derivatives Trading systems, Trades and Security Data Warehousing, Trade settlement engines, and Project Management. The ADC team not only posses detailed knowledge of financial markets front-end and back-end systems, but also have years of experience in developing applications using the latest technologies from Microsoft including C#, ASP.NET, Visual Studio 2005 and 2008, Biztalk 2006, Sharepoint Services, Content Management Server, SQL Server 2005 and its Integration and Reporting Services, Oracle 10g and 11g. Among other key technologies are IBM MQ Series and XML. ADC also has expertise with leading financial services packages (Portia, PAM, Charles River, etc.) Market Data (IDC, LPC, Reuters, Bloomberg, JPMC, Citigroup, Lehman etc.) and standards (FpML, FIX, SWIFT). ADC has worked with many large firms both in the retail and institutional side to implement business solutions. ADC has helped prepare their clients in implementing strategic and tactical solutions which has benefited their business using the state of the art technology by providing a competitive edge over existing competitors in the market place. ADC provides business process, information architecture, technical architecture, system requirements/analysis, complete end-to-end system development, third party application implementations and data warehouse solutions. ADC repository of practical methods, design templates, .NET frameworks, development tools, system components and best practices gleaned from numerous projects over many years, combined with highly experienced and professionals enables us to deliver high quality solutions on time, on-scope and on-budget. ADC is headquartered in Stamford Connecticut, with office in Jersey City, NJ and a R&D office in Dominican Republic.

Page 43

Approach To Building Asset Management

Recommend Documents