Pledge sequence number
Also written PSN · Pledge sequence number (PSN)
The unique number the DP system generates for each pledge or hypothecation request, identifying that transaction for confirmation, closure and invocation even when many pledges exist between the same parties.
In plain language
A borrower may pledge shares to the same lender many times - one pledge for a car loan, another for a business overdraft, a third when the overdraft limit is raised. All of them involve the same two people, perhaps even the same shares.
The depository system cannot rely on names to tell those pledges apart. So the moment a DP enters a pledge request, the system generates a pledge sequence number (PSN). From then on, everything that happens to that pledge - the lender's confirmation, a later closure, an invocation after default - is done against that number.
The PSN is the pledge's identity. The agreement number, by contrast, is the loan contract's reference and may be shared by several pledges.
How it works
From Chapter 9 (sections 9.2.2 to 9.2.6):
Why it exists. There can be any number of pledge/hypothecation transactions between the same pledgees and pledgors. Each must be identified separately by a unique system-generated "pledge sequence number" in the DP system, and a separate set of instructions must be given against each.
Agreement number vs PSN. A pledge transaction needs an identification which may be an agreement number. Multiple pledge instructions can be executed under a single agreement, and then the same agreement number is quoted for all. Entering the agreement number is optional in CDSL.
Lifecycle.
- Creation. The pledgor submits the Pledge Request Form (securities, agreement number, closure date, pledgee details). The DP enters it; a PSN is generated; the DP verifies and confirms. Securities move from free or locked-in balance to pledge setup balance, and the DP intimates the PSN to the pledgor. A pledge may be set up with a future execution date, or even with insufficient/nil balance.
- Confirmation. The pledgor gives the pledgee the stamped and signed PRF with the system letter. In CDSL, if the pledgee DP has no standing instruction to confirm, the pledgee BO submits the signed PRF with the PSN to its DP, which compares the form with details shown against the pledge number and accepts or rejects. Status becomes "Accepted-Verified"; holdings show "pledged balance".
- Closure / unpledge. Requests are entered and checked against the pledge/hypothecation instruction number.
- Invocation. The pledgee's Invocation Request Form is compared with details displayed against the pledge number.
The DP must retain copies of PRFs, URFs and IRFs for at least five years.
A worked example
Illustrative. Rahul borrows from Sahyadri Finance under one loan agreement, number LA-2291, pledging shares in three tranches as the limit is increased.
| Pledge | Securities | Agreement no. | PSN generated |
|---|---|---|---|
| 1 | 1,000 shares of Company A | LA-2291 | 104517 |
| 2 | 500 shares of Company B | LA-2291 | 104988 |
| 3 | 300 shares of Company A | LA-2291 | 105302 |
(The PSNs above are invented; the system generates real ones.)
- Rahul's DP intimates each PSN to him when it is generated.
- Sahyadri's DP in CDSL has no standing instruction to auto-confirm, so Sahyadri submits each signed PRF quoting the PSN; the DP matches the form to the details against that PSN.
- Rahul repays part of the loan. He asks to close only pledge 2. His unpledge request is entered against PSN 104988; pledges 1 and 3 are untouched.
- Rahul later defaults. Sahyadri invokes pledge 3 only, filing an IRF against PSN 105302. The 300 Company A shares move from Rahul's pledged balance to Sahyadri's free balance; the 1,000 Company A shares under PSN 104517 remain pledged.
All three share the same agreement number, which is why the PSN, not LA-2291, identifies each pledge.
Why NISM asks about it
Chapter 9 (Special Services - Pledge and Hypothecation, 10% weightage) introduces the pledge sequence number in section 9.2.2 and uses it through confirmation, closure and invocation. Its review questions ask when a pledge is complete (when the confirmation advice is entered in the DP system) and whether a pledge can be set up with a future execution date (yes). Questions on the PSN typically test that it is system-generated per transaction and that one agreement can cover several pledges.
Common exam traps
- One PSN per pledge transaction, even between the same pledgor and pledgee.
- One agreement number can cover several pledges; the agreement number is optional in CDSL.
- The PSN is generated by the DP system when the pledgor's DP enters the request - not chosen by the pledgor or lender.
- The pledgor's DP intimates the PSN to the pledgor.
- Closure and invocation are done against the pledge number, pledge by pledge.
- A pledge is complete only when the pledgee's confirmation is entered in the DP system, even if both parties use the same DP.
- Keep PRF, URF and IRF copies for at least five years.
Check yourself
1.When is a pledge transaction regarded as completed?
- a)When SEBI approves the proposal
- b)When the depository gives its nod
- c)When the confirmation advice is entered in the DP system
- d)When the pledgor's DP generates the pledge sequence number
Show the answer
Answer: (c) When the confirmation advice is entered in the DP system
The pledge will get credited only after the confirmation advice is entered in the DP system. That is the moment the transaction is complete.
Option D is the tempting one, because a great deal has already happened by then: the DP has verified the form, entered the details, generated a pledge sequence number, verified and confirmed the request, and securities have been debited from free or locked-in balances and credited as pledge setup balance. But all of that is the pledgor's side. The pledgee must still instruct its DP to confirm the creation, on which the status changes to "Accepted-Verified".
Options A and B invent approvals that do not exist. Neither SEBI nor the depository approves individual pledge transactions.
2.Mr. Rajiv Khanna has three separate pledge transactions with the same lender. How is each of them identified in the depository system?
- a)By the loan agreement number alone, which must be entered in both NSDL and CDSL
- b)By the pledgor's BO ID, since one pledgor can have only one pledge with a given pledgee
- c)By the ISIN of the securities pledged
- d)By a unique system-generated "pledge sequence number", with a separate set of instructions for each transaction; entering the agreement number is optional in CDSL
Show the answer
Answer: (d) By a unique system-generated "pledge sequence number", with a separate set of instructions for each transaction; entering the agreement number is optional in CDSL
The workbook: "There can be any number of pledge/hypothecation transactions between the same set of pledgees and pledgors. Each of these transactions has to be identified separately by a unique system generated number ('pledge sequence number') in the DP system and a separate set of instructions have to be given against each of these transactions." It adds: "(Entering the agreement number is optional in CDSL system)."
- A is wrong because the agreement number is optional in CDSL. Also, multiple pledge instructions can be executed on one agreement, so the agreement number cannot identify each transaction on its own.
- B is wrong: any number of transactions is allowed between the same parties.
- C is wrong: an ISIN identifies a security, not a pledge. Two pledges can cover the same ISIN.
The DP intimates the pledge sequence number to the pledgor once the request has been entered, verified and confirmed.
Where this is taught
Free preparation for NISM Series VIRelated terms
- PledgeA charge created over demat securities in favour of a lender who may appropriate them unilaterally on default — created by book entry under section 12 of the Depositories Act, not by handing over anything.
- Invocation Request FormThe form a pledgee submits to its DP to invoke a pledge after the pledgor defaults, moving the securities from the pledgor's pledged balance to the pledgee's free balance without the pledgor's confirmation.
- Pledge Request FormThe standardised form on which a pledgor initiates a pledge, carrying mandatory undertakings from both pledgor and pledgee to comply with the Indian Contract Act and give reasonable notice before invocation.
- PledgeeThe lender in a pledge or hypothecation — the party who confirms the pledgor's request through its own DP, and who is recorded as beneficial owner of the securities only on invocation.
- PledgorThe borrower in a pledge or hypothecation — the beneficial owner who offers demat securities as collateral, initiates the transaction through its own DP, and keeps ownership and corporate benefits until default.
- Agreement numberThe optional identifier a pledgor quotes across multiple pledge instructions drawn under a single loan agreement, letting the DP link related pledges to one underlying contract with a lender.
- Closure dateThe date entered on a Pledge Request Form indicating the intended duration of a pledge or hypothecation, after which the pledgee's DP must confirm creation of the pledge, except in NSDL where this rule does not apply.