central depository company of pakistan request for proposal … · 2016. 9. 7. · introduction ......

Professional Clearing Member – RFP

Sep 8, 2016

Central Depository Company of Pakistan

Request for Proposal

Implementation and Support for

Order Management System (OSM) including Trading, Risk Management and Back Office


Page 1 of 43 September 8, 2016

Table of Contents

1. Introduction ......................................................................................................... 3

2. Objective of PCM ................................................................................................ 4

3. Scope of Work..................................................................................................... 5

4. Instruction to Bidder ............................................................................................ 6

4.1. Invitation to Bid .............................................................................................. 6

4.2. Terms and Conditions for Bid and Bidders .................................................... 6

4.3. Pricing ........................................................................................................... 8

4.4. Payment Terms ............................................................................................. 8

4.5. Intimation of Award and signing of contract................................................... 8

4.6. Force Majeure ............................................................................................... 8

4.7. Project Completion Time ............................................................................... 9

5. Bidder Information Form ................................................................................... 10

5.1. Bidder Qualification Criteria ......................................................................... 11

5.2. Bio-data of the all staff of bidder assigned for development/implementation of

OMS 13

6. General Solution Requirements ........................................................................ 14

7. Functional Requirements .................................................................................. 15

7.1. OMS Trading Platform................................................................................. 15

7.2. OMS Risk Management Component ........................................................... 17

7.3. Back Office .................................................................................................. 20

8. Accessibility....................................................................................................... 23



9. Security Management ....................................................................................... 24

9.1. Critical Security Considerations .................................................................. 27

9.2. Usability Requirements ............................................................................... 28

10. Software Architecture and Design of PCM Solution ....................................... 29

11. Login Authentication and Authorization .......................................................... 33

12. IT Infrastructure of PCM Solution ................................................................... 34

13. General Requirements ................................................................................... 37

14. Training: ......................................................................................................... 39

14.1. Training and Training Materials:............................................................... 39

15. Operations and Maintenance ......................................................................... 41

15.1. Handholding Period ................................................................................. 41

15.2. Technical Support .................................................................................... 41

15.3. Support services ...................................................................................... 42



1. Introduction

In the existing legal and operational landscape of our capital markets, the Trading

Right Entitlement Certificates (TREC) Holders assume the responsibility of clearing

and settlement of trades executed on the behalf of their clients while also providing

custodial services.

It is worth noting that primary expertise of TREC Holders lies in the trading and

marketing of investment products based on securities which represents the core

business. However, in the existing model, TREC Holders has to commit substantial

resources in terms of infrastructure and human resource to offer custodial and

clearing/settlement services.

Custody and clearing/settlement services complement the trading business to an

extent but also require expertise in risk management and place significant

responsibility on each TREC Holder with respect to client assets under their custody

while exposing the TREC Holder to reputational risk in case of any malpractice by an

employee or agent. The existing legal framework, while taking into account the

sensitivity of custodial services imposes stringent regulatory requirements on the

TREC Holders including the segregation of client assets from proprietary assets and

the risk management obligations. Accordingly, TREC Holders are required to maintain

separate bank accounts to keep cash of customers deposited with them and must do

fortnightly reporting in respect of client asset segregation. In the absence of a viable

alternative of providing trading services independently of the custodial services, this

can place the small net worth TREC Holders at a disadvantage.

To address this issue, SECP has introduced a new concept of Professional Clearing

Member (PCM), an institution which can offer custodial and clearing/settlement

services to investors of small net worth TREC Holders called Trading Only Brokers

(TOs). The PCM shall not offer trading services thereby preventing conflict of interest

and addressing the concerns of TOs regarding the confidentially of client information.



2. Objective of PCM

With the promulgation of Securities Broker (Licensing & Operations) Regulations,

2016 it has been made mandatory that no person shall act or perform the functions of

security broker unless such person is licensed as securities broker, with the SECP,

under any of the following category of Securities Broker:

1. Trading Only; or

2. Trading and Self–Clearing; or

3. Trading and Clearing Broker.

The Trading Only Broker (TO) will only be eligible to execute its proprietary trades and

trades on behalf of its client(s) but cannot settle trade or keep custody of securities.

Trading and Self Clearing Broker will be eligible to execute as well as settle its

proprietary trades and trades executed on behalf of its customers and keep custody

of securities owned by it and its customers.

Trading and Clearing Broker will be eligible to execute as well as settle its proprietary

trades and trades executed on behalf of its customer and can keep custody of

securities owned by it and its customers and can also settle trades of other securities

brokers and their customer and keep custody of securities owned by other securities

brokers and their customers.

Based on the aforementioned categorization of securities broker, for Clearing,

Settlement and Asset Custody, TO will either appoint a Professional Clearing Member

(PCM) or Trading and Clearing Broker to provide custody and clearing/settlement

services.

In case where TO appoints a PCM, the PCM shall undertake custody and

clearing/settlement of all locked-in trades of TO and its Client(s) so that TO can focus

on trade related services including advisory and portfolio management of its clients.



3. Scope of Work

The scope of the current RFP is to identify an application development and

implementation partner for:

1. Design, development and rollout of a web/client based IT application for CDC for an Order Management System comprising of Trading, Risk Management and Back office including Accounting, Trading & Settlement lifecycle along with reporting and MIS functionalities.

2. Supply and installation of support software(s) (if any) to run the above application.

3. Handholding support for the application for 120 days post go live of the system developed.

4. Warranty and support for 2 years post go live for the system developed.

5. The design of the platform would address key concerns such as Confidentiality, Integrity and Availability.

The detailed application requirements are provided in the subsequent sections of this

document.



4. Instruction to Bidder

4.1. Invitation to Bid

1. CDC invites sealed bids i.e. technical and financial proposal, from interested bidders on September 26, 2016 for the design, development and implementation of a web/client based Order Management System (OMS). The bidders are required to guarantee a solution support and other technical support for a minimum of 2 years from the go live date. Support would interalia entail modifications for regulatory reasons, development of new features and other support to maintain and improve performance, competitiveness:

2. The detailed requirements are provided in the subsequent sections of this document

3. The bids prepared in accordance with the instructions in the following sections, must reach undersigned on or before Sep 26, 2016 at 1500 Hrs.

Mr. Shariq Naseem – General Manager – PD & Marketing

CDC House, 99-B, Block B, SMCHS, Main Shahra-e-Faisal, Karachi.

Tel: +92-21-111-111-500 Ext 4200

4.2. Terms and Conditions for Bid and Bidders

1. The Procurement Company is:

Central Depository Company of Pakistan Limited

Address: CDC House, 99-B, Block B, SMCHS, Main Shahra-e-Faisal, Karachi.

2. Clarification if any on the technical requirement may also be obtained by sending an email to [email protected] till Sep 20, 2016. Clarification requests received after this date will not be entertained.

3. It is of utmost importance that bids should be submitted very carefully, failing which the offer will be rejected.

4. The bid validity period shall be 60 days.

5. The language of the bid is English and alternative bids shall not be considered.

6. The bidder must also provide project execution plan.

7. Amendments or alterations/cutting etc., in the bids must be attested in full by the person who has signed the bids.



8. Bidder must have regular place of business, telephone numbers and email address and must provide proof of their existence in the particular business.

9. In case applicable taxes have neither been included in the quoted price nor mentioned whether quoted amount is inclusive or exclusive of such taxes, then quoted amount will be considered inclusive of all taxes and selected service provider will have to provide the required services, if selected and declared as best evaluated bidder.

10. The bidders do not have the option of submitting their bids electronically. Telegraphic and conditional bids will not be accepted. Unsealed bids will not be entertained.

11. CDC reserves the right to accept or reject any bid or to annul the bidding process and reject all bids at any time prior to award of contract, without assigning any reason or incurring any liability to the bidders. Further, in case it is revealed to CDC at any stage after the submission of bid that any of the information provided/submitted by the bidder against any requirement(s) is not correct or false then disciplinary action may be initiated which may lead to cancellation of the bid of that bidder and as deemed appropriate by CDC.

12. The prices quoted shall correspond to 100% of the requirements specified. The prices quoted by the bidder shall not be adjustable. Changes or revisions in rates after the opening of the bids will not be entertained and may disqualify the original offer.

13. Sealed bids may be dropped at the Reception of CDC House.

14. The envelopes shall bear the following additional identification marks:

CONFIDENTIAL ONLY TO BE OPENED BY THE ADDRESSEE

Bid for: “Order Management System”

Bidder Name:

Attention: Mr. Shariq Naseem – General Manager PD & Marketing

& Address: CDC House, 99-B, Block B, SMCHS, Main Shahra-e-Faisal,

Karachi.

15. The deadline for the submission of bids is:

Date: September 26, 2016 Time: 1500Hrs

16. A statement “Not to be opened before 1500 Hrs on Sep 26, 2016” shall be clearly mentioned on the top of the sealed bid.

17. The bids received after the due date and time will not be entertained.



18. CDC’s decision will be final and binding in all matters relating to this invitation.

19. CDC is not bound to accept the lowest bid.

20. CDC reserves the right to cancel this invitation and reject all bids at any stage of the bidding process.

21. CDC reserves the right to amend/change/revise the RFP if deemed necessary. The successful bidder shall have to provide the services accordingly.

4.3. Pricing

1. Solution proposed by the bidder to fulfill the requirements must be priced separately for each Module with details, Annual Maintenance cost, cost of further customization

2. With source code and without source code pricing should be separately quoted.

3. Support pricing per year should also be quoted after expiry of 2 years of support.

4.4. Payment Terms

Payment modes can be one of following upon mutual agreement after deduction of all

applicable government taxes:

1. Upfront after successful completion of project.

2. Deferred payment in five years.

3. Any other mode/model suggested by the bidder.

4.5. Intimation of Award and signing of contract

1. CDC will intimate the successful bidder in writing by registered letter, or by electronic means to be subsequently confirmed in writing by registered letter, that its bid has been accepted.

2. The intimation of award will constitute the formation of the contract.

4.6. Force Majeure

1. Neither party will incur any liability to the other if its performance of any obligation under the Contract is prevented or delayed by causes beyond its control and without the fault or negligence of either party. Causes beyond a party’s control may include, but aren’t limited to, acts of God or war, changes in controlling law, regulations, orders or the requirements of any governmental



entity, civil disorders, fire, epidemics and quarantines, general strikes throughout the trade, and freight embargoes.

2. The Bidder shall notify the CDC orally within five (5) days and in writing within ten (10) days of the date on which the Bidder becomes aware, or should have reasonably become aware, that such cause would prevent or delay its performance. Such notification shall (i) describe fully such cause(s) and its effect on performance, (ii) state whether performance under the contract is prevented or delayed and (iii) if performance is delayed, state a reasonable estimate of the duration of the delay. The Bidder shall have the burden of proving that such cause(s) delayed or prevented its performance despite its diligent efforts to perform and shall produce such supporting documentation as the CDC may reasonably request. After receipt of such notification, the CDC may elect to cancel the Bidder to extend the time for performance as reasonably necessary to compensate for the Bidder’s delay.

3. In the event of a declared emergency by competent governmental authorities, the CDC by notice to the Bidder, may suspend all or a portion of the Contract.

4.7. Project Completion Time

The preferable time for the delivery of the proposed solution/software is 2 and half

months after the award of the assignment.



5. Bidder Information Form

1. Name of Bidder : ______________________________________________

2. NTN# : ______________________________________________

(Please attach Copy of NTN Certificate)

3. GST# : ______________________________________________

(Please attach Copy of GST Certificate)

4. Contact Person : ______________________________________________

Designation : ______________________________________________

5. Contact number : ______________________________________________

6. Postal address : ______________________________________________

______________________________________________________________

7. Email address : ______________________________________________

Declaration: I certify that, to the best of my knowledge and belief, all of the information

on and attached is true, correct, complete and made in good faith. I understand that

false or fraudulent information on or attached to this form may be grounds for not

entertaining my bid, or for cancellation after bid acceptance. I understand that any

information I voluntarily provide on or attached to this bid may be investigated.

Signature ____________________________________________

Name & Designation ____________________________________________

____________________________________________

Name with Official Stamp ____________________________________________

Date _______________



5.1. Bidder Qualification Criteria

S.No. Criteria Minimum Supporting

Document

1 Company profile including details of Projects

completed.

Annual report or detailed

company profile.

2 Sales Tax, Income Tax Registration, and any

other Registration

Certificates from issuing

authorities

3 Company Experience – preferably 10 years Certificate of incorporation

4 Similar project completed – preferably 10 Letter of completion

specifying the

scale/magnitude of project

completed

5 Affidavit that firm is not blacklisted Affidavit in legal stamp

paper.

6 Presentation of project execution plan Project plan specifying the

total time required,

resource allocation and

milestones.

7 Bidder must have preferable IT staff strength

(staff performing duties of IT/software

design/development and implementation etc.)

of 12 personnel as on 26 Sep 2016.

Self-Certification

regarding the same on a

Company letterhead

signed by the Head of



HR, along with company

seal.

8 System must be up and running at preferable

10 different locations as of Sep 26, 2016.

Provide list of companies

along with details of

contact persons, name,

address, telephone

numbers, and email

address, where the

system is currently in use.

List the modules which are

currently in use at each

location.

Note: CDC may ask for any other document which it may deem necessary.



5.2. Bio-data of the all staff of bidder assigned for development/implementation of OMS

Name

Designation

(Project Manager,

Team Lead,

Developer etc.)

Highest

Qualification

Contact No.

Total experience in

years

Experience in

years in current

organization



6. General Solution Requirements

1. OMS should be web-based solution (having web-based front-end for users and as well as for system administrative functions for changing business rules or managing access policy) having centralized database, web and application server.

2. The intended user base for the system is diverse. The users include Brokers, PCM and investors. The system should have “drop down menus”, “command buttons”, “short-cut keys”, “and pop-up windows” and use other navigation aids as per the standards of PSX-KATS to make the solution / system efficient and easy to use.

3. The system should provide context driven help wherever input is required from the user and it should be customizable.

4. The system should provide for online help, general information and instructions.

5. The system should use standard drop-down lists wherever possible for standard values to be selected by the user.

6. The System should enforce secure login as per the login process, where users will have to authenticate his/her username, password. The system design therefore would also need to define the levels of user access to different user groups. The solution would need to define access policies where in different type of users would be given access to different modules and related information.

7. End users of the system will have to be given access to the system through multiple platforms including desktop, smartphones, tablets etc. Thus the system must allow for multiple platforms and must be compatible with different browsers. The solution should be compatible with all leading web browsers, especially with Microsoft Internet Explorer 6.0 or above and Mozilla Firefox 2 and above, Chrome etc. a. The application so developed shall also be mobile compatible. Stakeholders should be able to use mobile to transact.

8. The Graphical User Interface (GUI) of the application should be compatible (viewable) on various devices like PCs, tablets, smart phones, mobile gazettes etc.

9. All components of the OMS system must support scalability to provide continuous growth to meet the requirements. A scalable system is one that can handle increasing numbers of requests without adversely affecting the response time and throughput of the system. The system should support interoperable, portable, and scalable applications, services, interfaces, data formats and protocols.

10. Internal PCM users shall be connected over WAN and shall access the OMS over the Intranet. However, provision to connect via internet must also be provided.



7. Functional Requirements

The proposed solution would consist of the following main features:

1. Multi-Tenant trading, RM & BO including accounting.

2. The structure of OMS will have three broad components:

a) OMS Trading Platform (Optional for TOs)

b) OMS Risk Management Component (Mandatory)

c) OMS Back Office Component (Mandatory)

7.1. OMS Trading Platform

1. Complete package will include OMS, including Trading, Risk Management and Back Office services. However, TOs can opt to avail the KiTS service of PSX or any other trading software as their trading platform instead of the OMS trading platform. In such case TO’s trading platform will be integrated with the OMS provided by the PCM, so all trades executed by the TO/client(s) will be routed through OMS-RMS filters before placement on the PSX trading engine.

2. Integrated trading solution with KATS of PSX

3. Multi-TO and its client’s respective exposure and complete risk management.

4. Access of the OMS Trading to the TO and its client(s) for trade execution.

5. Master OMS ID for TO, through which the TO will be able to create online Trading User IDs for its client(s).

6. Trades of Client(s) can be executed by their respective TO and/or directly by client(s) through online OMS, KiTS platform or any other trading platform linked with OMS at the Pakistan Stock Exchange in accordance with its rules and regulations.

7. Facilitates TO to extend its exposure allotted by the PCM to its client(s) for order placement/execution, in case there is a shortfall in clients exposure allotted by the PCM.

8. Filtering of Trade order(s) on the basis of trading limits assigned by PCM to the TO and its client(s). Trades which are under the trading limits will be routed through the FIX Protocol of PSX before placement on the Trading Engine of PSX for order matching.

9. Linkage with NCSS and CDS so it could have complete data related to settlement and custody. CDS will pass the activity and tariff related information to the OMS.



10. OMS will allow TOs to automate a variety of brokerage business processes, such as order management, validation, routing, client(s) management, scrip management, trade execution handling etc.

11. Real time trade execution, account position and trading margins.

12. Efficient order capturing windows in line with KATS.

13. Feature rich order modification/cancelation.

14. Trade related information such as Market watch/portfolio information, MTM profit/loss tracking, Pre-trade and Post-trade Margin information etc. will be available.

15. Data Portal to display announcements, news, RSS feed, trading guidelines, investor information etc.

16. TO and Client(s) will be able to view their respective complete trading activities, portfolio position (securities and cash), settlement obligations, risk management, margins, pay & collect etc. in the OMS system. Relevant reports will be available on the same.

17. Market related information such as top gainer, losers and leaders etc.

18. Live messages and announcements.

19. Download option allowable through authority management will be available in the OMS for TO.

20. Ability to export data to Excel allowable through authority management system.

21. Multi account operation.

22. Feature rich views.

23. Feature rich workstations for traders, dealers, branch managers and Investors.

24. Features such as charts, indicators, price bands and moving averages, trading patterns, trend lines & drawings, free-float information, corporate action announcements, market news, etc.

25. Features such as stop loss, price alerts for different values and price crossovers.

26. Comprehensive reports.

27. Cash withdrawal and security withdrawal/ transfer request options.

28. Off-hour order placement facility.

29. Appropriate measures to ensure security of information in OMS.

30. Back Office should be customizable to suit different requirements of TOs.



31. The client end display should be capable of viewing filtered messages e.g. trade / order confirmations, notifications, indices ticker, administrative messages or Risk control related messages.

7.2. OMS Risk Management Component

1. Complete Risk Management of the TO and/or client(s) will be handled through RMS component of OMS.

2. Straight-through-order, equity, custody, online exposure and margin control measures, risk management.

3. RMS shall be conducted at below mentioned 3 levels:

a. Professional Clearing Member - PCM

b. Trade Only Broker – TO

c. Client(s) of TO

4. Trades of client(s) will be executed by the respective TO. Client(s) will also be able to execute trade directly by assigning a trading terminal by PCM.

5. PCM will assign trading limits for TO and its client(s). OMS will pre-match the order with the assigned trading limit. Orders within the prescribed limit will validated through OMS RM and shall be transmitted to the Trading System. Orders over and above the prescribed limit will be blocked and shall not be transmitted to the Trading System.

6. Trading / exposure limits of client(s)/proprietary account shall be incorporated in OMS. Some examples of Categorization of client(s) is as under:

a. Category A Client(s) – Low risk profile, maximum exposure can be allowed i.e. allowed trading in ready market /leverage / futures up to n times of the net assets provided (subject to maximum exposure limits detailed in NCCPL Regulations)

b. Category B Client(s) – Medium risk , medium range exposure can be allowed i.e. allowed trading in ready/leverage / futures up to n times of the net assets provided (subject to maximum exposure limits detailed in NCCPL Regulations)

c. Category C Client(s) – High risk, lowest exposure to be allowed i.e. only delivery versus payment trading allowed (subject to maximum exposure limits detailed in NCCPL Regulations)

7. Where TO wants to allow more extended trade limit to its client(s) (over and above Net Equity), they may do so by allotting cash / securities (with applicable haircuts) from its propriety account, but up to the maximum extent of “n” times of the available balance of client(s). However, in such case the extra required



cash /securities (i.e. the cash / securities provided by TO from proprietary account) must be submitted by the client(s) within next n days.

8. In addition to these position / trading limits as applied by PCM for TO and TO’s client(s), the risk management regime of NCCPL including but not limited to all types of margins, Marked-to-Market (MTM) Losses, position limits, capital adequacy limits and acceptable collateral management shall also applicable on the PCM as prescribed by NCCPL from time to time. This shall also include pre and post monitoring of TO position.

9. Reports/statements pertaining to settlement and risk management to the respective TO and its client(s).

10. Pre and Post trade margins, MTM losses, collaterals collection.

11. TO shall also have authority to allow its propriety account balances to be used for margin, MTM losses and collaterals demands as mentioned above, for its client(s).

12. Release excess collateral to the TO and/or its client(s).

13. In case of leverage market and trading in future market, Pre trade and post trade margins, futures variations margins call.

14. Definition of securities acceptable by PCM for the purpose of collateral and margins.

15. Collection of MTM losses for leverage market.

16. Auto/manual demand call, where available cash / acceptable securities balance of client(s) falls below the minimum required balance, as per the allowed trading limit.

17. Auto/manual liquidation of open position where demanded cash / securities are not provided.

18. Pre and post trade risk control.

19. Auto revaluation of all portfolios against real time market feed.

20. Integrated with back office and online trading platform.

21. Centralized control for multiple venues trading.

22. Real-time MTM & exposure adjustment.

23. Smart margin and / or cash verification before order placement.

24. Real-time cash update against cash receipt/payment.

25. Valuation and control of all cash withdrawal requests.

26. Real-time custody updates against custody In/Out.



27. Real-time cash & holding updates against trade execution.

28. Exposure and trading limits

29. Multi-venue and market based regimes

30. Real time and off line reporting

31. Cash and margin trading

32. Risk policies for individual client, all clients or group of clients

33. Risk policies for individual security, all securities or group of securities in particular or all markets/venues.

34. Responsibility for the settlement of all locked-in trades by a TO and/or client(s) successfully executed in the Market shall reside with the PCM.

35. TO will not be required to fulfill margin obligations in respect of such trades. PCM will be responsible for both the pre-trade and post-trade margin of such trades.

36. Trading in leverage markets (MTS, MF and SLB)

37. Equity segment margins should be allowed to be based on VAR margins, simple multipliers, additional margins for various client groups simultaneously.

38. New client addition / removal / client facilities, rights subscribed to by clients should be instantly changeable during trading hours in live environment – either at the online request of client or through administrative control with a proposer – approver confirmation.

39. TO addition / removal / dealer rights should be modifiable instantly even during trading hours on real time basis with a proposer – approver confirmation.

40. TO/ Client funds account modification / deletion / blocking should be possible during trading hours on real time basis with a proposer – approver confirmation.

41. Various user rights / privileges should be modifiable or completely blockable during trading hours on real time basis

42. Risk managers/ administrators should be allowed to control square off modes for all products, monitor pending orders, in process orders, allow cancellation of such orders, manage the scrip and market watch numbers at client end, broadcast message to select clients, client groups, users, define haircuts, view client collaterals, obligations; maintain audit trail for TO/ client and other user activity including log ins, trading and other activity logs, position wise date wise obligations etc.

43. The solution should be capable of allowing clients with limits / capital management based on multiple parameters; should be capable of monitoring trades, orders, exposures etc. on real time basis.



44. The solution should be able to interface with exchanges for VAR margin files and margin calculations using SPAN files.

45. Solution should also allow interface with multiple banks and depositories to block and lien mark the cash and stocks for trade or margin.

46. The solution should be capable of monitoring real time mark to market valuations as well as EOD MTM of positions held by clients. There should be a possible facility to send out automated trade alerts to the client vide an email or SMS.

7.3. Back Office

1. Complete client management such as account opening in line with CDS account opening fields, client code, signature & form capture, etc.

2. Multiple and multi-tenant commission and Fee profiles defining/calculation.

3. Trade / Rate / Security specific exceptional commission and fee definition for clients.

4. Post trade commission and fee adjustments.

5. Maker and checker between TO and Client, in case of any change in commission is needed. The final request will be forwarded to PCM to make necessary changes in the system.

6. Facilitates TO for Back office account opening, UIN Registration/mapping, assign and open a new client(s) code.

7. Maintain segregated securities/cash position of TO and its clients.

8. PCM Tariff, brokerage commission, PSX charges, laga, CGT, etc. details for TO own and client(s) trading activities.

9. Complete AMS system along with maker and checker function.

10. TO should not be able to edit the securities & cash portfolio balances of its client(s) in the OMS. View / print option for trading activities and balances of client(s) will be available to TO.

11. Multi-tenant accounting system. TOs should be able to maintain its financial accounts in the back office system provided by the PCM.

12. Standard accounting features such as General Ledger, JV, Rule base JV, Flexible Chart of Accounts level and lengths, Journal, cash and bank books, Provisional Vouchers, Payables / Receivables, Fixed Assets Register, Payroll Management, Bank reconciliations etc.



13. Financing to the TO and/or its clients and its complete calculation/maintenance along with different markup charging techniques, Islamic/conventional financing facility, record keeping, auto debit etc.

14. Features such as age calculator debtors & creditors, secured & un-secured debts, revenue & cost, profit evaluation, administrative costs, MIS reporting etc.

15. PCM can provide and/or arrange financing through Margin Financing System (MFS) and/or Margin Trading System (MTS) in accordance with the Leverage Market Rules.

16. Netting Mechanism.

17. Consolidated and TO wise Securities Settlement

18. Consolidated and TO wise Money Settlement

19. Default Management

20. Billing

21. PCM will facilitate the TO in the initiation of the IDSC transaction. The option to initiate IDSC transaction may be built in the OMS.

22. PCM/TO will initiate the IDSC transaction on trade date which will be automatically routed from OMS to NCSS.

23. If the IDSC transaction is affirmed by CCM, settlement obligation will shift to the CCM.

24. If the IDSC transaction is rejected by the CCM, BO will be generated in CDS proprietary sub-account of TO maintained with PCM

25. Following general facilities amongst others are expected,

Bulk and manual (single) upload of journal entries.

Bulk and manual (single) upload payment and receipt entries.

Maker – Checker concept for operations.

Automated reconciliation of bank and DP accounts.

Preparation and printing of cheques, vouchers, trial balance, balance sheet.

Acceptance of pay out request for offline clients from branch terminals.

Generation of Payout request files – bank wise, branch wise, channel wise etc.

Accounting of client margin amounts in sub accounts.

Auto updation of ISIN, new Scrips, & Settlement numbers.

Client-wise Profit and loss statement for Cash & FO segment

26. BO system should have the facility to update and store (date wise) the closing prices for stocks on upload of price file received from exchanges - NSE & BSE separately.



27. VAR margins should be uploadable into the BO system.

28. Flexible database structure to handle changes in exchange / regulatory

requirements.

29. New client creation through a single record entry or file upload.



8. Accessibility

1. Trading terminals with OMS will be installed at TO premises, which will be accessible via web and/or client side deployment of the software.

2. Accessibility via web and mobile platforms.

3. Alerts such as Margin Calls in the form of SMS/e-alerts/fax/emails.



9. Security Management

1. The solution must provide a security blanket to protect all applications, services, data and the infrastructure from malicious attacks or theft from external (through internet) and internal (through intranet) hackers. Use of firewalls and intrusion detection systems provided by hosting services provider should ensure that such attacks and theft are controlled.

2. Furthermore, all the system logs should be properly stored & archived for future analysis and forensics whenever desired. The successful bidder shall get a security audit done for the entire solution as part of scope of work within one month of Go Live.

3. Following are the key logical security requirements:

Requirement Description

Authentication Related

User Identification

And Authentication

All the computing devices (servers, desktops, network

devices) shall uniquely identify and authenticate the user

or any process that acts on behalf of any user.

Authentication Hint Application should not give any hint or information during

the authentication process to avoid possible

exploitation/use of the hint by unauthorized individuals

Handling of

Authentication

Failure

The application enforces a limit of consecutive invalid

authentication attempts by a user during a specified short

time period.

Enforcing use of

quality

authentication pins

The application enforces users to use quality

authentication pin by providing a mechanism to verify that

the pins meet specified quality criteria.



Generating Quality

Authentication

Pins

The application shall provide a mechanism to generate

pins that meet defined quality metric and to enforce the

use of the pin for specified functions

Management of

Identifier

The user identifier should be unique for each user so that

the activities performed by the user on the information

system can be traced back to an individual. The managed

process of user account handling shall clearly state the

approval authority for creation of user accounts for

information systems, suspension/disabling etc.

Password

Management

The application should manage the ‘information system

authenticators’ (e. g password) by defining initial

authenticator content, establishing administrative

procedures for distribution of initial authenticator, re‐

issuing of authenticator in the event of loss or compromise

or damage of user authenticator, establishing

administrative procedures for revoking authenticators,

changing default authenticators upon information system

installation, changing/refreshing .authenticators

periodically

Access Related

System Access

Notifications

The application displays an approved, system use

notification message before granting access, informing

potential users on various issues.

Access

Enforcement

The application enforces access control to the system in

accordance with the applicable policy



Previous Login

Notification

The application should provide logon history details

Control of

concurrent

sessions

The application is capable of limiting the number of

concurrent sessions for any user.

Authenticity of

communication

sessions

The application provides mechanisms to protect the

authenticity of sessions during communication.

Access Logs The application logs all access events

Enforcing data

entry by humans

where applicable

The application should use CAPTCHA where applicable

to enforce data input by human only not by computer

programs or ‘bots’.

Data Handling

Data Validation The application checks validity of the input data to the

application

Protection of

transmitted data

The application protects the integrity and confidentiality of

the transmitted data (authentication credentials only)

between the client and the server.

Application

Partitioning

The application separates user functionality (including

user interface services) from application management

functionality.



Error Handling The application identifies and handles error conditions in

such a manner so that no sensitive information that could

be exploited by adversaries is leaked through the error

messages

Network Control

Network

Segmentation

The network architecture and segmentation should be

based on different security level (depending on the nature

of the information asset and anticipated security threats).

Network Routing

Control

The organization should adopt a policy in respect of

controlling the information flow within the system and

between interconnected systems. The information system

should enforce such policy wherever there is a difference

in the level of trust

4. Authority Management System

5. Roles Based Access Control

6. Audit Log of user performing different functions according to the allowed authority and Change History

7. Maker-Checker binded with AMS

9.1. Critical Security Considerations

1. OMS should be protected, without any impact on the system, from the following security incidents:

a. Virus Attack – This shall include malicious code infection of any of the desktops/servers in the network

b. Denial of Service Attack - This shall include non-availability of service

c. Data Theft - Compromise of any kind of data through network.



d. Intrusion – Successful/unsuccessful unauthorized access to OMS application/network resulting in loss of confidentiality/integrity/ availability of data.

2. In case of an impact, the data, database and database structure should not be compromised. The tolerance for compromise of confidential data is zero.

9.2. Usability Requirements

The system should have good ergonomics and aesthetics with excellent GUI. The

screen layout and designs, menu options, and other system formats etc, should be

designed keeping in mind ease of use by different stakeholders. Software Architecture

and Design of PCM Solution.



10. Software Architecture and Design of PCM Solution

Following should be explained in detail:

4. The technologies used in the development of the software. Explain it for each module in overall software solution.

5. The logical diagram of overall software solution and interaction between its different modules as well as with external systems.

6. The structure of system and its different components and sub components and how these components interact.

7. Maintainability, extensibility, reliability of the software ensured.

8. Describe if the software design is modular and to what extent. Describe if the functionality code is duplicated in several components.

9. The areas where tight coupling exists between the software components and the functional areas where the modules are loosely coupled.

10. List the current versions of tools and technologies that are in used in the development / testing and executing /maintenance of the software over production.

11. List the till date known gaps, if any, in the adopted technologies and the bidder’s plan to address in the software application.

12. Provide the list of operating systems over which this solution and its different modular components can be deployed.

13. The overall tiers/layers in the software application. Such as if it’s a three tier architecture product or else. Explain the separation of presentation layer, business logic layer and data access layer in the system.

14. The list of database server/ RDBMS, web server, application server, message oriented middleware, enterprise service bus, queuing technology, using which this software operates. Mention the details of usage of these servers for different components of the software.

15. To what extent the software can be used on other platforms (web server, database, application server etc.) then those mentioned. Is there any flexibility to replace database, web server etc. Also provide the list of application / web / database servers this application can be deployed on.

16. How much the solution abides by the principles of service oriented architecture. Describe the usage of web services in the overall software architecture. Is there any need to use API gateways in the solution.



17. How data is transmitted across software and external connections. Mention the role of XML and JSON in the architecture. Also mention the role of AJAX in the application.

18. The design patterns used in the software product in different modules.

19. The frameworks / standards used in different modules of this software product.

20. The exception handling mechanism used in the software. How error conditions are raised and propagated between application components.

21. The transaction management mechanism used in the application.

22. The data that is deleted from the software and would not be available after an activity in the software.

23. The approach used in order to minimize the number of roundtrip calls between client and server side of application.

24. Mention if any legacy code is being used in the application.

25. Mention if any third party software tools, technology and APIs are being used in the software.

26. Describe if any open source tools, technologies and components are being used in the software along with the reason for using the same.

27. How the software can be operated in a distributed environment.

28. Describe if software can use and integrated with business intelligence tools. Also, mention the use cases that can leverage BI capability for better experience.

29. How the software utilizes different features of database server, application server etc. for better performance (ex. usage of In-memory cache). How performance of the software ensured.

30. How the software application ensures Non-repudiation of transactional activities in software.

31. The usage of PKI Infrastructure in the software application.

32. How adhoc query requests can be handled in the software.

33. How security in the software overall design is ensured. What security measures are implemented at the code level and need to be implemented at the database, application server, web server level etc.

34. The areas where software components can be executed over different processors or threads. Describe to what extent the software uses threading. Describe if any marshalling technique is used in the application.



35. Describe which protocols are used in the software and for what purpose.

36. The areas where the communication is asynchronous and where there is synchronous communication between software components.

37. The overall input validation mechanism implemented in the software. Does the software relies on client side validations only or there is any mechanism to validate at different tiers of application.

38. How the software application and its different modules would behave in cases such as loss of network connections or reboot of underlying supporting softwares.

39. How the system modules use stateless or stateful components and for what purpose.

40. What requirements the system need from infrastructure in terms of shared libraries, support for communication protocols, load balancing, transaction processing, system monitoring or other infrastructure services.

41. How the data is secured from unauthorized modifications, disclosure and distribution.

42. Describe the clustering requirements of the application and overall software.

43. How encryption techniques are used across the software. What are the measures to protect data from unauthorized external access. Is there any role of digitally signing the transaction.

44. The data that needs to be inserted via a patch activity and there is no provision of the same by using software functionality.

45. The jobs/ processing that need to be scheduled in the system. How they are scheduled (cron, SQL server scheduler etc.)?

46. How the overall software solution can be better configured for a cloud environment. Are there any challenges that need to be taken care of while deploying it in the cloud environment.

47. The usage of configuration files, parameter files that are used in the software application.

48. How session management is done in the application and in its different modules. If session time is limited in the software. How session state is protected from unauthorized access. If session identifiers are passed in query strings.

49. The usage of SSL and security of keys that needs to be ensured in the software.

50. How design addresses the security threats such as SQL injection, cross site scripting etc.



51. Describe if confidential data such as credentials etc. are secured (such as encrypted) in the software solution.

52. The log files that are generated in the software and what level of logging can be enabled and does the log files contain critical information.

53. How cookies are used in the software and how cookie is secured.

54. Describe if system level accesses are restricted in the software.

55. How database connections, password keys or other secrets are stored. Are they stored in plain text?

56. The roadmap of the software product and its overall architecture and design. Is there any need of reengineering on newer platform and if the same has been planned by the bidder.

57. The performance standards and the response times in the software application that are being met.

Item Performance Standard / Response time

Screen Navigation – field to field (example) < 5 milliseconds

Screen Navigation – screen to screen (example) < 1 second

Screen Refresh (example) < 0.5 second

Screen list box / Combo box

Screen grid 25 rows & 10 columns

Report preview (simple)

Report Preview (complex)

Simple search (single table)

Complex search (multiple table)

Web page loading

Saving / posting a record

Batch processing per 100 records



11. Login Authentication and Authorization

1. List the browsers that are supported in the software and their versions.

2. The Audit logs, Audit trails that are maintained in the system.

3. The maker checker mechanism in the implemented in the overall software.

4. Describe which persistence frameworks are being used in the software application.

5. How integrations with external software applications supported in the software. What is bidder’s recommended way to integrate back office system with CDS in order to provide data from CDS to back office pertaining to CDS transactions and Account opening information. Also, mention if the system is integrated with RTGS / banks etc.

6. The load that would be on software in terms of number of transactions under different modules in case of 120 TOs and 20000 accounts and one third of the same.

7. Mention the expected night time / day end processing workload on the system.

8. The mechanism used for deployment of client side code on the client machine.

9. The code protection measures that are taken in the software such as obfuscation, jar signing etc. What level of code is obfuscated. How its ensured that the code does not get modified by unauthorized access.

10. Describe which modules of the software are core extensive and which are RAM intensive.

11. Describe which components of the application has got desktop version, web version, native mobile version or hybrid mobile version. If the browser version has got responsive web design.

12. What are the benchmarks related to stress / load at which this application has been tested.

13. The mechanism of FIX data exchange and the required installations in this regard.

14. The cases where the software stores data locally in client machine or mobile device.

15. The reporting architecture, framework and technologies used in the reporting activity in software.



12. IT Infrastructure of PCM Solution

1. Describe in detail the recommended server hardware specification required for the solution.

2. Describe in detail the recommended storage device specification required for the solution.

3. Describe the recommended network equipment specification required for the solution.

4. Describe the recommended desktop hardware specification that are required for the solution.

5. Describe the recommended specifications of other IT Infrastructure components, peripheral devices that are required for the deployment of the software.

6. Describe the number of equipment pertaining to IT Infrastructure components that are required.

7. Describe the number of instances, with detail configuration, separately for development/QA/UAT/Training/Production/DR that shall be required for running the software.

8. Describe the number of items required with their specification separately for the environments development/QA/UAT/Training/Production/DR ) mentioned above as well as while considering the initial load over production of 25 TOs and 5000 accounts on production in the first year and increase of 30 TOs each year with 5000 accounts incremented each year.

9. Please inform, based on bidder’s market experience, the volume of transactions that would be done in different modules, keeping in consideration the above mentioned load/growth. Also, the number of concurrent users in the system. Infrastructure sizing should also account for the estimated concurrent users in the system.

10. Describe in detail the high availability and redundancy measures that need to be taken for the software.

11. Describe in detail the failover and load balancing that needs to be implemented for the software.

12. Describe in detail the clustered configuration that needs to be implemented for the software.

13. Describe in detail the security related measures that need to be taken in the overall infrastructure design. Mention how highest level of network security, reliability, visibility and manageability is ensured in the proposed design of the solution.



14. Describe in detail the configurations that need to be implemented at the infrastructure level (its different components) for optimal performance of the software.

15. Describe in detail the arrangements that are required for WAN , LAN connectivity, internet connectivity, VPN connectivity and the bandwidth that shall be required.

16. Describe the usage and arrangements that are required for overall IT environment w.r.t other necessities such as directory server, mail server, SMS relay server, SAN server, Authentication server, IVR/ Call center integration, CRM integration, DNS server, VM Manager, file server or any other essential server.

17. Describe in detail the configuration of web server, application server, proxy/reverse proxy server, database server etc. that is required over the infrastructure.

18. Describe in detail , with diagram, the network architecture proposed, the communication methodology proposed, the placement of hardware servers in different logical regions (DMZ etc.) and the detailed diagram of software deployment over the IT Infrastructure.

19. Describe in detail that how the proposed infrastructure architecture ensures scalable and modular architecture with no single point of failure and best practices and standards.

20. Describe the data off-lining, retention and purging measures that shall be required for the software data.

21. Web server sizing may also assume 25% extra logins of casual users.

22. In case of DR, capacities may be reduced as compared to production. Also recommend if it would be feasible and if both the sites need to be active-active or active-passive.

23. Describe in detail the recommended configuration of software over virtualized environment. Also, map the overall software application and its underlying softwares (web server/application server etc.) over the virtualization enabled environment.

24. Describe your recommendation w.r.t allocation of CPU/Cores and other system resources such as RAM etc. for various VMs.

25. Explicitly mention if any software component (OS, database etc.) is reaching end of life/support within a duration of 1-2 years.

26. Describe the minimum and maximum response time and disk IOPS for which the system shall be configured.

27. Describe the recommendations related to backup and recovery measures for the software.



28. Describe in detail the data replication mechanism that need to be establish for the software data.

29. Describe in detail the storage related configurations in the overall solution. Discuss the scalability needs of capacity over SAN.

30. Describe the configuration of network equipment in the overall solution such as core router/ internet router/core switch/firewall/IPS/IDS or other networking device.

31. How to tune the environment, especially on data volume as user work load grows.

32. Are there specified time durations or intervals at which data needs to be transferred from external systems into this software. Please describe.

33. What are the licensing needs of the complete software and its components.

34. Is there any proprietary technology being used in the overall solution.

35. Describe in detail bidder recommendations for the configuration that need to be implemented in case the solution is hosted over the cloud environment.

36. Mention the uptime requirements of different modules of the system.



13. General Requirements

1. Describe the software source code configuration management and version management process that shall be adopted.

2. Describe the change management process that shall be adopted for the software.

3. The bidder shall provide the system administration guide, system trouble shooting guide, system interface documentation, system design document, software functional specification document, when required.

4. The bidder shall provide Acceptance testing plans, test cases and test reports.

5. The bidder shall provide user manuals of the software. Please share the template of the same.

6. The bidder shall provide trainings and knowledge transfer to IT staff for the software administration and maintenance.

7. The bidder have to provide the list of clients where this software is currently running, maximum load on it, maximum number of users in an installation, number of transactions processed on average on daily basis and number of transactions in peak hours.

8. Please mention the features that are being planned in upcoming release of software and what are the timelines.

9. What is the frequency of modifications in the software and its release over production.

10. What are the bidder plans for the upgrade of technological architecture of the software.

11. Are there any known errors in the software application. If, ‘Yes’ then list them. Are there any capacity limitations in the software? Also provide the details, if any, including the reason when in past the software abruptly undergone an unplanned downtime.

12. How the project management activities shall be performed from the bidder side during the project.

13. Describe the production transition strategy as recommended from the bidder’s side.

14. Provide the organizational level certifications that have been done such as CMMI etc.

15. Provide the technical resource profiles that shall be engaged in the project from bidder’s side. What shall be the composition of team for this project and their roles.



16. Provide the recommended roles and responsibility matrix that shall be followed during the project.

17. Source code security scanning shall be performed before live deployment along with penetration testing

18. Provide reports if the source code audit has been done from external party or penetration testing exercise had been performed over the software in past.

19. Describe the Quality Assurance process that is performed by the bidder before deployment on production environment.

20. Whether the bidder shall go for any subcontracting during the project for any item.

21. Describe the vision of bidder for the software product.

22. Mention if client’s technical support staff can be made available in Karachi during the project and afterwards for support after project’s deployment.

23. Describe the process of incident and problem resolution for production environment.

24. Briefly describe the details regarding the software’s intellectual property rights.

25. Mention, if the software comply with internet / electronic transactions act, rules and regulations.

26. Mention, if the system has ISO 20022 compliant message exchange formats.

27. Provide the number of years this product is in live operations.

28. Provide the expected issues in rolling out this project and the key dependencies. Bidder shall also provide project management documents at the time of project initiation / execution.

29. Bidder to provide particular strengths of its product as well as differentiating factors of its project in comparison with those of the competitor.



14. Training:

The bidder must provide the training and documentation in the following areas:

1. End user training for OMS

2. High end technical training including training on application and database management, system administration etc. to a select group of technical staff as designated by the PCM.

Following activities needs to be performed by the bidder as part of documentation:

1. Defining overall training requirements in consultation with the PCM

2. Preparation of training plan, schedule etc.

3. Preparation of training guides / user manuals for the application and installation manual & administration manual a. Documentation to be provided to the PCM in electronic medium and booklet in binding form.

4. Training delivery will happen at PCM office / sites as per the convenience of PCM. This will happen in logically made groups of attendees and will be finalized by the bidder in consultation with the PCM.

5. The successful bidder should ensure that the knowledge transfer to PCM happens effectively post training, during the project implementation and maintenance phase as well

14.1. Training and Training Materials:

The successful bidder should perform the following tasks as part of the training to

PCM. The bidder has to give the training as per the following criteria:

1. Go-live

2. The application would be considered go-live only when

3. The implementation and testing of location hardware has been completed and signed off by PCM.

4. The location connectivity and all in-scope application usage is tested at PCM offices and signed off by PCM.

5. The location users have been trained by the successful bidder.

6. The application solution implemented by successful bidder would be deemed to be completed when all the following conditions are fulfilled and acceptance/sign off is obtained from PCM on the same:



7. Sign off on user and system configuration manuals, and all other deliverables as mentioned in this RFP

8. User acceptance testing and sign off on the system functionality.

9. Validation of data migration results.

10. Training provided to all identified employees.

11. Post implementation support would be deemed to be complete if no R1 incident/problem/bug is reported during the support period of three months. In case a severity 1 issue is reported during the support period, then from date of occurrence of R1 issue/bug bidder will have to continue post implementation support for another 3 months. The post implementation support can go up to maximum of six months



15. Operations and Maintenance

1. The successful bidder shall maintain and support PCM for a period of 2 years post Go-Live, including:

2. Resolution of errors/bugs (if any), software updates, changes in the software that may be necessary due to legal/statutory changes etc.

3. Providing all software updates and patches released by update and patch management, resolution of any issues/problems with the hardware etc.

4. For the operations and support duration, the bidder is to deploy people at PCM/hosting site on an ongoing basis to strengthen the operations.

15.1. Handholding Period

1. The successful bidder shall provide handholding for a period of 120 days to system users and PCM technical staff and provide them detailed technical training of PCM post Go-Live Phase. The technical training shall include: application installation and parameter tuning, application usage, application design and logic, configuration management, performance tuning of applications and language used for coding. The successful bidder shall also resolve the day to day issues arising out of the usage of the application by the users, assist technical staff and helpdesk users for issues relating to stakeholder user management, resolve any installation and configuration related problems of the users.

2. The successful bidder shall provide an Issues and Resolution document, FAQ document and helpdesk manual at the end of the handholding period.

15.2. Technical Support

1. The successful bidder must warrant that all the deliverables provided under this bid will be free from defects in design and development etc. for the warranty period. If any issues remain outstanding at the end of the warranty period, the warranty period will be extended until PCM is satisfied with the resolution of the issues.

2. The successful bidder must identify a “Project Manager” who will be the primary point of contact for PCM during the warranty period and who will have the authority to take any action necessary to resolve any warranty related issues and also is responsible for providing status report to PCM officials as per agreed frequency. The project manager should be available on call during normal business hours.



15.3. Support services

1. The support services for the PCM shall be provided for a period of 2 years post go-live. During this period the successful bidder shall provide bug fixing support for any system problems that may arise in the PCM system developed.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

central depository company of pakistan request for proposal … · 2016. 9. 7. · introduction ......

Documents