Home  :  Circulars

NATIONAL SECURITIES DEPOSITORY LIMITED

Participant Interface

Circular

Circular No. NSDL/POLICY/2007/0061
Date: October 5, 2007

Sub : Release of Version 7.0 and its features

All Depository Participants (DPs) are hereby informed that Version 7.0 of the DPM Application Software (DPMAS) will be released on October 5, 2007. The Power of Attorney (POA) module informed to DPs vide Circular No. NSDL/POLICY/2007/0054 dated September 22, 2007 will be released in version 7.0 of DPMAS. The software would be released in phases to all DPs. Software release schedule would be communicated to the DPs by PMC.

Additional features of Version 7.0

The features of this version release are as follows:

1. POA Registration
2. System Security Enhancements
3. Transaction Statement (SOT) for closed accounts

The details about these versions are given below:

A. POA Registration:

POA features, informed to the DPs vide our aforesaid circular, would also include the following

1. POA Holder(s)/Authorized Signatory (ies) Master list report and Corporate POA reports are provided under Master List reports. These reports provide the list of POA holder/authorized signatory as well as the list of corporate POAs registered in the system.

2. Additions / Modification through Interactive screens on DPMAS

a. Interactive Screens have been provided in Client Maintenance Module to capture and modify;

i. POA Holder / Authorized Signatory

ii. Corporate POA

iii. Mapping POA to beneficiary account at a holder level

b. The screens for client creation in client maintenance module have been modified to enable attaching the POA details to the client account.

c. Additional functional rights have been added in system security module. DPs are advised to give the functional rights to the users for conducting different operations of the POA module.

d. Additional menu button to view signatures of POA has been added, in the common menu buttons, to view signature of the authorized signatory/POA Holder, on various screens of DPMAS where a DP executes a transaction. This screen will also show account holders signatures.

3. Exception reports are also provided as follows :

a. Authorized signatories not associated with any POA ID:

This report enables DP to monitor whether there is any authorised signatory, which has been created in DPMAS but not associated with any POA ID.

b. POA ID not associated with any clients:

This report enables DP to monitor whether there is any POA ID, which has been created in DPMAS but not associated with any client account.

c. POA IDs without authorised signatories:

This report enables DP to monitor any corporate POA IDs, which does not have any active authorized signatory associated with the POA ID i.e., when all the authorised signatories, which are associated with the POA ID, are either in closed status or detached from POA ID.

d. Expiry details of digital signature certificate:

This report provides the expiry details of the digital signature certificates used by the POA ID.

e. Client account holders to which blank POAs are attached:

This report provides the details of the account holders, which are mapped, to POAs whose POA IDs does not have any active associated authorized signatory or POA ID is deactivated or POA Holder is deactivated.

Operating Instructions

a. As provided with all other instruction submission features, facility of maker & checker is provided for POA registration also. Though a user can be assigned functional rights for both maker (capture) as well as checker (Verify Release), as a matter of good practice DPs are advised to allocate maker and checker rights to different users.

b. DP has to ensure that the minimum number of authorized signatories required for authorizing an instruction should be less than or equal to the number of authorized signatories registered for that POA.

c. DP should monitor the status of POA or the authorized signatory to ensure that POA IDs are active in the system while executing transaction in DPMAS from the facility to view the POA signatures provided on various screens of DPMAS.

d. DPs are advised to maintain POAs by detaching all deactivated POA IDs and POA Holders from client accounts as well as detaching closed authorised signatory from POA IDs.

For any clarification with respect to POA Registration, DPs are requested to get in touch with Mr. Harsh Kotak / Mr. Yogesh Parve on 022-24994487/24994490 or email id - harshk@nsdl.co.in / yogeshp@nsdl.co.in

B. System Security Enhancements:

The current DPMAS provides facility for User ID creation and maintainence, change of password (voluntary) and access control to different functions defined in DPMAS. The system is now being enhanced to enable DPs to define policies for userid and password. Facility is also included to define multiple administrators.

This version features system enforced policies for User ID and password complexity, expiry, history etc. to help DP to implement good practices concerning user authentication. In order to achieve this, DPs are advised to design and implement adequate procedures in line with the enhanced system security module of DPMAS.

The system is also enhanced to maintain the session information for every user logged on to DPMAS. It would allow DP to configure multiple administrator ids in DPMAS. The Module would also provide new reports giving master information of User IDs, User Groups, changes to the same and user session information.

The enhanced secuirty policy for User ID and password would be installed with default parameters which can be modified by DPs to best suit their organisational security requirements.

The following logical access controls would be enforced on all User IDs created by administrators in DPMAS.

1. User ID Policy:

Rules for creating User ID :.

a. The length of User ID should be within the range of minimum and maximum values defined in security configuration details.

b. User ID can comprise only alphabets (A-Z) (case insensitive), only numerals(0-9) or combination of both. Special characters, ie any characters other than those mentioned above, would not be allowed.

c. The existing User IDs which are not compliant to aforesaid criteria would remain active in the system even after the new software version is applied on DPMAS. However, an alert message "Your user id is not adhering to the standards. Please contact your administrator to revoke this id and assign new one" would be displayed to these users after every login in DPMAS. System administrator of DPs are advised to revoke such ids and allot new ids to these users at the earliest. An exception report in text file format would be provided as a part of this version release to identify such invalid ids. Upon executing ExceptionReport.bat file in "C:\Exeception_Report_Invalid_Userid" directory on C drive, the report would be generated in the same folder. Compliance officer will monitor this exception report

d. Inactive users which are not logged on to either DPMAS or GISMO applications since specific number of days (as per the configuration parameter given below) would be automatically blocked in DPMAS at next Beginning Of Day (BOD). Only administrator can then activate such User-Ids.

Configurable Parameters :

The table given below lists various configuration parameters applicable to User IDs. These parameters can be set by DP to suit its organizational needs. However, the parameter would be bound by the minimum fixed threshold values supplied along with installation of the software. For example, fixed threshold value for 'Minimum length' of User ID would be set to 3. Whereas DP would be able to define their own minumum length for User IDs, it cannot be less than 3 characters.

Sr No	Parameter Name	Description	Measured in terms of	Threshold Value	Rules for setting new value by DP
1	Minimum Length	Minimum Length of User ID	Number of Characters	3	New value should be greater than or equal to Threshold Value
2	Maximum Length	Maximum Length of User ID	Number of Characters	8	New value should be less than or equal to Threshold Value

2. Password Policy

Rules for defining Passwords :

a. The length of the password should be within the range of minimum and maximum values defined in the security configuration details.

b. The password should mandatorily contain any of the following two character sets.

i. Alphabets [A-Z] (case insensitive)

ii. Numerals [0-9]

iii. Special Characters

c. The password should contain the minimum 'X' number of characters from a character set where 'X' is defined as minimum number of characters for the respective character set in Security Configuration Details. For example, if 2 alphabets have been configured as 'minimum characters' for the character set 'Alphabets' then the password should contain alteast 2 alphabets.

d. DPMAS would allow only specific special characters in password. Special characters for this purpose would be configurable in Security Configuration Details against the parameter - 'Special Char Allowed' .

e. The password would expire after specific number of days of last password change date. Upon expiry, user would be forced to change the password. The number of days for password expiry would be configurable in Security Configuration Details against the parameter 'Lifetime of Password' .

f. Warning messages for password expiry will be displayed before specific number of days from the date of password expiry. These warnings would be displayed every time the user logs in using that User ID. The number of days can be configured against parameter 'Reminder Time Period'.

g. The User ID would be locked on specific number of consecutive unsuccessful login attempts. The number of unsuccesful attempts allowed would be defined in Security Configuration Details against parameter 'No. of unsuccessful attempts'. Only administrator would be allowed to unlock the User ID.

h. The history of previous passwords of each User ID would be maintained in DPMAS. The number of passwords which would be recorded in DPMAS would be configurable in Security Configuration Details against parameter 'Password Change History'. Neither the user, nor the administrator can use these passwords as the new password.

i. The user would not be allowed to change the password twice in the same day. However administrators can reset the password to enable uninterrupted functioning of UserID.

j. The system would force the user to change the password at first time log-in under following scenarios

i. When a new User ID is created, the default password would be set same as 'User ID'. User would be forced to change the password on first log in.

ii. On activation of a suspended, blocked as well as locked User-id by administrator, system would force the user to change password on first login after reactivation. User may use the old password to identify himself/herself before changing the password.

iii. Administrator overrides the password of the user-id.

DPs are advised to ensure that owner of the User ID changes the password immediately under all the aforesaid scenarios.

Default Values of Configurable Parameters and allowable values

The table given below lists various configuration parameters applicable to password. These parameters can be set by DPs to suit their organizational needs. However, the parameter would be bound by the fixed threshold values supplied along with installation of the software. For example, fixed threshold value for 'Minimum length' of password would be set to 8. Where as DP would be able to define minumum length for password, it cannot be less than 8.

Sr No	Parameter Name	Description	Measured in terms of	Threshold Value set by NSDL	Rules for setting new value by DP
1	Minimum Length	Minimum length of password	Number of characters	8	New value should be greater than or equal to Threshold Value
2	Maximum Length	Maximum length of password	Number of Characters	16	New value should be less than or equal to Threshold Value
3	No. of Alphabets	Minimum number of alphabets required in password	Number of alphabets	2	New value should be greater than or equal to Threshold value. Applicable if alphabets are chosen for the password.
4	No of Numerals	Minimum number of numerals required in password	Number of Numerals	1	New value should be greater than or equal to Threshold value. Applicable if numerals are chosen for the password.
5	No of Special Chars	Minimum number of special characters required in password	Number of Characters	1	New value should be greater than or equal to Threshold value. Applicable if special characters are chosen for the password.
6	No of unsuccessful attempts	Number of unsuccessful login attempts with wrong password after which the User ID is blocked.	Number of attempts	5	New value should be less than or equal to Threshold value
7	Life Time of Password	Number of days from last login, after which the password would be marked expired	Number of days	60 days	New value should be less than or equal to Threshold value
8	Reminder Time Period	Number of days before password expiry, from when the warning message is displayed	Number of days	10	New value should be greater than or equal to Threshold value
9	Block Period	If User ID is not used for number of days mentioned as block period, the User IDs would be blocked in DPMAS	Number of days	60 days	New value should be less than or equal to Threshold Value
10	Password Change History	Number of passwords remembered by system such that new password cannot be one of these passwords	Number of passwords	5	New value should be greater than or equal to Threshold value
11	Special Char Allowed	List of special characters which would be allowed in password	List of special characters		New value should be any character within the character set defined in threshold value

 

3. Multiple Administrator ids.

After this version release DPMAS would permit DP to define multiple administrator User IDs.

a. The existing "Admin" User ID would remain as is and would act as Super administrator id. The functional rights of this User ID would be retained as it is. In addition, more administrator User IDs can be created by 'Admin' User ID.

b. The following table lists major differences in functional rights of 'Admin' user and new administrator User Ids

Functional Rights	Admin User	New Administrator
GISMO Functions
Message Control Panel	Allowed	Allowed
Communication	Allowed	Allowed
Back-Office	Transaction Import and Bulk Verify/Release not allowed. Rest of import and exports would be allowed.	All import and export functions would be Disallowed
Shut Down	Allowed	Allowed
System Security	Registration and Maintainence of both Administrator and Functional User IDs would be allowed	Registration and maintainence of only functional users ids would be allowed
Administrative Tools	Allowed	Allowed
Inquiries	Allowed	Allowed
Instruction Capturing and Verify/Release	Disallowed	Disallowed
Reports	Only System Security related reports would be available	Only System Security related reports would be available
Setting User-id/Password policy	Yes	Yes

c. The password polices would be applicable to both 'Admin' user as well as new administrator ids. However following rules for 'Admin' user would differ from other User IDs,

i. Admin User ID would not be locked on unsuccessful login attempts due to incorrect passwords

ii. There would not be any restriction on number of times the password can be changed for Admin User ID in a day.

iii. Password change of Admin User ID would not be enforced after version release.

d. User ID policies would be applicable to only new administrator. Super Administrator would be exempted from this policy.

4. Session Information:

After this version release, Session information such as login-id used, log-on timestamp, log-off timestamp and the terminal name would be recorded in DPMAS. DPMAS would record the logoff timestamp only if user logs off gracefully from the session. The system would also maintain the information regarding the unsuccessful login attempts such as log-in id, log-in timestamp and terminal name. The information of both successful and unsuccesful log-in attempts would be provided to Administrators in the form of report.

5. Reports:

The application would provide the following reports to the administrators. These reports would not be available to functional users.

1. User Profile Report: This report would provide the details of all User IDs registered in DPMAS along with their activation, suspension, deactivation dates and its current status. Report can be generated based on

1. User ID range
2. Status of User ID
3. Date range of user creation
4. Combination of any of above parameters.

2. Group Access Rights Report : This report would provide the details of groups registered in DPMAS along with the access rights and its current status. Report can be generated based on the group id range.
3. Audit Report : This report would provide three options to generate the report giving audit details of changes in user profile and user group

1. Audit Report of User Profile: This report would provide the details of changes in group, alternate group allocation-de-allocation and status of User ID. DP can generate the report based on

1. User ID range
2. Date range of modification
3. Combination of both.

2. Audit Report of User Group: This report would provide the details of changes in name and status of user group registered in DPMAS. DP can generate the report based on

1. Group Id range
2. Date range of modification
3. Combination of both.

3. Audit Report of Functional Rights: This report would provide the details of changes in Functional rights of user group registered in DPMAS. DP can generate the report based on

1. Group Id range
2. Date range of modification
3. Combination of both.

4. Session information report: This report would provide the login details of various User IDs. DP can generate this report based on

1. User ID range
2. Application Name (NSDL-DPM and GISMO)
3. Login date range
4. Combination of all above.

It would also provide an option to generate report for failed log-in attempts only.

Important Note:

Depository Participants are requested to note the following points:

1. After version release, all User IDs would be forced to change the password. It is therefore suggested that the user involved in instruction capturing and verify/releasing logs-in immediately after this release is applied on server.
2. The last log-on timestamp of all the existing User IDs would be set to current date and time during this version release. This logon timestamp would be reflected in "User Profile Report" as "User Last Login Date".

For any clarification with respect to system security module, DPs are requested to get in touch with helpdesk.

C. Transaction Statement (SOT) for closed accounts

NSDL has vide circular NSDL/POLICY/2006/0014 dated May 11, 2006 has advised DPs to provide the Statement of Transaction (SOT) to client, which has requested for closure of the account, for the period from the beginning of the quarter in which the account is closed till the date of closure. In this regard, in the version 7.0 of DPMAS, a new check box has been provided with respect to SOT in the input screen of the report to extract SOT of only closed client accounts. DPs are advised to provide the date range to extract the SOTs for the closed accounts

For any clarification with respect to SOT for closed accounts, DPs are requested to get in touch with Mr. Harsh Kotak on 022-24994487 or email id - harshk@nsdl.co.in

For and on behalf of
National Securities Depository Limited

sd/-

Bhushan Maideo
Vice President