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
rishi@ana-data.com
(201) 780 2790
www.ana-data.com
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. It contains intellectual property belonging to ADC. It shall not be duplicated
or distributed by any means — in whole or in part — 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 — or in connection with — 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 ........................................................................................................................................................................ 4
PROJECT DRIVERS .............................................................................................................................................................. 5
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....................................................................................................................... 8
Metadata ............................................................................................................................................................................. 9
Data Traceability ................................................................................................................................................................ 9
Data Quality Management ................................................................................................................................................. 9
Data Store Status, Data Quality and Data Tracing Reporting ........................................................................................... 9
DESIGN 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 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 ........................................................................................................................................................................... 32
PROJECT STAFFING FOR ANALYSIS STREAMS ........................................................................................................................ 32
PROJECT STAFFING FOR REPORTS ENHANCEMENT STREAM .................................................................................................. 33
STAFF PROFILES ..................................................................................................................................................................... 35
PRICING/COSTING MODEL .............................................................................................................................................. 37
CLIENT REFERENCES ........................................................................................................................................................ 38
GOLDENTREE ASSET MANAGEMENT (GTAM) ...................................................................................................................... 38
STONE HARBOR INVESTMENT PARTNERS (SHIP) .................................................................................................................. 38
MERRILL LYNCH GLOBAL COLLATERAL DATABASE ............................................................................................................. 38
ASSUMPTIONS AND DEPENDENCIES ............................................................................................................................. 40
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 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 highly capable and experienced staff. Ana-
Data’s clients are major investment and brokerage houses, successful hedge funds, and other capital
management companies.
Part of 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.
Centralized Approach to Data: It is common that a successful company’s business grows to a degree at which
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 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 Objecti ves
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 CONSIDERATIONS
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 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 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
 Positions
 Balances
 Trans
 Market Values
 Accruals
Yield Book
 Benchmark holdings
 Security level analytics
 Country of Risk & Currency
Bloomberg
 SMF data
 Bonds
 Equities
 Derivatives Contracts
 Prices
 Benchmark & fund returns
 Market rates
 Ratings
Market Data Providers
 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

o Bond
o Equity
o Derivative
o Index
 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 decision-
making.
 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.
o Defining the storage model and processing elements.
o Logging ETL process and reflecting the data store state.
 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 requirements, 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 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 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:
o The requirements-gathering stage, in which every suggestion is considered
o The implementation stage during which changes can be accommodated but must be
negotiated and will generally slip the schedule
o The rollout stage, where the project features are frozen (to avoid scope creep)
 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 M odel
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 RESOURCES

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 – essentially handling all vendor-specific processing.
ADC’s Vendor 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.
 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 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
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 developers.
Price Master
Price Master System allows the client to request and receive securities prices from multiple vendors,
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 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, 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 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 the original pipeline along with some 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 signs-off on checklists, and requires Accounting management
to sign-off afterwards. The process 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 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 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 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 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. 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 for developing processes for storing and extracting data. This individual
works closely with the Team Lead and client’s database personnel. Database Developer executes 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 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
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 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 six 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 Ana-
Data 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).
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 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 in-
depth 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 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 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
Technology Used: Microsoft Visual Studio 2005, .Net 2.0, Smart Client, Composite Application Block, SCSF
(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 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.
Technology Used: Microsoft Visual Studio 2005, .Net 2.0, Smart Client, Composite Application Block, SCSF
(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:
o Client’s Business Analyst is dedicated to the project. He/she has extensive subject matter
knowledge of business operations to assist Ana-Data Consulting (ADC) in writing
requirements/specifications and testing.
o Project manager to manage the client’s participation in the project (unless this work is also
given to ADC). Typically ADC provides project management of its participation in the project
itself.
o 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
works with clients in Manhattan, Jersey City, and nearby. Arrangements can be made to
perform work at other locations or at Ana-Data’s Jersey City office.
o The client provides standard developer’s desktops to the Service Provider personnel for use on
the project.
o The client provides necessary access and privileges to use its infrastructure, computing and
communication resources, application software, office facilities as well as expertise and
knowledge available with the client for the entire duration of the project.
o 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
specifications to the Service Provider project team in a timely manner.
o The client provides all non-documented relevant information.
o The client provides all needed support to ADC personnel for understanding business as well as
technical environment.
o The client provides its existing SDLC documentation templates which ADC will conform to for
the Target State deliverables.
o Content of the reports in terms of the source details including the input data fields in the data
store, and the report columns are provided by the client.
o The client provides access to the necessary staff (Subject Matter Experts, Users) in a timely
manner for the entire duration of the project.
o The client supports timely resolution of issues and responds to queries encountered during the
project execution.
o The client provides timely sign-off on the documents where it is needed.
 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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Approach To Building Asset Management

Uploaded by

Copyright:

Available Formats

Ana-Data Consulting

June 11, 2008

One Exchange Place, Suite 308, Jersey City, NJ 07302

(201) 780 2790

Ana-Data Approach to Building Asset Management Systems

TABLE OF CONTENTS ........................................................................................................................................................ 2

Example of break up of pricing ADC typically proposes:

 For GAP/Requirement Analysis

System Support of Business Functions

Systems Development Objecti ves

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

Golden and Distributable Copies of Data

Scheduling of Delivery, and Ad-Hoc Requests

Automation of Processing in the Data Store

Data Quality Management

Data Store Status, Data Quality and Data Tracing Reporting

Data Store Design Aspects

Summary of Vendor Experience

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

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

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

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

Market Data Providers

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

Securities Management Systems and Their Vendors

Trade Order Management Systems

 Advent Software (Moxy)

Portfolio Management and Investment Accounting

 Advent Software (AXYS, APX and Geneva)

Data Management and Middleware

 Asset Control (CDM)

 GoldenSource Corporation (EDM)

Performance Measurement and Performance Attribution

 Portfolio Management Systems integrated Performance Plus

Risk Management Software

 Algorithmics (Algo Suite)

Analytics and Data Providers

Straight Through Processing (STP) Software

Data in the Data Store

Classes of Data in the Data Store

 Security (instrument, deal) descriptive for multiple security types, including

Organization of Data in the Data Store

Systems Interacting with the Data Store

Systems providing data to be loaded into the data store:

Consumers of the data:

Data Store Architectural Considerations

Benefits of Architecture with Data Warehouse

Advantages of data warehouse:

Data warehouse, properly designed, will provide:

Architecture with Data Marts

Operational Data Store

Virtual Data Store

 Dependence on sources being up, online, and in good consistent state

Data Flow to and from the Data Store

Data Flow Organization Principles

Principles of organization of data consumption from the data store:

SOLUTION DELIVERY MODEL

 General system architecture

General System Architecture

The following steps in enhancing the IT setup should be implemented:

Data Store Architecture

 Build detail architecture of the data store

For analysis and architecture, as applicable:

Data Store Design and Implementation