RRN
The reference number generated when a Rematerialisation Request Form is accepted — an abbreviation the workbook reuses, confusingly, for a second, different number in mutual fund restatementization.
In plain language
Whenever the depository system accepts a request, it usually stamps that request with its own reference number, so it can be tracked and matched later. For an ordinary Rematerialisation Request Form, that reference is called the RRN.
The trouble is the workbook does not stop there. It reuses the same three letters for an entirely separate number, generated by an entirely separate process, a few pages later in the same chapter.
How it works
From Chapter 7: (1) section 7.4.2 — on entering an RRF in the DP system, the system generates a "remat request number (RRN)," written on the RRF, which the Issuer or R&T Agent matches against its own intimation before confirming the request. (2) section 7.6 — on entering an MF-RRF for restatementization, the system separately generates the "Restat Request Number [RRN]," a completely different number, for a completely different asset class (mutual fund units, not equity or debt securities), which the AMC/RTA accesses electronically to confirm or reject the restat request.
Both are genuinely called "RRN" in the workbook. Nothing in the text itself flags that they are different numbers beyond the surrounding context — a candidate has to track which process a question is describing.
A worked example
Mr Kamdar submits an ordinary RRF to rematerialise 300 shares; his DP's system generates RRN 4471, which the DP writes on the RRF, and which the Issuer's R&T Agent later matches against its own intimation before confirming the request.
In a separate transaction the same week, Mr Kamdar also asks his DP to restatementize Rs 80,000 of mutual fund units back into a Statement of Account. This time the system generates RRN 9028 — the Restat Request Number — which his AMC accesses electronically to confirm the conversion. The two RRNs sit in different systems, for different assets, and neither can be used to trace the other request.
Why NISM asks about it
Chapter 7, sections 7.4.2 and 7.6, each generate a number the workbook calls "RRN." Expect a question asking what RRN stands for in a given passage — the answer depends entirely on whether the passage describes equity/debt rematerialisation or mutual fund restatementization.
Common exam traps
- "RRN" means two different things in the same chapter: a Rematerialisation Request Number (7.4.2) and a Restat Request Number (7.6) — always check which process the question describes.
- Neither RRN is the same as a DRN (Dematerialisation Request Number), which is generated when securities go into the depository — the opposite direction.
Check yourself
1.A BO who has set up a Restatementization request due to an error now wants it undone. What is permitted?
- a)The request may be modified by the DP at any time before confirmation
- b)Modification is not allowed; deletion of the RRN is allowed if it has not been downloaded by the AMC/RTA, and where the set-up was erroneous the deletion must be authorised by the BO
- c)Neither modification nor deletion is permitted once the RRN is generated
- d)Only the AMC/RTA may delete the request, on written application by the BO
Show the answer
Answer: (b) Modification is not allowed; deletion of the RRN is allowed if it has not been downloaded by the AMC/RTA, and where the set-up was erroneous the deletion must be authorised by the BO
The rule is stated in two halves. Modification is not allowed in case of Restatementization. Deletion of RRN is allowed in case of Restatementization, if the same is not downloaded by the AMC/RTA. If Restat is setup due to an erroneous request from the BO then the deletion shall be authorised by the BO.
So there is a window — but it closes the moment the AMC/RTA downloads the RRN, and within that window the BO must authorise the deletion where his own error caused it. That last requirement protects against a DP quietly reversing a client instruction.
Compare the parallel rule on the exchange side of mutual fund settlement: modification is not allowed for a Repurchase/Redemption request either. The mutual fund workflows are consistently one-way once set up.
Where this is taught
Free preparation for NISM Series VIRelated terms
- RematerialisationThe reverse of dematerialisation — the demat account is debited and the issuer prints fresh physical certificates for the same quantity, to be despatched within 30 days.
- DRNThe unique number the DP system generates once a dematerialisation request is entered, used to track that request through the Issuer or R&T Agent until it is confirmed or rejected.
- RestatementizationThe reverse of De-statementization — converting mutual fund units held electronically back into a paper Statement of Account or certificate, on the Beneficial Owner's own Restatementization Request Form.