REQUEST FOR PROPOSAL Multi-Asset Class Investment Risk ... · 2.1 Multi-asset class risk system...

P a g e 1 | 69

REQUEST FOR

PROPOSAL

Multi-Asset Class Investment Risk

Management System

Date of Issue: 28 August 2019 Closing Date: 03 October 2019

P a g e 2 | 69

TABLE OF CONTENTS

1 BACKGROUND..................................................................................................................................................... 5

1.1 Introduction ................................................................................................................................................... 5

1.2 Strategies........................................................................................................................................................ 5

1.3 “Rigour” Approach to Investing .................................................................................................................. 6

1.4 Protection of Personal Information .............................................................................................................. 7

2 REQUEST FOR PROPOSAL................................................................................................................................ 8 2.1 Multi-asset class risk system request ........................................................................................................... 8

2.2 Purpose of the document .............................................................................................................................. 8

2.3 RFP response guidelines............................................................................................................................... 8

2.4 RFP process and submission procedure ...................................................................................................... 9

2.5 Submission date, time and address ............................................................................................................ 10

2.6 RFP process requirements .......................................................................................................................... 10

2.7 Structure of responses ................................................................................................................................. 12

2.8 Evaluation criteria ....................................................................................................................................... 13

2.9 RFP general requirements .......................................................................................................................... 16

2.10 Supporting documentation.......................................................................................................................... 16

2.11 Quotation/proposal conditions ................................................................................................................... 17

3 MULTI-ASSET CLASS RISK SYSTEM REQUIREMENTS ......................................................................... 19 3.1 Background.................................................................................................................................................. 19

3.2 RFP response objectives ............................................................................................................................. 20

3.3 Project Management Capacity.................................................................................................................... 21

3.4 Project Scope ............................................................................................................................................... 22

3.5 Support and Maintenance ........................................................................................................................... 24

3.6 Functional Requirements ............................................................................................................................ 27

3.6.1 High Level Diagram.................................................................................................................................... 27

3.6.2 Functional Requirements ............................................................................................................................ 29

3.7 Non-Functional Requirements ................................................................................................................... 38

3.7.1 Scalability .................................................................................................................................................... 38

3.7.2 Security ........................................................................................................................................................ 39

3.7.3 System Response Time and Availability ................................................................................................... 40

3.7.4 Support......................................................................................................................................................... 41

3.8 Technical Requirements ............................................................................................................................. 42

3.8.1 System Architecture Requirements............................................................................................................ 42

3.8.2 System Requirements.................................................................................................................................. 42

3.8.3 System Documentation ............................................................................................................................... 43

3.8.4 Reporting ..................................................................................................................................................... 44

3.8.5 Integration.................................................................................................................................................... 45

3.8.6 Hardware Requirements ............................................................................................................................. 46

3.8.7 Additional Software Requirements ............................................................................................................ 46

3.8.8 Connectivity ................................................................................................................................................ 46

3.8.9 Network ....................................................................................................................................................... 47

3.8.10 Web Technology..................................................................................................................................... 48

3.8.11 Business Continuity, Backup and Disaster Recovery .......................................................................... 48

P a g e 3 | 69

3.9 Hosting......................................................................................................................................................... 50

3.10 Implementation............................................................................................................................................ 51

3.10.1 Approach ................................................................................................................................................. 51

3.10.2 Timeframes ............................................................................................................................................. 52

3.10.3 Change Management.............................................................................................................................. 52

4 MARKET DATA.................................................................................................................................................. 53 4.1 Market Stats and Pricing............................................................................................................................. 53

4.2 Fundamental Accounting data, Estimate, Ownership & ESG.................................................................. 54

4.3 Credit Ratings (Major Agencies) ............................................................................................................... 54

4.4 Benchmark Data (Constituent Level Data) ............................................................................................... 54

4.5 Economic Data ............................................................................................................................................ 55

4.6 Commodities................................................................................................................................................ 55

4.7 Exchange Rates ........................................................................................................................................... 56

4.8 Index Data.................................................................................................................................................... 57

ANNEXURE A ............................................................................................................................................................. 61 1. Background ...................................................................................................................................................... 61

2. Terms of Business............................................................................................................................................ 61

3. The services to be provided............................................................................................................................. 61

3.1. The Services ................................................................................................................................................ 61

3.2. The service provider’s staff ........................................................................................................................ 62

3.3. Contract Management ................................................................................................................................. 62

3.4. Deliverables ................................................................................................................................................. 62

3.4.1. Preparation and Delivery ............................................................................................................................ 62

4. Fees and Payment ............................................................................................................................................ 62

4.1. Payment of services .................................................................................................................................... 62

5. Term, Suspension and Termination ................................................................................................................ 62

5.1. Duration of Contract ................................................................................................................................... 62

5.2. Termination of the Contract ....................................................................................................................... 63

5.3. Termination for Breach of Contract........................................................................................................... 63

5.4. Termination for Insolvency ........................................................................................................................ 63

6. Confidentiality and Conflicts of Interests ...................................................................................................... 63

7. Liability ............................................................................................................................................................ 63

8. General ............................................................................................................................................................. 64

8.1. Force Majeure.............................................................................................................................................. 64

8.2. Assignment .................................................................................................................................................. 64

8.3. Notices ......................................................................................................................................................... 64

8.4. Amendment ................................................................................................................................................. 65

8.5. Survival ........................................................................................................................................................ 65

8.6. Electronic Communications ....................................................................................................................... 65

8.7. Validity of contract Provisions................................................................................................................... 66

8.8. Conflict ........................................................................................................................................................ 66

8.9. Applicability ................................................................................................................................................ 66

9. Dispute Resolution and Governing Law ........................................................................................................ 66

10. Acceptance................................................................................................................................................... 67

P a g e 4 | 69

ANNEXURE B.............................................................................................................................................................. 68 RISK BUDGET SUMMARY .................................................................................................................................. 68

P a g e 5 | 69

1 BACKGROUND

1.1 Introduction

The Eskom Pension and Provident Fund (EPPF) is a defined benefit fund with defined

employer and employee contributions that provides retirement, withdrawal, death and disability

benefits to members, pensioners and dependants.

The EPPF is registered as a privately administered pension fund in terms of the Pension Funds

Act (1956) and it is approved as a pension fund in terms of the Income Tax Act (1962).

Approximately 108 people are employed by the EPPF on a permanent basis.

The EPPF manages approximately R141 billion in assets across funds that are managed both

internally and externally. The majority of the assets are locally domiciled with 29%

implemented in global and Africa strategies. These assets are managed across multiple asset

classes and strategies including hedge funds, private equity and direct property, listed

domestic and international equity, listed domestic bonds and listed domestic property.

The EPPF currently has rand denominated assets of approximately R99.5 billion and offshore

US Dollar denominated assets of R41.5 billion, as at the financial year of 30 June 2018.

1.2 Strategies

The Fund also has a number of specific and focused strategies in place.

1.2.1 Black Economic Empowerment Strategy. The Fund has a well-documented and heavily monitored Black Economic Empowerment

Strategy for asset managers in place. One of the primary objectives of the policy is to target

the establishment of new black asset managers by means of a dedicated incubator

programme. The EPPF currently has R2.0 billion assets committed to this programme.

The Fund also has a policy of supporting emerging black asset managers through an emerging

manager allocation of assets. This policy is implemented by the Investment Multi-Management

Unit of the Fund. The EPPF commits to allocate 65% of the domestic external portfolio

mandates exclusively to suitable emerging black asset managers.

P a g e 6 | 69

1.2.2 Developmental Impact The Fund also has a Developmental Impact policy, whereby a certain pool of assets

(R1.5 billion) is dedicated to high impact investments in four targeted development areas,

namely Social Infrastructure, SME Finance, Renewable Energy and Affordable Housing. The

Fund has a reduced return target for this portfolio of assets of simply beating inflation. However,

to date the Fund has been able to achieve an IRR in excess of 11.57% on these assets.

1.2.3 Private Equity The Fund has a long standing and well developed Private Equity Investment Programme. The

Fund has allocated R6.0 billion worth of assets to Domestic and African Private Equity. The

African Private Equity allocation of R1.0 billion has not been fully deployed.

Additional cash would only become available for domestic private equity when the allocation is

topped up due to growth in the fund size (to meet the target allocation of 4.5% of assets), or if

an investment is exited, and cash becomes available to recycle. The Fund has two policies in

place which regulate the domestic and Africa private equity portfolios.

1.2.4 Real Assets The purpose of the Real Assets mandate is to direct the EPPF’s strategy in investing in hard

assets that have long-dated and inflation-sensitive cash flows, namely Real Estate, Credit,

Structured products, Non-indexed related commodities and Strategies that invest in non-

traditional assets that better match the Fund’s liability profile. Fund has allocated R7.9 billion

worth of assets to Domestic and International Real Assets.

1.3 “Rigour” Approach to Investing

The Fund embarked on the study of risk in the investment of the Fund, with the outcome of the

development of a Risk Budget for the Fund.

The Fund, as part of the Risk Budgeting study, established a Risk Budget, defined in terms of

the solvency level of the Fund, which, together with certain tolerance bands, defines a risk

budget for the investments of the Fund. This effectively establishes the risk cognisant

investment philosophy of the Fund. The articulated Risk Budget as recorded in the Investment

Policy Statement of the Fund is broadly described in annexure B to this RFP.

The multi-asset class risk system must assist in managing the risk appetite of the Fund as

defined by the Risk Budget that will be available for the investment of the assets to the Fund

under particular solvency levels.

P a g e 7 | 69

To the best of its knowledge, the Fund believes that it is the only retirement fund in South Africa

to have explicitly established an explicitly quantified risk budget.

1.4 Protection of Personal Information

The Protection of Personal Information Act 4 of 2013 (POPIA) gives effect to the constitutional

right to privacy in terms of Section 14 of the Bill of Rights of the Constitution of South Africa.

Non-compliance with the POPIA can result in penalties and damage to the Fund’s reputation.

The Fund must ensure that adequate contracts with operators are concluded where Personal

Information is processed by a third-party provider. Shortlisted bidders will be required to

complete the Funds self-assessment questionnaire.

P a g e 8 | 69

2 REQUEST FOR PROPOSAL

2.1 Multi-asset class risk system request

The Fund would like to invite solution providers to submit a proposal to provide the EPPF with

a proposed solution(s) and associated services for implementing a multi -asset class

investment risk management system (“risk management system”).

This RFP describes the EPPF’s requirements and is intended guiding respondents to propose

a best fit solution for the EPPF’s current and future needs. The EPPF requests respondents to

propose a solution(s) for a risk management system that would allow the EPPF to manage and

report on the risk budget in a technically sound, prudent and complete manner.

The Fund allows most investible assets, but does not generally allow speculative assets to be

held. The Fund’s assets currently include an allocation to South African equities , Global

equities, Emerging Market equities, South African properties, South African bonds, South

African cash, South African Inflation Linked bonds, Africa Listed Equity, International Cash,

Domestic hedge funds, and Domestic and African Private Equity, including African

Infrastructure.

2.2 Purpose of the document

The purpose of this RFP document is to provide broad details relevant to the services required

and is not intended to provide detail of every action required.

2.3 RFP response guidelines

2.3.1 Point of contact This RFP is issued on an open tender notice format with a definite closing date and time.

Respondents are required to submit their responses in expansive detail and in time to qualify

for consideration of their responses.

During the response time the central point for all queries relevant to the provision of

background information and points of clarity relevant to this RFP, will be dealt by the Risk

Specialist at the Fund. In the interest of all parties concerned all queries must be submitted in

writing before 12 September 2019, at 17h00 South African Time and responses to queries or

points of clarity will be updated on the EPPF Website by 17 September 2019 at 17h00 South

African Time.

P a g e 9 | 69

The electronic mail address for queries is [email protected]. No telephonic

correspondence will be entertained.

2.3.2 Administrative Briefing Session After the distribution of this RFP, a briefing session will be conducted with all potential

respondents to provide any further information; address any possible uncertainties relevant to

the RFP; and/or to further detail the EPPF’s requirements.

The briefing session is scheduled to take place at 14:00 on 09 September 2019 at the EPPF’s

offices, Isivuno House, EPPF Office Park, 24 Georgian Crescent East, Bryanston East, 2191.

The information provided during this briefing session should be taken into consideration when

responding to this RFP. Vendors can join the session telephonically using +27 862 000 000

Pin Code 87642.

Vendors who would like to test the conference line before the administrative briefing session,

must send an email request to [email protected] before 05 September 2019, at 17:00

South African Time.

This session is not compulsory. Technical questions will be responded to as outlined in

2.3.1.

2.4 RFP process and submission procedure

The Fund will review proposals in its discretion against a set of pre-defined criteria and will rate

each proposal on its ability to satisfy the requirements stated in this RFP.

In the event that a preferred supplier is chosen such service provider will be formally notified.

A formal Contract and Service Level Agreement will be entered into between the Fund and the

successful service provider detailing issues such as the scope of work, remuneration structure

and the term of the contract.

Potential service providers are requested to be mindful of the time allowed for responses, the

closing date and time, the delivery address for proposals and must note that late submissions

will not be considered.

The RFP must be submitted with the necessary supporting detail and must at least provide all

the information requested in this RFP.

mailto:[email protected]


P a g e 10 | 69

The Fund reserves the right to consider any proposal in its entirety or partially, and may appoint

more than one service provider or no service provider at all.

2.5 Submission date, time and address

The closing date for submission of proposals at the delivery address indicated below is 03

October 2019 at 14:00 South African Time.

RFPs may be submitted in a sealed envelope and addressed to:

The Secretary of the Procurement Committee

Multi-Asset Class Investment Risk Management System Tender Submission

Eskom Pension and Provident Fund

The RFPs must be placed in the Fund’s official Multi-Asset Class Investment Risk

Management System Tender Box that is placed in the reception area at Isivuno House, EPPF

Office Park, 24 Georgian Crescent East, Bryanston East, 2191.

Respondents must ensure that whoever delivers the proposal to the Fund takes care to

complete the RFP register at the tender box and place the tender in the correct Tender Box.

RFPs may also be couriered or mailed by means of registered mail to reach the Fund on or

before the closing date and time, but it must be noted that postal and administrative delays

will not be accepted as a reason for exemption from the requirement that proposals must reach

the tender box on or before the closing time. It remains the responsibility of the respondents to

ensure that their proposals reach the Fund before the closing date and time.

Proposals may not be faxed or e-mailed and proposals received by any other means other

than being placed in the tender box, will not be considered and will be rendered invalid.

2.6 RFP process requirements

The following minimum requirements will be applied to the RFP process:

i. Responses received after the closing date and time will be considered late and will not be

accepted.

ii. All responses must be submitted in full and complete on or before the closing time. The

Fund will not allow additions and/or amendments to any response to be submitted after

the closing time.

iii. Submitted responses may be withdrawn in writing prior to the closing time.

P a g e 11 | 69

iv. All enquiries relevant to the RFP may only be submitted to the indicated point of contact

and in writing. Telephonic and/or verbal enquiries will not be entertained.

v. During the course of this RFP process, respondents may acquire confidential information

relating to the Fund’s business, projects and/or customers. Respondents are required to

keep this information strictly confidential at all times (even after the project has been

completed) and may not use or attempt to use or allow such information to be used for

personal gain or the gain of any other person or institution.

vi. Respondents may not disclose any such confidential information to any third party, but to

the extent that such disclosure may be necessary for the submission of a formal proposal,

must approach the Fund for prior approval to share any information with any third party.

This does not apply to information which must be legally disclosed or becomes available

to and known by the public.

vii. Respondents must comply with the highest ethical standards in order to promote mutual

trust and an environment where business can be conducted with integrity, in a fair and

reasonable manner.

viii. Respondents must, on the official letterhead of the company submitting the response,

declare that:

a. the information provided in all documentation is true and correct; and

b. the signatory of the tender document is duly authorised to do so by means of a special

or general resolution of the company/closed corporation.

ix. Proposals submitted to the Fund must remain valid for a minimum period of 90 days from

the closing date.

x. Respondents will be held to their proposals submitted. The Fund reserves the right to

negotiate the modification of a proposal with the successful respondent in whole or in part.

xi. Agreements reached after such modifications with the successful respondent, or parts

thereof, and accepted by the Fund will form part of the contract.

xii. Each proposal will be evaluated for general conformity to specifications and the

demonstrated capabilities of respondents to execute the scope of work.

xiii. Respondents must provide curricula vitae of all key personnel they propose for execution

of the scope of work, with clearly defined fields of expertise, functions and responsibilities.

xiv. In general respondents must indicate the experience and field/s of expertise of their

companies and must specifically indicate previous work done in the retirement fund

industry, if any.

xv. Respondents are responsible for any and all costs and liabilities incurred in responding to

this RFP. The Fund will not be responsible for any costs whatsoever or howsoever arising.

xvi. The Fund reserves the right to withdraw this RFP for any reason and at any time without

incurring any cost or liability.

P a g e 12 | 69

xvii. The Fund reserves the right to withdraw, at any stage of this process, amend or cancel

this RFP, reject or not accept any or all proposals, obtain any information from any lawful

source regarding past business history and practices of the respondent, and to take any

such information into consideration in the evaluation process.

xviii. The Fund does not have to explain acceptance or rejection of any specific service provider

and the Fund’s decision is final and binding.

2.7 Structure of responses

All responses are required to be prepared as follows:

2.7.1 Proposals must be electronically generated and one printed original must be signed in

permanent ink by the individual(s) legally authorised to bind the respondent.

2.7.2 Legibility, clarity and completeness are essential.

2.7.3 The RFP response should contain the following items:

i. 1 neat and securely bound clearly marked and signed original copy of the RFP

response, fee schedule and supporting documents;

ii. 14 neat and securely bound hard copies of the RFP response and supporting

documents as above;

iii. 1 digital copy of the RFP response on a USB memory stick; and

iv. The electronic copies of the RFP proposal and/or examples of work must be

provided in Adobe Reader Portable Document Format (PDF) , clear of virus

infections.

2.7.4 Responses must be prepared as simply as possible, providing a straightforward, concise

description of the interested parties and the capabilities available to satisfy the

requirements of the RFP.

Any submissions not complying with these requirements will be disqualified.

P a g e 13 | 69

2.8 Evaluation criteria

Respondents will be evaluated according to the extent to which the response to the RFP

indicate that they are able to meet the requirements of the EPPF, as stipulated in this RFP

document. The EPPF will not be held responsible or obliged to contact any respondent if the

response to the RFP lacks any information or clarity. The evaluation criteria against which

respondents will be evaluated will include, but are not limited to, the criteria contained in the

sections below and, the various evaluation criteria will be weighted in terms of relative

importance to the EPPF’s business objectives and strategies.

2.8.1 Track record

Respondents must demonstrate their expertise and experience in offering multi-asset class

risk systems on behalf of pension funds and asset managers over the past five years.

2.8.2 Fee Structure Respondents must provide the following costs for the implementation:

Cost Component Cost

Software Licenses

Software Installation and configuration

Infrastructure and hardware costs

Customisations and bespoke development

Development of Interfaces

Project Management

Requirements Specifications

Testing

Training

Other (please specify)

Market Data (Section 4)

- Terminal Cost

- Data Subscription

Total Cost

i. Indicate hourly rates for consultancy / implementation per resource level (i.e.

project manager, architect, developer, and tester) after the implementation.

P a g e 14 | 69

ii. Provide full details of any and all licencing requirements and what rights

attached to any licencing agreements.

iii. All pricing must be inclusive of Value Added Tax (VAT)

iv. All prices must either be quoted in ZAR or USD currency.

2.8.4 Empowerment / BEE The Fund is committed to advancing the objectives of B-BBEE and details of the locally

domiciled service provider’s B-BBEE credentials, supported by a copy of a rating certificate, if

a rating has been obtained, with details of the relevant company profile must be provided. In

the very least, specific reference must be made to:

Ownership structure and shareholding;

Board representation;

Executive / Operational Management structure;

Demographic composition of the actuarial team;

Gender equity profiles; and

Secondary BBBEE initiatives, such as procurement from BBBEE suppliers.

Locally domiciled respondents need to ensure that certificates must be in the name of the legal

entity making the submission and be current.

International domiciled respondents need to provide the Fund with their current and future

diversity and gender (inclusivity) targets.

These details must be clearly stated in the order requested and with the headings as above.

2.8.5 Client References

The EPPF may require reference site visits to established clients where the respondent’s

solution is already implemented and in full use, in respect of the final shortlist of respondents.

The EPPF therefore requires information regarding contactable clients that have deployed

and are currently using the proposed solution. Respondents must include references of at

least three recent risk management system implementations within the South African market

in the following format:

• Client name.

• Contact details (telephone, fax and email address),

• Responsible person.

P a g e 15 | 69

• Project description (scope, size, number of users, budget, duration and completion

date).

• Summary of key lessons learnt, if applicable.

When providing information regarding references it is accepted that the respondent has

cleared with the referent that:

• The client can be contacted directly by the EPPF or its consultants;

Vendors who do not have South African clients, may provide international based clients as a

reference.

2.8.5 Respondent Presentations, Proof of Concept (POC) and Site Visits

Site visits of sites where the shortlisted respondents’ proposed solution/s are in operational

use may be required for shortlisted respondents to have the opportunity to demonstrate their

systems and showcase previous implementations. Respondents must take care to provide

the contact details of their references and by including such names and details provide the

assurance that the EPPF or its advisors may freely contact such referents, subject to normal

protocols of confidentiality.

Respondents may be required to present their solutions to the EPPF on short notice.

The overall goal and objective of the POC is to identify a solution that:

Demonstrates core functionality of system in relation to EPPF requirements;

Has a competitive cost of ownership;

Is scalable and easy to use and administer;

Provides Strong security controls– user access, audit trails; segregation of work

space;

Provides Ease of integration with new file formats, and

Is supported by the vendor, and with an undertaking from the vendor for ongoing

development and maintenance of relevance and applicability

The successful respondent/s, if any, will be provisionally appointed subject to successful

contract negotiations, due diligence taking into consideration technical expertise, financial

strength, management, and company structure.

P a g e 16 | 69

2.9 RFP general requirements

The proposed vendor must comply with the requirements outlined in this RFP. As part of your

submission, please print and sign Appendix A – Terms of Business as a separate attachment.

2.9.1 General Requirement of respondents

Respondents must be well-established entities that have been in business for a minimum of

five years and must be able to demonstrate their experience in developing market risk models.

Respondents (legal entity) must provide supporting documentation to indicate the period of

time they have been in operation and services they have provided (including at least three

contactable client references).

2.9.2 Company details and stability

Please provide a response to each of the following questions:

i. How long the business has been in operation?

ii. What is the scope and nature of the business, paying particular attention to core

activities and highlighting areas where it lacks or outsources expertise?

iii. What is the company’s registration number?

iv. Provide details on the company structure and key project resources to be allocated

directly as well as indirectly to the management structure and the Fund’s project?

v. Provide details of commercial relationships where a consortium/joint

venture/partnership is offered as follows:

The entity that will be the guarantor of contract performance;

The date of joint venture formation, if applicable;

The name of the lead / prime contractor; and

A statement regarding the nature of the agreement between the joint venture

partners, the proposed percentage of division of work and profit between the

constituent members. Each party to the RFP, if that party is a subsidiary

company, is required to give details of the extent to which the holding

company and related subsidiaries and associates are prepared to provide

guarantees.

2.10 Supporting documentation

The respondents must include at least the following supporting documentation within their

proposals:

Proof of company registration documentation;

P a g e 17 | 69

An up-to-date Original Tax Clearance Certificate indicating good standing with

SARS;

A statement of the bidding company’s B-BBEE credentials as required in the

above, supported by a rating certificate from a recognised rating agency, if

applicable;

In the case of a joint venture the above-mentioned documentation need only be

supplied for the guaranteeing entity; and

An up-to-date Audited Financial statement of the entity that will be submitting the

proposal

Respondents will be disqualified from the RFP process if any of the above-mentioned details

and/or documents are not submitted.

2.11 Quotation/proposal conditions

Validity of Quotations Quotations must be valid for at least 90 days from the closing date of the tender. Please include

original valid tax clearance certificates, proof of registration of your business, and your latest

BBBEE certification, if you have one.

VAT VAT must be included in all prices, where applicable.

P a g e 18 | 69

Closing Date for Proposal Submission The closing date for submission of proposals at the delivery address indicated below is 03

October 2019 at 14:00 South African Time.

All submissions must be placed in the Multi-Asset Class Investment Risk Management

System Tender Box at the EPPF’s offices, in the reception area at Isivuno House, EPPF

Office Park, 24 Georgian Crescent East, Bryanston East, 2191. Shortlisted respondents will

be invited for presentations prior to making a final appointment decision.

Please note the tender box dimensions 9.5 cm by 62 cm (A single envelope with all

submissions will not fit-separate clearly identified envelopes may be used).

Enquiries

All enquiries must be forwarded to the central email address at: -

E-mail: [email protected]

Note that only written queries will be answered. The Fund reserves the right to withdraw, at

any stage of this process, amend or cancel this RFP, reject or not accept any or all proposals,

obtain any information from any lawful source regarding past business history and practices of

the respondent, and to take any such information into consideration in the evaluation process.


P a g e 19 | 69

3 MULTI-ASSET CLASS RISK SYSTEM REQUIREMENTS 3.1 Background

The EPPF has, adopted a risk budget approach within the Investment Policy Statement, which

will govern the process of measuring, allocating and controlling risk across its entire

investments.

The risk budget comprises of three significant components:

• Surplus risk analysis

• Loss aversion

• Relative Risk (Tracking Error)

As a direct result of implementing the risk budget, the EPPF seeks to acquire a risk

management system that would allow it to manage and report on the risk budget in a technically

sound, prudent and complete manner.

This risk management system will also need to meet the portfolio management requirements

of the multi- management (Fund of Funds) and internal asset manager teams. These teams

manage the following asset classes (across local and international domiciled funds):

• South African Equity

• South African Nominal Bonds (Govt. and Credit)

• South African Inflation Linked Bonds (Govt. and Credit)

• South African Cash and Money Market

• South African Bond Derivatives (Futures and Options on Futures)

• Interest Rate Swaps

• Unlisted Bonds

• South African Listed Property

• South African Direct Property

• South African Private Equity

• South African Unlisted Equity

• South African Hedge Funds

• South African Fund of Hedge Funds

• South African Developmental Investments

• Global Listed Equity

• African Ex SA Listed Equity

• African Ex SA Private Equity

• African Ex SA Fixed Income

• Global Nominal Bonds (Govt. and Credit)

P a g e 20 | 69

• Global Inflation Linked Bonds (Govt. and Credit)

• Global Listed Property

• Global Private Equity

• Global Cash and Money Market

• Currency

• Currency Derivatives

• Derivatives (Exchange Traded and OTC)

• South African Exchange Traded Funds

• Global Exchange Traded Funds

• Commodity Exchange Traded Funds

• Emerging Markets Equity

These funds (some of which are pooled and others are segregated mandates) are managed

in Long only, as well as Long-Short and leveraged strategies (Hedge Funds).

The internal asset management team manages mainly Long only South African and African

domiciled assets (all assets stated above), although derivatives and currency positions will be

implemented from time to time.

3.2 RFP response objectives

The objectives of this RFP and the responsibilities of respondents are to:

• Understand the requirements of the EPPF and also providing supporting

information of a risk management system

• Demonstrate a proven track record of implementations (preferably as an

Application Service Provider (ASP)) in Emerging Markets and Africa

• Establish integration between the proposed system and the EPPF IT platform

• Ensure that the solution is hosted within a redundant hosting environment by the

respondent

P a g e 21 | 69

3.3 Project Management Capacity

In ensuring a successful rollout of the RFP and to ensure that all the business requirements of

the EPPF will be met, proper governance and project management measures must be in place

during implementation and beyond. The respondent is therefore required to provide detailed

information on project management expertise including:

i. Project management methodology and / or tools proposed including change

management to be used by the organisation for the execution of this project.

ii. Applicable quality management frameworks, standards and certifications, including

certification body, to be used for the execution of this project.

iii. The proposed approach to ensure that the project is aligned with the EPPF’s business

strategy and goals, and takes all documented stakeholder requirements into account.

iv. The proposed approach to providing leadership and gathering support (at different

organisational levels) in a bid to promote acceptance of the new solution by all key EPPF

staff and management.

v. The proposed approach to ensure the responsiveness of the proposed system to the

EPPF’s business requirements and the delivery of tangible business value by the project.

vi. The proposed approach to manage risk appropriately by overseeing the adoption and

implementation of a control framework.

P a g e 22 | 69

3.4 Project Scope

Given the above background, the EPPF envisages that the overall solution will entail the following functionality. Please indicate which modules the

respondent solution is supporting. Please include a detailed comment where the solution is only adhering to Partial or None:

REQUIRED OFFERING

SUPPORT COMMENT

Full Partial None

A – Risk Modelling And Attribution

B – Risk Attribution

C – Factor and Style Analysis

D – Portfolio Construction

E – Portfolio Optimisation

F – Simulation & Hedging

G – Scenario / What-If Analysis

H – Stress Testing

I – Asset And Liability Analysis

J – Back-Testing

K – Reporting

L – Risk Management Capability in:

Credit Risk

Market Risk

M – Market Data

Where a respondent is only bidding for a component of the solution, they should clearly indicate in the above, which components they are bidding for.

Relevant to the requirements provided above, reference must be made to the sections below where the detailed functionality is explained.

P a g e 23 | 69

Respondents are required to provide their responses in the tables provided. Include a full description of how the solution supports the stated

requirement. The ability of the solution to meet or support the requirement is based on the following scale:

• Full – refers to the solution having the ability to completely support the requirement “out-the-box”.

• Partial – refers to the solution requiring some configuration to support the requirement. In the case of a “Partial” fit, indicate the percentage fit of

the solution to meet the requirement before any configuration is performed.

• Custom – refers to the solution requiring customisation, additional costs or third party interfaces to support the requirement. In the case of a

“Custom” fit, indicate the percentage fit of the solution to meet the requirement before any custom development is performed.

• None – refers to the solution not being able to support the requirement.

The proposed solution must enable the functional requirements that are contained in the tables below.

P a g e 24 | 69

3.5 Support and Maintenance

The respondent must provide details of its support and maintenance services capabilities within the response times as defined in the table below.

Respondent is required to provide their responses in the tables provided. Include a full description of how the solution supports the stated requirement.

The ability of the solution to meet or support the requirement is based on the following scale:

• Full – refers to the respondent having the ability to completely support and meet the requirement.

• Partial – refers to the respondent not completely supporting the requirement. In the case of a “Partial” fit, indicate the percentage fit of the vendor

supporting the requirement.

• None – refers to the vendor not being able to support the requirement.

Priorit

y

Code

Description of Code

Response Time

Resolution Time

Meet Requirement?

Full Description

of Requirements

Met

Full

Partial

None

1

Emergency – user site

operations are at a

standstill

Respond to call

within 1 hour

Solve problem within

mutually agreed upon

deadline (between

client and respondent)

P a g e 25 | 69

Priorit

y

Code

Description of Code

Response Time

Resolution Time

Meet Requirement?

Full Description

of Requirements

Met

Full

Partial

None

2

Very Urgent – user site

still operational but

deadlines are threatened

due to certain

malfunctions

Respond to call

within 2 hours

Solve problem such

that deadline is met if

malfunction is due to

system defect

3

Urgent – user site

operations still

functioning. Solution to be

provided according to

user requirements and

deadlines

Respond to call

within 8 working

hours

Solve problem within

mutually agreed upon

deadline (between

client and respondent)

4

Not Urgent – user

deadlines should be taken

into account

Respond to call

within 2 days

Advise by when will be

able to resolve

P a g e 26 | 69

Respondents must provide replies to the questions below:

i. Can the organisation provide on-site or remote support services during normal business hours between 08h00 and 17h00 on weekdays

(South African Standard Time)?

ii. Can the organisation provide support outside the normal business hours?

iii. Can the organisation guarantee 99% system uptime, during normal business hours?

iv. Does the organisation offer customers any additional support services? If so, please supply details.

v. What service level management processes does the organisation currently have in place? Describe any frameworks, standards and

certifications, including certification body, in use at the organisation.

vi. Provide the disaster recovery methodology and approach to make sure the recovery time of 24 hours can be met.

vii. Will the organisation be able to manage one annual scheduled and unscheduled disaster recovery test?

viii. What support and maintenance activities has been included and

excluded?

P a g e 27 | 69

The EPPF reserves the right to provide for specific targets and requirements of its choice in the Service Level Agreement (SLA) and the SLA may

include provisions to address issues such as a definition of services; performance measurement; problem management; penalties, warranties; disaster

recovery, termination of agreement and desired percentage of system uptime.

3.6 Functional Requirements

3.6.1 High Level Diagram

The proposed solution will comprise of three layers

when interfacing with the risk system:

P a g e 28 | 69

• Data Integration Layer

• Reporting Layer

• Analysis Layer

The requirements for each of these layers are documented below in section 3.6.2 Functional Requirements.

This section will require a complete description and background history of the risk algorithm that underlies the proposed solution.

P a g e 29 | 69

3.6.2 Functional Requirements

The table below depicts the functional requirements needed for the risk management system.

i. Describe the algorithm methodology (ies) (Fundamental, statistical, numerical, hybrid approach) utilised in developing the proposed risk model.

ii. Describe the factors used and the explanatory value of the risk model.

iii. How often is the model recalibrated?

iv. Explain the calculation approach used to derive the underlying covariance matrix, and describe the data universe and data frequency.

v. How many risk models are built by the organisation and how do they differ (e.g. Region, currency, forecast horizon)?

vi. Is the data cleaning for the models managed in-house or outsourced?

vii. What approach is utilised to decompose systematic and specific risk elements?

viii. Does the respondent have a multi-asset risk model that can be used for South African managers?

ix. Is the risk model explicitly built for the South African model (using ZAR based calibration)? How is this model different?

x. Provide evidence of the risk estimation quality of the risk model as applied in South Africa for individual asset types covered by the model. (i.e.

3, 6, 12 month estimated risk vs. actual)

xi. Outline strengths and weaknesses of the proposed risk approach.

P a g e 30 | 69

Requirement

Support Full Description of How

Functionality Meets Requirements

Full

Partial

Custom

None

xii. Ability to build own models?

xiii. Does the system manage long-short and leveraged strategies?

xiv. Data Coverage:

a. South African Equity

b. South African Nominal Bonds (Govt. and Credit)

c. South African Inflation Linked Bonds (Govt. and Credit)

d. South African Cash and Money Market e. South African Bond Derivatives f. Interest Rate Swaps g. Unlisted Bonds

h. South African Listed Property

i. South African Direct Property

j. South African Private Equity

k. Global Listed Equity (Including Emerging Markets)

l. African Listed Equity m. African Credit

n. African Private Equity

o. Global Nominal Bonds (Govt. and Credit)

p. Global Inflation Linked Bonds (Govt. and Credit)

q. Global Listed Property

r. Global Cash and Money Market

s. Currency & Currency Derivatives

t. Derivatives (Exchange Traded and OTC)

Outline other asset classes covered.

P a g e 31 | 69

Requirement



Full

Partial

Custom

None

xv. Fund “Look Through”

a) Does the system manage Fund of fund or Fund of Hedge Funds and other hierarchy structures? Can this be user defined?

b) If a composite portfolio is loaded, is the risk calculated on the look through assets or the composite attributes? E.g. ETF’s

c) Can the system do fund look through to underlying instrument (derivatives, ETF's, mutual funds, unitised portfolios etc.)

xvi. Describe the instrument types covered in your system. e.g. Swaps, Forward, Futures below). Describe methodology and approach

xvii. Does the system allow for user-defined instruments and to set up proxies? Describe methods and data required to define this process.

xviii. Does the system allow portfolio composites to be imported? Describe methods and data required to define this process.

xix. Describe the different methods that can be used to generate custom reports. Where these are separate modules please indicate.

xx. Can the covariance matrix be extracted?

xxi. Can data embedded within the system be extracted? Describe any specific terms and conditions that may be applicable for reporting this data in external reports.

P a g e 32 | 69

Requirement



Full

Partial

Custom

None

xxii. Calculation of Risk Metrics:

a. Volatility

b. Ex-ante Tracking Error

c. Duration (Effective, Macaulay, Modified)

d. Convexity

e. Skewness

f. Kurtosis

g. Correlation

h. Beta

i. Surplus Risk

j. Value at Risk (VaR)

k. Modified Value at Risk (MVaR)

l. Estimated / Expected Tail Loss (ETL)

m. Conditional Value at Risk (CVaR)

n. Modified Expected / Estimated Tail Loss (METL)

o. Greeks (Delta, Gamma, Vega, Theta, Rho)

Describe the different calculation approaches available where relevant. Where relevant describe options to parameterise metrics (horizon, confidence level etc.).

P a g e 33 | 69

Requirement



Full

Partial

Custom

None

xxiii. Provide a list of metrics available in the system not listed above. Provide supporting technical definition, and the calculation formulae.

xxiv. List the factors, including risk factors, and style exposures that can be measured. Provide the definitions used for the factors and styles listed.

xxv. Can user defined styles be managed?

xxvi. What risk attribution methods are available in your system? a. position-based risk attribution b. factor based risk attribution

xxvii. Does the system perform robust optimisation?

xxviii. Can the system optimise multiple assets simultaneously? Describe limitations.

xxix. What metrics can be optimised?

a. Volatility

P a g e 34 | 69

Requirement



Full

Partial

Custom

None

b. V@R

c. CV@R

d. Surplus at Risk

e. Other?

xxx. Can a user-defined objective function be embedded in the optimisation? Describe framework and limitations. Describe operational process to do this.

xxxi. Can trade costs be minimised as part of the optimisation?

xxxii. Describe the difference in portfolio outcomes when optimising tracking error based on expected returns vs. expected rankings.

xxxiii. Can penalty functions be applied to:

a. Instruments

b. Sectors

c. Asset classes

Can an asset portfolio be optimised to a liability?

xxxv. Can optimise a long short portfolio? Which assets? Multi-asset class?

xxxvi. Can optimise a leveraged portfolio? Multiple gearing? Asymmetric gearing?

xxxvii. Can a portfolio be optimised to a set of factor or style exposures?

xxxviii. Can a fund of funds be optimised (e.g. fund holdings or weight allocation to funds or any other metric)?

xxxix. Does the system analyse and recommend hedging options to limit

xxxiv.

P a g e 35 | 69

Requirement



Full

Partial

Custom

None

identified risks?

xl.

Are historic stress tests available in the model? Please describe how historic tests are translated to current portfolios.

xli.

Describe how global historic events are captured specifically for the South African market? Have they been tested for applicability? Provide examples.

xlii.

Describe the scenario-testing framework available for each asset class

(i.e. how you build scenarios and what factors, styles, instruments, curves, etc. can be tested).

xliii.

Can the system generate Monte-Carlo simulation paths? Describe methods used for such paths.

xliv.

Does the system allow for recourse based optimisation and simulation?

xlv.

Expand on the approach used to derive yield curves for the South African market.

a. Nominal

b. Real

xlvi.

Describe how MTM curves may be loaded and managed by the system.

xlvii.

Does system cater for uploading own yield curves and using these in discounting these cash flows or liability stream for use in modelling and analysis?

xlviii.

Describe how liability portfolios may be loaded and maintained in the system.

P a g e 36 | 69

Requirement



Full

Partial

Custom

None

xlix. Describe any specific tools within your system that measures, aggregates, decomposes, attributes, simulates or hedges asset to liability risk.

l. Are the scenario and stress tests available for liability portfolios and benchmarks?

li. Describe the tools available in the system for through time analysis of metrics.

lii. Describe the tools available in the system for back testing of strategies.

liii. Describe the capability of the system’s :

a. Excel add-in

b. Modelling API

liv. Can the system exclude single securities/sectors or apply constraints to calculations

lv. Where is the risk calculation taking place (on the client, server, and ASP solution)?

lvi. Ability to provide drill down capabilities of risk figures.

lvii. Ability to perform risk calculation and display of key figures on different aggregation levels.

lviii. Ability to exclude single securities from calculations.

lix. Ability to aggregate and drill down between portfolio hierarchies.

Display risk contribution of positions to entire risk on the selected hierarchies.

P a g e 37 | 69

Requirement



Full

Partial

Custom

None

lx.

Does the system allow for risk management, analysis or modelling against cash flow or liability stream benchmarks?

lxi.

Does the system do risk calculations on ex-ante or forward looking basis?

lxii.

Does the system do risk calculations on ex-post basis?

lxiii.

Does the system provide connectivity to benchmark providers? If yes, please provide a list of these providers

lxiv.

Can hierarchies of benchmarks (blending) be constructed?

lxv.

Can funds be used as a benchmark?

lxvi.

Please describe the process of creating customized benchmarks.

lxvii.

Calculation of other metrics:

a) Active Share b) Turnover Analysis.

lxviii.

Credit Risk Please outline your solution in terms of how it would assist the Fund

with assessing risk of default on a fixed income security (whether

nominal or inflation-linked) (on either the coupons or the redemption),

the restructuring of any terms of the fixed income security (which is

usually also considered a default), or the downgrading of the credit

rating of a fixed income security. Any and all of these events will have a

negative impact on the price of the bond, assuming all else remains the

same i.e. ignoring the impact of changes to yields on the highest rated

bonds.

P a g e 38 | 69

3.7 Non-Functional Requirements

The EPPF endeavors to continue providing high quality customer service and a robust solution is crucial for this. The EPPF aims to minimise manual

interventions in administration processes.

3.7.1 Scalability

The system must be scalable and should therefore be based on modern, but well-proven, architecture and technology.

Requirement

Full description of how requirement is met

i. Please provide full details of the value-add service including all security features applicable (e.g. hosting)

ii. What are the migration tools that are available with your product for the migration from one environment to other (i.e. UAT to production...etc.).E.g.: Parameter mappings, constraints etc.

iii. Please detail future enhancements in the pipeline along with timelines for release

iv. Describe the split between the presentation, business and data access layers of your system and the logic

v. Is there access to the database and data model? What access controls are required? Is there an up-to-date database schema describing where data is stored available?

vi. Is the system built to industry standards such as Microsoft Foundation Class (MSFC), .Net, Java SE and J2EE?

vii. Do you use any data file compression techniques in order to optimise disk storage?

P a g e 39 | 69

3.7.2 Security

The EPPF has strict requirements relevant to the security of any proposed system, in order to ensure the preservation of the confidentiality, integrity

and accuracy of information. These requirements encompass ensuring that information is accessible only to those authorised to have access, safeguarding

the confidentiality of member information.

i. Comment on the proposed system’s security architecture.

ii. What encryption level is applied around database and application passwords?

Requirement

Support Full description of how requirement

is met

Full

Partial

Custom

None

iii. System must not store passwords and other authentication information in clear text on client side or server side.

iv. System must not utilize hard-coded accounts/passwords

v. Modification of system logs must be prevented by the system.

vi. Application level logins and passwords handled differently to database level logins and passwords.

vii. Periodic password changes must be enforced, e.g. users are forced to change their passwords every 30 days? Is this configurable?

viii. System must have the ability for a user to reset their password.

ix. System must have the ability to 'lock-out' a user after a pre-determined number of unsuccessful login attempts.

x. Can the system automatically log users out after 'N' minutes of system inactivity?

P a g e 40 | 69

xi. Can the system be set to control the password structure (i.e. minimum of 8 alphanumeric characters within the password, case sensitivity, no banned words, etc.)?

3.7.3 System Response Time and Availability

i. What is the maximum system downtime allowed within your SLA for your hosted solution?

Requirement


is met

Full

Partial

Custom

None

ii. Is system data available to users 100% of the time on a real time basis during business hours?

iii. Is the system available on weekdays during non-core business hours and weekends?

iv. Can system maintenance that encompasses scheduled downtime be announced in advance?

v. Is the system available during backups?

P a g e 41 | 69

3.7.4 Support

In order for the EPPF to sustain efficient customer service, the successful solution provider will be required to provide the service level that sufficiently

supports the EPPF’s business at an optimal fee structure. A Service Level Agreement (SLA) will be signed to record a common understanding of desired

support services, priorities, responsibilities and guarantees and may specify the levels of availability, serviceability, performance, operation and other

attributes such as penalties in the case of violation of the SLA.

i. Respondents must indicate what service level management processes their organisations currently have in place.

Requirement


is met

Full

Partial

Custom

None

i. Is support available during office hours?

ii. Does the system provide documentation of system and support processes?

iii. Does the system provide support documentation outlining: a. escalation procedures

b. format and frequency of system archives

c. responsibilities of each support group within technology operations

P a g e 42 | 69

3.8 Technical Requirements

3.8.1 System Architecture Requirements

i. Respondents must provide a separate high level application diagram and technical architecture diagram, including system workflow architecture and integration to other systems.

3.8.2 System Requirements

i. Explain the change control process in relation to system updates and model recalibration and sign off process thereof

Requirement


is met

Full

Partial

Custom

None

ii. Application Service Provider solution – The solution is hosted and supported outside EPPF

iii. Can the system have segregation of data / work space for different users or teams?

iv. Does the system have the ability to provide audit reporting?

v. Does the system have a special role for auditing of administrator's actions?

vi. Does the system provide that all changes in data / risk parameters can be tracked to identify who/when changed the data and which attributes were changed (audit trail).

vii. Does the system have user interface to query audit trails?

viii. Does the system have the ability to execute processes automatically?

P a g e 43 | 69

3.8.3 System Documentation

Respondents must indicate if the following documentation is available:

Requirement


is met

Full

Partial

Custom

None

i. System Architecture outlining:

a. Hardware layout

b. Software components layout based on hardware layout

c. Software components interactions schema including protocols and IP Ports information

ii. Third party products / components used in the proposed system

iii. Installation Guide

iv. Administrator Guide (include backup/restore procedure and data archiving)

v. User Guide

vi. User interface to support context-sensitive help (“F1” button)

vii. API documentation

P a g e 44 | 69

3.8.4 Reporting

Requirement


is met

Full

Partial

Custom

None

i. Does the system have a reporting engine / portal?

ii. Does the system provide standard reports? Please describe and give examples of different report types and indicate which ones have graphing capability.

iii. Is the reporting engine extendable and can users design / customise their own report?

iv. Is the reporting engine working on the online database?

v. Can reports being triggered by on demand, on event, by schedule?

vi. Can the system generate standard reports in PDF format? Provide details.

vii. Can the system generate standard reports in XLS format? Provide details.

viii. Can the system generate standard reports in XML format? Provide details.

ix. Can the system generate reports stemming from an integration layer i.e. multiple system have been integrated?

P a g e 45 | 69

3.8.5 Integration

Requirement

Support Full description of how

requirement is met

Full

Partial

Custom

None

i. The system provides supported integration facilities.

ii. The system has functional areas available through API.

iii. Does the system support Web server platforms?

iv. Can data be loaded into the system and handle exceptions? Describe the process of importing data (fund holdings, benchmark, instrument static data)

v. The system has the ability to map new data formats (fund benchmarks and instrument static) to external systems without vendor involvement.

vi. Does the system have standard interfaces to market data providers available?

vii. Does the system provide the functionality to accept real-time market data?

viii. Is the statistical library available in Microsoft Excel?

ix. Does the system have the ability to integrate with the StatPro Benchmark file format?

x. Does the system have the ability to integrate with the Maitland Investment Administration Service?

P a g e 46 | 69

3.8.6 Hardware Requirements

i. Describe all client hardware (front-end) requirements necessary to operate the proposed solution (platform, processor, memory, hard disk).

Include minimum supported hardware (processor, RAM, disk).

ii. Describe how the proposed solution operates in a cloud environment / data centre.

iii. Describe all server hardware requirements for development, test and production system (platform, processor, memory, hard disk).

iv. Describe how the proposed solution integrates to mobile devices (tablets etc.) including security.

3.8.7 Additional Software Requirements

i. Describe all server software requirements.

ii. Describe all client software requirements.

iii. Describe how the system is deployed to users (local install, browser, citrix, etc.).

iv. What software (including version number) is the package written in?

v. What database systems does the package support (include version numbers)?

vi. What database functionality does the system support and use (e.g. tables only, triggers, stored procedures, user-defined types, etc.)?

3.8.8 Connectivity

i. Describe the client / server connectivity mechanism, including which standards are utilised or supported.

ii. Describe database and application connectivity or middleware requirements both for the application server(s) to connect to the database

server(s) and the client application to connect to the database server(s). Include protocol (i.e., ODBC, JDBC) and tool (i.e., SQL/Net) if applicable.

P a g e 47 | 69

3.8.9 Network

i. Describe how the system support clients connecting to the server from outside the client network via the internet.

ii. Describe the required network infrastructure.

iii. Specify the bandwidth requirements for optimal operation between server components and client workstations.

iv. Provide a system diagram showing major components of the solution / application / system and the network traffic between each. Include

the database server(s), application server(s), reporting server(s) and client system(s).

P a g e 48 | 69

3.8.10 Web Technology

Requirement


is met

Full

Partial

Custom

None

i. The system components / functionality of the proposed solution are web enabled? If so describe which ones.

ii. Does the proposed system design use an Application Server Technology? If so specify the Application Server(s).

iii. Does the proposed solution utilise a Secure Socket Layer protocol for transmitting requests and documents over the web?

iv. What web infrastructure technologies does the proposed solution integrate with? Describe methods to integrate with existing Intranet infrastructure.

3.8.11 Business Continuity, Backup and Disaster Recovery

Requirement


is met

Full

Partial

Custom

None

i. Does the solution provide automatic and regular data backups?

ii. Does the solution manage partial and full backups?

iii. Does the solution have a mechanism for backup deletion protection?

iv. Do these tools perform backup and recovery of transaction data, logs, and system information (e.g. user IDs, passwords, etc.)?

v. Can the proposed solution interface with third party backup and recovery tools?

P a g e 49 | 69

Requirement


is met

Full

Partial

Custom

None

vi.

Does the solution support performing system backups while users are connected to the system and processing transactions?

vii.

Does the solution cater for disaster recovery? If so, confirm if the level of DR location is certified and describe the tools and mechanisms provided for disaster recovery.

P a g e 50 | 69

3.9 Hosting

The EPPF requires the solution to be hosted at the respondent’s premises or hosting

facilities. The primary WAN connection is a fibre connection with bandwidth capacity

of 20Mbps.

The primary link is complimented with redundancy links to Neotel fiber (10

mbps) . Given these requirements:

i. Provide details of the infrastructure and ability to host the solution. In

particular, detail the environment in which the solution will be hosted.

ii. Indicate if clients are able to select their own independent ASP / Hosting data

centre site and infrastructure provider.

iii. Describe bandwidth requirements to enable acceptable system response times and

stability.

iv. Describe any communication link security measures that will be put in place to

ensure a secure connection to the EPPF from your hosting environment.

v. Describe how the system will be configured to segregate the EPPF’s data from

any other customer’s data.

vi. Describe how ASP / Hosted service will be delivered? (Leased line, VPN, etc.)

vii. Indicate whether hardware and/or disk space is shared amongst clients.

viii. Describe how available disk space is monitored.

ix. Describe whether the proposed ASP solution is different in any way from the

installed solution. Is there any reduction in functionality?

x. Indicate if there are any limitations with the proposed service that may prevent a

client accessing their own data for report writing and data extraction purposes.

xi. Indicate whether the respondent company owns and controls its own ASP / Hosting

data centre site and infrastructure, or is space rented from another organisation

(that might offer general hosting facilities).

xii. Indicate whether the ASP / Hosted service manages its own firewall or does it

use a managed firewall service from another service provider.

P a g e 51 | 69

xiii. Indicate if the firewall uses authentication (i.e. a digital certificate).

xiv. Indicate if the firewall works in tandem with an IDS (Intrusion Detection System)

so that it is able to respond to attempted intruder break-ins.

xv. Indicate whether as part of the proposed ASP service, a service to manage

resolutions on data integrity exceptions is offered.

3.10 Implementation

Respondents are required to detail their approach to the implementation, providing particular

information relevant to the timeframes and change management aspects of implementation.

Please ensure that the implementation contract is separate from the maintenance and support

contract.

3.10.1 Approach

i. Describe how the organisation would approach this implementation, please detail

the phases involved.

ii. Indicate if the proposed support agreement prevents clients from using the

services of an independent third party, to implement the proposed system.

iii. Give a high level overview of the System Development Life Cycle (SDLC) for the proposed

solution, paying particular attention to the implementation and support phases.

iv. Comment on the approach to application testing, in particular unit, system and integration

testing.

v. Comment on the approach to user acceptance testing.

vi. Comment on the approach to skills transfer and end-user training.

vii. Describe the resources available from the organisation as well as required from the

EPPF to be dedicated to this project.

P a g e 52 | 69

3.10.2 Timeframes

i. Provide details of the estimated length of time for the implementation of the proposed

solution indicating best and worst case scenarios.

ii. Indicate high-level estimates of timelines for the activities.

iii. Provide a detailed implementation project plan.

3.10.3 Change Management

i. Provide details of how training of end users will be conducted, assuming

that at least 20 staff members would need training on the new solution.

Provide details of the extent to which technical training would allow a user or client to be self-

sufficient with regard to installing all system (i.e. application, database) components and upgrades

independently.

P a g e 53 | 69

4 MARKET DATA

For respondents who provide market data subscriptions in addition to the data distributed with the

risk model, please complete the section below.

The Fund uses market data time series to understand market dynamics and structure. Perform

portfolio revaluations and to keep track of corporate events in the market. By combining portfolio

data and trading statistics, an interactive model can show the percentage of the portfolio that can

be either liquidated or traded to benchmark, over a given number of days. The market data will

also list the most illiquid stocks. Structural portfolio liquidity issues can now be understood for

individual holdings. Benchmark data will be used in performance attribution and portfolio

modelling framework.

The Investment Research Process consists of various iterative steps, and the investment research

analyst is responsible for using historic data obtained from published reports to build a view on the

company and to forecast future earnings to make an investment recommendation on the company.

Fundamental data will be used to build financial forecast models and economic data will be used

to simulate future asset returns.

4.1 Market Stats and Pricing

Description Yes / No

South African Listed Instruments (all asset classes) – Live Pricing Feeds

Yield Curves (Nominal, Swap, Zero, Money Market, Inflation/Real)

South African Volatility Curves

Actual Earnings, Corporate Action and Dividend Schedules

EOD SA Market stats (Equities, Bonds, Listed Derivatives)

EOD African Market stats (Equities, Bonds, Listed Derivatives)

South African Unlisted Fixed Income and Money Market (Terms & Conditions)

Global Listed Instruments (all asset classes) – Delayed Pricing Feeds

P a g e 54 | 69

4.2 Fundamental Accounting data, Estimate, Ownership & ESG


South African Listed Instruments (Equities) – (Income Statement, Balance Sheet, Cash Flow,

Statement of Ownership)

African Countries Listed Instruments (Equities) – (Income Statement, Balance Sheet, Cash

Flow, Statement of Ownership)

Shareholder Registers

ESG analysis for top 160 South African Listed Instruments by Market Cap

4.3 Credit Ratings (Major Agencies)


Global Fixed Income Instruments

South African Fixed Income Instruments

South African Money Market Instruments

South African Listed Equities

African Countries Listed Equities

4.4 Benchmark Data (Constituent Level Data)


End of Day Specialist Indices End User Fees - Shareholder Weighted Indices (SWIX) 10 -25

users (EPPF has a data license agreement in place with JSE)

End of Day Specialist Indices End User Fees - Capped Indices (EPPF has a data license

agreement in place with JSE)

End of Day Core Indices Designated End User Fees - Constituent and Tracker (EPPF has a

data license agreement in place with JSE)

ALBI

GOVI

CILI

MSCI World All Countries Index

MSCI Emerging Markets

Barclays Global Aggregate Bond index

MSCI EFM Africa Ex-South Africa Index

P a g e 55 | 69

4.5 Economic Data

Description Yes / No World Bank Real GDP per capita

Major Economies - Gross Domestic Product

Major Economies - Inflation

Major Economies - Central Bank Lending Rate

Regional - GDP

Regional - Inflation

South Africa

GDP

CPI

CPIX

PPI

Unemployment Rates

Population

Manufacturing

Consumer Confidence

Exports

Imports

Direct investments

Prime Lending Rate

Repo Rate

4.6 Commodities

Description Yes / No Copper

Aluminium

Nickel

Gold

Platinum

Silver

Paladium

Vanadium

Uranium

Brent Crude oil

Steel

Iron

P a g e 56 | 69

Zinc

Aluminium

Lead

Tin

Brent Spot

Brent Sweet oil

Light Crude oil

Heating oil

Natural Gas

Paper

White Maize

Yellow Maize

Barley

4.7 Exchange Rates

Description Yes / No USDNZD (United States Dollar/New Zealand Dollar)

USDDKK (United States Dollar/Danish Krone)

USDNKK (United States Dollar/Norwegian Krone)

USDSEK (United States Dollar/Swedish Krona)

USDCNY (United States Dollar/Chinese Yuan

USDHKD (United States Dollar/Hong Kong Dollar)

USDINR (United States Dollar/Indian Rupee)

USDSGD (United States Dollar/Singapore Dollar)

USDKRW (United States Dollar/South Korean Won)

USDRUB (United States Dollar/Russian Rouble)

USDTRY (United States Dollar/Turkish Lira)

USDARS (United States Dollar/Austrian Schilling)

USDBRL (United States Dollar/Brazilian Real)

USDBWP (United States Dollar/Botswana Pula)

USDCDZ (United States Dollar/Dem.Congo Zaire)

USDEGP (United States Dollar/Egyptian Pound)

USDGHC (United States Dollar/Ghanain Cedi)

USDKES (United States Dollar/Kenyan Shilling)

USDMWK (United States Dollar/Malawian Kwacha)

USDMUR (United States Dollar/Mauritius Rupee)

USDNGN (United States Dollar/Nigerian Naira)

USDTZS (United States Dollar/Tanzanian Shilling)

P a g e 57 | 69

Description Yes / No USDUGS (United States Dollar/Ugandan Shilling)

USDZMK (United States Dollar/Zambian Kwacha)

USDZWD (United States Dollar/Zimbabwean Dollar)

USDSAR (United States Dollar/Saudi Arabian Riyal)

USDZAR (United States Dollar/South African Rand)

EURZAR (European Euro/South African Rand)

JPYZAR (Japanese Yen/South African Rand)

GBPZAR (British Pound/South African Rand)

CADZAR (Canadian Dollar/South African Rand)

AUDZAR (Australian Dollar/South African Rand)

CHFZAR (Swiss Franc/South African Rand)

EURUSD (European Euro/United States Dollar)

USDJPY (United States Dollar/Japanese Yen)

GBPUSD (British Pound/United States Dollar)

USDCAD (United States Dollar/Canadian Dollar)

AUDUSD (Australian Dollar/United States Dollar)

USDCHF (United States Dollar/Swiss Franc)

EURJPY (European Euro/Japanese Yen)

EURGBP (European Euro/British Pound)

EURCHF (European Euro/Swiss Franc)

4.8 Index Data

Description Yes / No South African Volatility Index

VIX Index

CILI

1 - 3 Year CILI Index



12+ Year CILI Index

Barclays Capital Inflation Linked Bonds (ILB) Index

Barclays 1 - 3 Year ILB Index



Barclays 10 + Year ILB Index

Barclays 15 + Year ILB Index

All Bond Index

P a g e 58 | 69

Description Yes / No 1 - 3 Year Bond Index

3 - 7 Year Bond Index

7 - 12 Year Bond Index

12+ Year Bond Index

Govi

Alexander Forbes Money Market Index

Short Term Fixed Interest Index (STeFI)

Call Deposit Index

3 Month NCD Index

6 Month NCD Index

12 Month NCD Index

MSCI World Equity

JPMorgan Commodity Curve Index family (‘JPMCCI’)

Hedge Fund - Fund of Funds Index

Hedge Fund - International Index

Hedge Fund - Emerging Markets Index

Hedge Fund - Convertible Arbitrage Index

Hedge Fund - Event Driven Index

Hedge Fund - Fixed Income Arbitrage Index

Hedge Fund - Global Macro Index

Hedge Fund - Long / Short Index

Hedge Fund - Managed Futures Index

Hedge Fund - Absolute Return Index

All Share Index

Capped SWIX All Share Index

Top 40 Index

Capped All Share Index

Resources Index

Industrials Index

Financials Index

JSE Large Cap Index

JSE Mid Cap Index

JSE Small Cap Index

US Dow Jones Industrials

UK - FTSE 100

Japan

Hang Seng

P a g e 59 | 69

Description Yes / No S&P 500 (TR)

Nasdaq Composite

CAC Quarante

Xetra Dax

Citi WGBI

JP Morgan

SA Listed Property

SA Unlisted (IPD) Property

Africa Property Loan Stock

US Citi 3 month T Bill

Flemming Aggregate Bond Index

Botswana Domestic Companies

MSCI AC Asia

MSCI AC Asia Pacific

MSCI AC Far East

MSCI AC Pacific

MSCI Golden Dragon

MSCI Zhong Hua

MSCI AC World

MSCI AC World Excluding South Africa

MSCI AC Americas

MSCI AC Europe

MSCI World Excluding South Africa

MSCI EAFE + EMF

MSCI European

MSCI Pan-European

MSCI Emerging markets

MSCI Developed Markets

MSCI North America

MSCI Onshore China A

Dow Jones Global Titans

Dow Jones Asian Titans 50

Dow Jones BRIC 50

Russell 2000

Russell 3000

Dow Jones Euro Stoxx

Dow Jones Euro Stoxx 50

P a g e 60 | 69

Description Yes / No S&P Global 1200

Dow Jones WillShire 5000

JPMorgan Global Bond Index Broad

JPMorgan Global Government Bond Index

JPMorgan EURO EMBI Global Index

JPMorgan Emerging Markets Bond Index

FTSE European Emerging Markets Bond Index

FTSE Eurozone Government Bond Index

JP Morgan Emerging Markets

Merrill Lynch Global Government Index

Merrill Lynch Global Government Inflation-Linked Index

Merrill Lynch Global High Yield Index

FTSE All Share Index

CAC All Shares Index

FTSE/JSE Capped SWIX

FTSE/JSE All Property Index

FTSE/JSE SWIX40

P a g e 61 | 69

ANNEXURE A

TERMS OF BUSINESS

1. Background

The Fund wishes to appoint a suitable service provider to provide a multi-asset class

investment risk system.

The Terms of Business below serve to set out the minimum terms proposed by the Fund for

any agreement to be concluded with the preferred service provider. The final terms will be

subject to negotiation with the preferred service provider, if appointed by the Fund.

2. Terms of Business

These Terms of Business will form the basis of a suitable Main Agreement to be negotiated

and concluded between the Fund and the successful service provider. Such an agreement

will detail the services to be rendered and other associated terms governing the relationship

between the parties.

3. The services to be provided

3.1. The Services

The service provider will provide the services described in the RFP, and at the location(s)

to be set out in the Main Agreement.

Where the Main Agreement refers to services to be performed this means that the service

provider will provide the Fund with the Services and will be responsible for the

management and control of the services and the quality of any deliverables listed in or

referred to in the Main Agreement.

Where the Main Agreement refers to Services to assist the successful service provider this

means that the Fund will use reasonable skill and care, as specified, to assist the service

provider with its work, but the service provider will be responsible for the overall

management and control of the Services and for the results to be achieved from using the

Services.

P a g e 62 | 69

3.2. The service provider’s staff

Where individual members of the service provider’s staff (including partners and directors)

are named in the Main Agreement the service provider will make every reasonable effort

to ensure that the named individual(s) are available to support its work for the Fund stated

in the Main Agreement.

Where the service provider considers changes in its named staff necessary or appropriate,

for reason of, inter alia, resignation, relocation, training or illness, the service provider may

make the changes after giving the Fund reasonable notice and will provide the Fund with

details of replacement staff.

3.3. Contract Management

Both parties may designate a contact person that will be responsible for managing all

issues relating to the performance of the Main Agreement.

3.4. Deliverables

3.4.1. Preparation and Delivery

The Fund will incorporate the deliverables listed or referred to in the RFP into the

Main Agreement to be signed with the preferred service provider.

4. Fees and Payment

4.1. Payment of services

The Fund agrees to pay for the Services as set out in the Main Agreement.

All invoices will be payable within thirty days from date of receipt thereof.

5. Term, Suspension and Termination

5.1. Duration of Contract

The Main Agreement will apply from the Commencement Date stated, or where no

Commencement Date is specified, from the date of signature of the Main Agreement by

both parties. The Main Agreement will continue until all the Services and deliverables have

been provided unless it is terminated earlier in accordance with the terms set out below.

P a g e 63 | 69

5.2. Termination of the Contract

Unless stated otherwise in the Main Agreement, the Contract may be terminated by either

party at any time by giving the other party no less than 30 days written notice.

5.3. Termination for Breach of Contract

The Main Agreement may be terminated by either party by written notice with immediate

effect if the other commits a material breach of any term of the Main Agreement that is not

remedied within 10 days of dispatch of a written request to remedy the same.

5.4. Termination for Insolvency

The Main Agreement may be terminated by either party by written notice in the event that

the other party is unable to pay its debts or has been placed under administration, judicial

manager, liquidator or similar person or officer appointed or compromises generally with

its creditors or ceases for any other reason to carry on business or in the reasonable

opinion of the other party any of these events appears likely.

6. Confidentiality and Conflicts of Interests

6.1. By signing the Main Agreement, each party is under a professional obligation not to

disclose to a third party any information confidential to the other party. Similarly, reports

by the service provider are for the use of the Fund alone and may not be disclosed to

third parties without the Fund’s prior written consent.

6.2. Notwithstanding 6.1 above, either party will be entitled to disclose confidential information

of the other to a third party to the extent required by law or where the said information is

already known to the public, provided that in the former case (and without breaching any

legal requirement), where reasonably practicable not less than five business days’ notice

in writing is first given to the other party.

7. Liability

7.1. The service provider shall use reasonable skills and care expected from an expert in its

industry in the provision and delivery of the services and the deliverables in terms of the

Main Agreement.

7.2. The service provider shall accept liability to pay compensation for damages and losses

arising as a direct result of breach of contract or negligence on its part or third parties

acting on behalf of the service provider in respect of Services provided in connection with,

or arising out of the Main Agreement (or any variation or addition thereto).

P a g e 64 | 69

7.3. The service provider shall not be liable for any loss, damages, costs or expenses directly

or indirectly incurred as a result of information supplied by, or misrepresentations, gross

negligence, fraudulent acts or default on the part of the Fund, its directors, employees,

contractors or agents. The Fund indemnifies the service provider and holds it harmless

against all and any such claims made against it in respect of any such loss, damages,

costs or expenses and against the actual costs incurred by the service provider in

defending such claims.

8. General

8.1. Force Majeure

Neither of the parties to the Main Agreement will be liable to the other for any delay or

failure to fulfill obligations caused by circumstances beyond its reasonable control.

8.2. Assignment

Neither of the parties to the Main Agreement may cede, assign, delegate, transfer,

encumber, charge nor otherwise seek to deal in any of its rights or obligations under the

Main Agreement without the prior written consent of the other party.

8.3. Notices

Notices must be served either personally, sent by prepaid registered post or faxed to

the address of the other party given in the Main Agreement or to any other address as

the parties may have notified during the period of the agreement. Any notice sent by

registered post will be deemed to have been delivered 10 days after sending. Any

notice sent by fax or served personally will be deemed to have been delivered on the

first working day following its dispatch.

P a g e 65 | 69

8.4. Amendment

Any amendment or consensual variation, cancellation or termination of the Main

Agreement, or any of its terms, will not be effective unless agreed in writing and signed

by both parties.

8.5. Survival

The confidentiality clause in the Main Agreement shall survive the termination or expiry

of the agreement and shall continue to bind the parties to the agreement.

8.6. Electronic Communications

During the provision of the Services, the Fund may from time to time communicate

electronically. However, as the service provider is aware, the electronic transmission

of information cannot be guaranteed to be secure or error -free and such information

could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or otherwise

be adversely affected or unsafe to use.

Accordingly, whilst the Fund carries out commercially reasonable procedures to check

for the most commonly known viruses and to check the integrity of data, it remains the

service provider’s responsibility to carry out a virus check on any documents before

launching them, whether to be sent or to be received on disk or otherwise. Therefore

and notwithstanding any collateral contract, warranty or representation, the Fund will

have no liability to the service provider on any basis, whether in contract, delict

(including negligence) or otherwise, in respect of any error or omission arising from or

in connection with the electronic communication of information to or from the service

provider and the service provider’s reliance on such information and including (but not

limited to) the acts or omissions of the relevant service providers.

P a g e 66 | 69

If the communication relates to a matter of significance on which the service provider

wishes to rely and is concerned about the possible effects of electronic transmission,

the service provider should request a hard copy of such transmission from the Fund.

8.7. Validity of contract Provisions

If any provision of the Main Agreement is held to be invalid, in whole or in part, such

provision shall be deemed not to form part of the agreement. In any event the

enforceability of the remainder of the agreement will not be affected.

8.8. Conflict

In the event of any conflict between the Main Agreement and any other document that

forms part of the agreement, the Main Agreement shall prevail.

8.9. Applicability

The Main Agreement shall apply to work undertaken in relation to the service provider,

its holding company or any of its subsidiary, associated or related companies, agents

or sub-contractors providing services in terms of the agreement.

9. Dispute Resolution and Governing Law

Should any dispute arise between the Fund and the service provider, both parties will

attempt to resolve the dispute in good faith through senior-level negotiations. If the dispute

is not resolved through negotiation or mediation within a reasonable time both parties

agree that it shall be finally resolved in accordance with the rules of the Arb itration

Foundation of South Africa by an arbitrator or arbitrators appointed by the Foundation and

agreed upon by both parties.

The Terms of Business and the Main Agreement shall be subject to South African law.

P a g e 67 | 69

10. Acceptance

By signature of this document, the service provider agrees to be bound by the terms of business

contained herein, subject to such variations as may be agreed between the parties when negotiating

the main agreement.

Signed in acceptance on behalf of ………………………………………………………being duly

authorized thereto.

Signed at…………………………….on this……day of………………….2019

Name & Surname………………………………

P a g e 68 | 69

ANNEXURE B

RISK BUDGET SUMMARY

The Board has adopted a pragmatic approach to introducing risk budgets into the Fund’s IPS

framework.

There are different types of risk important at each level of Fund’s investment management and

thus different risk metrics are appropriate at each level. These measures and controls will be

calculated on an ex-ante basis using a best practice risk forecasting and simulation engine.

a. Total Fund level

i. Funding Level Risk (insufficient assets to meet liabilities) - Measures the risk of

inappropriate investment policy and strategy

ii. Expected Shortfall – Measures the risk of loss in extreme market conditions

b. Asset class level

i. Total Investment Risk (Total Tracking) - Measures the risk of ineffective

implementation of strategy

c. Portfolio level

i. Active Risk (volatility of deviation from style or benchmark) - Measures the risk of

unintended exposures or inadequate diversification

Funding Level Risk

There are several risk measures which focus on funding level risk. The Chief Investment Officer

(CIO) will report on these measures to the Strategic Investment Committee (SIC) periodically.

However, no objective levels (budgets) will be set for these metrics due to the separation of

responsibility for investment management and setting the strategic asset allocation. Therefore

results will be presented for information and use in Strategic Asset Allocation (SAA) reviews.

Metric: Funding Ratio, defined as the ratio of Fund assets to liabilities. Fund assets will be

measured at current market value. Liabilities should be calculated using the following assumption

sets:

P a g e 69 | 69

a. Mark to market (MTM)

b. Actuarial assumptions (Actuarial)

c. Risk vendor real rate curve

The Asset to Liability Volatility metric is the ex-ante measurement of the volatility of the asset

portfolio return to the liability benchmark.

The Funding Ratio will further be stress tested to understand its expected behaviour on a pre -

defined set of scenarios:

a. Historic extreme events

b. Pre-defined economic conditions

c. What-if tests

Risk of Loss

Metric: Expected shortfall, defined as the expected loss experienced in a 99% worst case market

scenarios. This will also be tested when implementing a new SAA or monitoring the imp lemented

SAA.

REQUEST FOR PROPOSAL Multi-Asset Class Investment Risk ... · 2.1 Multi-asset class risk system...

Documents

Transcript of REQUEST FOR PROPOSAL Multi-Asset Class Investment Risk ... · 2.1 Multi-asset class risk system...