Follow Us on Facebook

Monday, November 16, 2009

Dematerialisation of Securities

Dematerialisation is the process by which physical securities of an investor are converted to an equivalent number of securities in electronic form and credited in the investor's account with the DP. One can do this for shares in pledged condition also though with the permission of the pledgee. One can dematerialise odd lot shares also. Requests for dematerialisation shall need to be submitted only in a Dematerialisation Request Form (DRF).
2.1. Documents required
2.1.1. Completely filled up Demat Request Form (DRF) in triplicate for each ISIN along with defaced physical securities.
2.1.2. Transposition form, if applicable

2.2. Availability of forms
2.2.1. Ensure adequate stock of DRFs with you.
2.2.2. Requisition for DRF should be put to dematrating@ as per procedure mentioned in Requisitioning Stationery from CPO section.

2.3. Scrutiny of the demat request: Each demat request must be scrutinised by the branch at the time of accepting the same from the customers. If there is any discrepancy then it should be immediately pointed out to the client advising the steps for rectification. Advice the customer to take the help of Sample Filled in DRF for filling up the DRF correctly.

The scrutiny of Demat request involves the following:

2.3.1. Eligibility of Security for Demat: It must be ensured that security mentioned on the certificates is eligible for Demat.

To check eligibility, refer to the ISIN Book. You may also check the same in the New ISIN Query on DeposisWeb. Enter the first few characters of the company name in the text box for the same. Select the type of security from the drop down. Also specify the face value of the security. On hitting 'Go' the matching results are displayed. Check if the status is 'Active' and that it is 'Available for Demat'. Scrips that are not available for Demat have been highlighted with Red Colour with a remark "Scrip not available for demat".

If the name of a company has changed, it is expected that the customer will bring the certificates in the new company name. However, even if the certificates are in the old company name, they can be dematerialised under the same ISIN as earlier. When you use the ISIN query using the old name or the new name, the appropriate record will come up automatically showing the old company name also in brackets. We need not now rely on the customer's information that the name has changed and end up accepting requests which may not have been under demat.

Branch officials are advised not to accept any certificates for Dematerialisation from customers under the ISINs for National Savings Certificate (NSC)/Kisan Vikas Patra.

2.4. Following guidelines are to be followed for accepting dematarialisation requests from NRI customers:
2.4.1. NRI-Repatriable category accounts:
2.4.1.1. Duly filled in DRF along with the physical share certificates should be accepted by the branch official.
2.4.1.2. The RBI approval should be present on the share certificate. In case the approval is not present the branch official should obtain any of the below mentioned documents:

(i) Copy of letter of Allotment issued by the Company / Registrar
(ii) Copy of the letter from the company stating that the shares were allotted on repatriable basis under RBI permission No.

2.4.1.3. Copy of the share application which will state that the share application is on repatriation basis and linking of the application to the allotment letter whose quantity will match with the shares to be dematerialised.
2.4.1.4. In absence of any of the above-mentioned documents the DRFs will to be rejected.


2.4.2. Resident / NRI- Non Repariable category:
2.4.2.1. If the certificates submitted for demat are in Repatriable category, the following should be adhered:
1. Inform the client about the mismatch between the account and the certificates category.
2. If the client confirms that he wants to still dematerialize the same with intention, the branch official should obtain a declaration letter addressed to the company from the client confirming his change of status signed by all the holders.

2.5. Demat request forms (DRFs) submitted at branches are scrutinized at the Central Processing Office, Mumbai (CPO) before being forwarded to the Registrar. Any rejection during this scrutiny means that the certificates are sent back to the customer. Since the certificates have been punched and stamped, the customer has to first get duplicate certificates from the Registrar. To avoid customer dissatisfaction arising from such rejections, it is imperative that the DRFs are scrutinized meticulously at the branch on receipt from the customer and the DRFs should be returned to the customer for rectification, if required.

To assist you in such scrutiny, we have made modifications in the ISIN search module - we have introduced a “Remarks Column”, which will help you to guide the customer and reduce rejections arising from some common errors. An illustration of the remarks in each situation is given below:

There are also instances where there is an inordinate delay on the part of Registrar to confirm the demat request. NSDL maintains a list of such errant companies/registrars. To enable you to alert customers when accepting demat requests from them, the following remark will be given against such ISINs :

“As per NSDL - Company with long pending demat requests and not responding/ services stopped by the RTA. Please alert client that dematerialisation may get inordinately delayed
.”
There are cases where the name of a company has changed. In such cases, the certificates could be in old name as well as new name. Both need to be processed under the same ISIN. The old name is also updated and the ISIN can be queried using both the new name and the old name.

Sub-division/consolidation of shares - face value is different

There are instances where the shares of a company are split or consolidated. In a split, the share of a company with face value Rs. 10 may be split into 10 shares of face value Rs. 1 each. In such cases, the certificates and the ISIN representing the share of face value Rs. 10 are discontinued. A new ISIN is allotted to the share of face value Re. 1 and new certificates are sent to the share holders by the company.

In such cases, if a shareholder comes with a demat request with the old certificates, the same should not be accepted. Demat requests with only new certificates can be accepted.

In the ISIN query, in such cases, two rows will appear

  • one with the face value Rs. 10 but it will not be available for demat

  • another with the face value Re. 1 and available for demat
To avoid incorrect acceptance, apart from matching the name of the company and the security on the screen, also verify that the face value on the certificates matches exactly with the face value appearing on the screen for the ISIN and that ISIN is available for demat.

2.6. Single ISIN in one DRF: Securities having the same ISIN only can be submitted under a single DRF. However, multiple folio nos. of the same pattern of holders relating to the same ISIN can be dematerialised under a single DRF. Certificates of the same security having different ISIN (this is possible in case of partly paid up shares and non-pari passu shares) should not be accepted in the same DRF form.

2.7. Partly Paid up shares and Pari Passu Status: NSDL provides different ISIN to Non Pari Passu shares and to partly paid-up shares of a company. Verify the certificates carefully and mention the correct ISIN. A non-pari passu share is one, which is issued after the last record date and is eligible for dividend on pro- rata basis.

2.8. Lock - in status: Locked-in certificates of a security must be submitted under separate DRF. The same should not be mixed with free securities. In case of locked-in securities the lock-in reason & lock-in release date must be filled up in the DRF. Amongst lock-in securities belonging to the same ISIN but having different lock-in release dates or lock-in reason, separate DRF requests have to be made.

2.9. Names differing on account of full name and initials: Demat requests received from client(s) with name(s) not matching exactly with the name(s) appearing on the certificates merely on account of initials not being spelt out fully or put after or prior to the surname, can be processed. However, the client should be informed this is possible only if the signature(s) of the client(s) on the DRF tallies with the specimen signature(s) available with the Issuers or its R & T agent.

To give an example, the shareholder may have opened the depository account in the name of Sushil Ramesh Shah but his name on the share certificate may appear as S. R. Shah or Sushil R Shah etc.

2.10. Holding Pattern: The combination and the order of holders' names on DRF and as printed on the Certificates should be identical with that in the DP account. For knowing the holding pattern of the account, check the same in DeposisWeb - Queries & Reports - Account Information.
2.11. If the shares are in the name of X, Y (X as first holder and Y as second holder) it cannot be dematerialised in the account of either X or Y alone. Also if the shares are in the name of X, they cannot be dematerialised in the account of X, Y (X as first holder and Y as second holder).

2.12. Further, if the shares are in the name of X, Y (X as first holder and Y second holder) and the account is in the name of Y, X (Y as first holder and X as second holder), then these shares cannot be dematerialised in this account only on the basis of DRF (see exception below). The dematerialisation can be done in the account where the holding pattern is X., Y (X as first holder and Y as second holder).

Exception: Where the combination of holders is the same in the certificates and in the demat account, and the difference is only in the order in which the name of the holders appear on the share certificates and in the demat account, dematerialisation is possible. Here, the customer has to submit a Transposition Request Form along with the DRF.

2.13. Signature Verification: The DRF must be signed by all the account holder's and should be in the same order. Branches should verify client’s signatures affixed on the DRF and ensure that signatures perfectly match as per our system records. On verifying the signature on the DRF, if branch finds that there is a mismatch in the signature as signed on the DRF with that of the records in the system then they should not accept the DRF and request the client to affix the correct signature as per DP records.
Simultaneously branch should check with the client if he has a different signature registered with the Company / Registrar, and if so request the client to affix the signatures on the DRF with a remark “Signature as per R & T".

If the demat request is being submitted by a PoA (Power of Attorney) holder, a copy of the PoA should be submitted. Where the customer claims that the PoA is already registered with the Registrar, the PoA Registration No. should be mentioned on the DRF.

2.14. Details of Certificates: The details of certificates such as the folio no., certificate no., & distinctive no. must be filled up correctly in the DRF. Also, the number of certificates annexed with the DRF should tally with the number of certificates mentioned on the DRF. The certificates should be attached in the same order as mentioned in the DRF.

CAUTION: Verify this properly because if there are any mismatches between the certificate details mentioned on the DRF and the certificates attached with the DRF, the liability is on ICICI Bank for any missing certificates.

2.15. Defacing of the Certificates: All the certificates must be defaced by putting a stamp or by writing ''SURRENDERED FOR DEMATERIALISATION” by the client. However, defacing should be done only after checking the eligibility of security, as defaced securities cannot be sold in physical form. If defacing has been done by mistake then the customer should be advised to send the same to registrar for replacement.
However, the request should not be accepted if the certificates are mutilated or defaced in such a way that the material information is not readable.
In case of government securities, the same should not be defaced or mutilated either by punching holes or by any other means.

2.16. Transfer - cum - Demat: SEBI has withdrawn Transfer cum Demat since Feb. 10, 2004. Hence the branch should entertain no request under this facility.

2.17. Transmission - cum - Demat:
In case of certificates held jointly, on the death of any one or more of the joint holder(s) mentioned on the certificate, the surviving joint holder(s) can get the name(s) of the deceased deleted from the physical certificate(s) and get the securities dematerialised in the DP account of the surviving holder(s) by following the procedures mentioned below:
2.17.1. The following documents should be submitted along with the DRF :
  • A copy of the death certificate duly attested by notary.
  • Transmission form for Dematerialisation / Deletion cum Demat form.
2.17.2. Verify that the certificates are registered in the name of the Client(s) along with the name(s) of the deceased and the order of the names of the surviving holders is the same as in the Demat account.

2.18. Receiving Demat Request and acknowledging the same
2.18.1. The DRF is in triplicate.
2.18.2. Branches should ask the customer to write / stamp
2.18.3. DP ID and CLIENT ID on the face of EVERY Physical Share Certificate submitted by him for demat. ("DP ID and CLIENT ID" should be clearly visible on the share certificates. It should not be mentioned on the printed details of the certificates). This will ensure better control for the certificates submitted by the client.

2.18.4. "Surrendered for dematerialisation" should be mentioned on the face of every share certificate.

Kindly ensure that the DRF accepted at the branch bears the date of submission, date of acceptance, branch stamp and signature of the demat officer on all copies of the DRFs. Failure to do so will invite audit observations.

2.18.5. On receipt of duly filled DRF, Branch should cancel the physical share certificates by drawing two parallel lines across the physical share certificates and punch two holes on the top of the share certificates (i.e. name of the company should be punched ) and then forward the physical share certificates to CPO - Goregaon Office for processing .

2.18.6. All DRFs accepted are to be dispatched to Central Processing Office (CPO) on the date of receipt from the client. Failure to dispatch on time causes delay in processing and dispatch of certificates to respective registrars. Dispatch of DRFs (to Registrar) after 7 days from the date of receipt invites monetary penalty from NSDL / SEBI.

2.18.7. Kindly ensure that the DRF accepted at the branch bears the date of submission, date of acceptance, branch stamp and signature of the demat officer on all copies of the DRFs. Failure to do so will invite audit observations.

2.18.8. If everything is proper, issue the acknowledgement to the customer from Registrar's Copy (white copy). Retain the Branch copy (yellow colour) at the branch. Send the Registrar's copy & CPO copy (white and blue) to the Central Processing Office (CPO) at Goregaon, Mumbai.

2.19. Inwarding in the System
The DRF should be immediately inwarded in the Inwarding module on DeposisWeb. In case the system is not available, then the DRF's must be inwarded at end of day. Please refer to DeposisWeb section for help on inwarding of DRF.

2.20. Packeting & Depspatching of DRF
At the end of the day, all DRFs inwarded for the day should be 'packeted' and 'despatched' in DeposisWeb along with other documents received during the day.

2.21. Despatch of Demat Requests to Central Processing Office (CPO):
The DRF along with the physical securities should be despatched to the CPO with a covering letter.
In case the DRF cannot be inwarded due to unavailability of the system then a covering letter should be prepared in the below mentioned format
The POD (courier receipt) must be filed along with the copy of covering letter for your records.

2.22. Processing of DRFs at Central Processing Office (CPO)
2.22.1. Entry of DRF: The DRF team at CPO does the entry of the DRFs received at the CPO. At this level the complete details provided by the client in the DRF is captured in the Deposis (Back office system for ICICI Bank Demat Services).

2.22.2. Objection of DRF: If there is any discrepancy in the DRF the same is objected in the system.
2.22.2.1. An Objection reason is attached to the objected DRF.

2.22.2.2. The Demat Request is returned to the client alongwith a letter mentioning the objection reason at his correspondence address.

2.23. Generation of Demat Request Number.
2.23.1. If the DRF is in order, another user verifies the entered details and the DRF are authorised.
2.23.2. At the end of the day all the authorised DRFs are uploaded in the NSDL system and the Demat Request No. (DRN) is generated.
2.23.3. The DRNs are released in the DPM (NSDL system); this transmits the electronic request to the respective registrar.

2.24. Despatch of DRF to the Registrar
2.24.1. The DRN is updated on the Demat Request Forms.
2.24.2. The DP Authorised section is completed.
2.24.3. The DRFs along with the security certificates and a covering letter are despatched to the respective Issuer or its Registrar & Transfer Agent not later than seven days of accepting the same from the customer.
2.25. Processing of Demat Request by the Registrar
2.25.1. Confirmation of Demat Request
2.25.2. The registrar on receipt of Demat request verifies the details with that in his record.
2.25.3. If the Demat Request is in order the registrar confirms the DRN in the NSDL system and the physical securities are destroyed. The free account of the client gets credited with equivalent quantity of securities.

2.26. Rejection of Demat Request
2.26.1. Demat requests submitted at branches, after due scrutiny, are forwarded by the Central Processing Office, Mumbai (CPO) to the respective Registrars. Registrars, after due scrutiny, confirm the requests enabling credit in the demat account of the customer.
2.26.2. If the request is rejected by CPO, the certificates are sent back to the customer directly by post. If the request is rejected by the Registrar, the certificates are sent back to the DP (at the CPO) and CPO sends the same to the customers directly by post.
2.26.3. For such rejected requests, DeposisWeb now provides the following information also :

  • If the request has been rejected by the Registrar, whether the certificates have been received by CPO or not and the date on which the same have been received at CPO.
  • If the certificates sent by CPO to the customer by post have been returned undelivered, the date on which it was received back at CPO and the reason for the return. Further if the certificates have been redispatched on request by the customer/branch, the date of such redespatch.
2.26.4. The information is available under "Status of Request" on DeposisWeb. On the page, specify demat account no., DRF as the document type and DRF no. as document no. and submit. On the result page, click the Indoc no. hyperlink for details. The details page would include the following two additional blocks. These blocks are:

  • "Certificates Received Back" as given below :
The date is the date on which the lot of certificates was received. Quantity is the quantity of securities represented by the lot of certificates. If this block does not appear for a rejected demat request, it means that the certificates are yet to be received at CPO.

  • “Return By Post Details" as given below:
RBP No. Is a system-generated no. for each instance of return by post. The return date is the date on which the certificates were received back at CPO. Remarks contains the reason for the return. If the certificates have been redispatched, Redispatch date and Redispatch Out no. will contain the date of such redespatch and the system-generated Outward No. The current status of certificates sent back to customer will appear in the Status of RBP column.
If redispatched certificates are returned undelivered again, another record will appear below the earlier record.
If this block does not appear for a rejected demat request, it means that certificates have not been returned to CPO. They are either delivered to the customer or are in transit.

2.27. Loss of documents after accepting from the client
2.27.1. After the DRF and certificates are submitted by the Client at the branch, in exception circumstances, they may get lost in the following ways:
  • Misplaced at the Branch before they are sent to the CPO
  •  Intercepted in transit between Branch and CPO
  • Misplaced at the CPO before entering the same on the NSDL system
  • In case the DRF is rejected either at the CPO itself (where certificates are sent back to the customer from CPO) or at the Registrar end (where certificates are sent to the CPO and there onwards to the customer), any misplacement/interception in between.
2.27.2. In the above cases, inform the CPO immediately. In these cases, the CPO requests the Registrar for the procedure to be followed to resolve the case. The procedure typically requires execution of an indemnity by the client.

2.27.3. The CPO executes the indemnity on non-judicial stamp paper and forwards the same to the client for them to sign and return to the CPO. The CPO sends the same to the Registrar along with the forwarding letter for issue duplicate share certificate/credit in the demat account.

2.27.4. Where required, the Registrar will issue Duplicate Share Certificate(s) and send the same to the Client directly. Subsequently, Client may submit the same with fresh DRF for demat. In other cases, the Registrar may also directly credit the demat account.

2.28. Storage of DRF copy at Branch: The status of the DRF is 'Sent to CPO' on inwarding the request at the Branch. Subsequently, the status changes after being processed by the CPO.

Branches are supposed to store a copy of each DRF forwarded by them to CPO. It is suggested that Branches after inwarding and forwarding the DRF request to CPO, should file the branch copies of DRF date-wise. Every Monday, they should verify in Deposis - Status of Request for all DRFs inwarded during the week previous to the previous week for confirming change in Status. Accordingly, the copies should be destroyed.

Care should be taken to ensure that the destruction of the Branch copy is done only after confirming the change in the status of the request.

0 comments:

Post a Comment

Blog Archive

Related Posts with Thumbnails
Grab this Widget ~ Blogger Accessories
 
Site Architect - Abhishek Kamdi