Pledge and Hypothecation — borrowing against your shares

Shares as collateral, without giving them up

An investor holding ₹20 lakh of shares does not want to sell them to raise ₹8 lakh. He wants to borrow against them. The demat system lets him do exactly that, and the legal authority is short and specific: the creation of pledge and hypothecation against securities held in demat mode is permitted under Section 12 of the Depositories Act, 1996.

Securities — free balances or lock-in balances — held in a depository account can be pledged or hypothecated against a loan, credit, or such other facility availed by the beneficial owner of such securities. Note that lock-in shares can be pledged. What they cannot be, until the lock-in ends, is invoked — and that distinction is worth carrying from the first page.

Two names to fix immediately:

• The borrower who offers the securities is the pledgor
• The lender who receives the security interest is the pledgee

The one rule about which depository

Both parties to the agreement — the pledgor and the pledgee — must have a beneficial account with the same depository, as inter-depository pledge is presently not permitted.

But — and this is the half candidates drop — both parties need not have their depository account with the same DP.

So: same depository, yes. Same DP, not necessary. A borrower with an NSDL account cannot pledge to a lender holding a CDSL account. He can happily pledge to an NSDL lender sitting with a different DP in a different city.

Pledge or hypothecation? One test only

The workbook gives a single discriminator, and it is about control, not about paperwork, amount or type of lender.

The nature of control on the securities offered as collateral determines whether the transaction is a pledge or hypothecation.

One footnote in the workbook decides a whole family of exam questions: the term "hypothecation" is used only in NSDL. Consistently with that, invocation of hypothecation is not applicable in CDSL.

The standing instruction on the lender's side

A lender who takes pledges all day does not want to confirm each one by hand. The pledgee BO has the facility to give standing instructions for accepting pledge instructions in his favour, either at the time of opening the demat account or at a later date — so pledge requests initiated by the borrower are automatically accepted in the lender's favour.

In NSDL this is implemented as a flag: the "Standing Instruction Indicator for Auto Pledge Confirmation". Where it is enabled, the pledge instruction automatically gets confirmed and the status is updated as "Pledged", without the pledgee needing to submit a Pledge Request Form for confirmation.

The life cycle in one paragraph

The pledgor initiates the creation of pledge/hypothecation through its DP, and the pledgee instructs its DP to confirm the creation. The pledge so created can then go one of two ways. On repayment of the loan, the pledgor initiates the closure through its DP and the pledgee instructs its DP to confirm the closure. If the pledgor defaults in discharging his obligation under the agreement, the pledgee may invoke the pledge — after taking the necessary steps under the terms of the agreement with the pledgor and as stated in the Bye-Laws of the depository and the rules and regulations framed by SEBI.

Everything below is that paragraph in detail.

What the Pledge Request Form must contain

SEBI has prescribed what goes into the form itself.

The Pledge Request Form prescribed by the depositories must contain provisions requiring both the pledgor and pledgee to provide specific undertakings. In particular:

• The pledgee shall undertake to give reasonable notice to the pledgor and comply with Sections 176 and 177 of the Indian Contract Act, 1872
• Both parties shall further undertake to adhere to the provisions of the Indian Contract Act, 1872, the Depositories Act, applicable SEBI Regulations, circulars, and bye-laws in force from time to time
• Depositories shall maintain a standardised format for the Pledge Request Form

And on the far end of the life cycle: upon invocation of a pledge, the depository shall notify both the pledgor and pledgee, confirming the invocation and that the pledgee has been recorded as the beneficial owner in accordance with Regulation 79(8) of the DP Regulations.

Creation — what actually happens in the system

A pledge transaction needs an identification, which may be an agreement number. There can be any number of pledge/hypothecation transactions between the same set of pledgees and pledgors, and each must be identified separately by a unique system-generated number — the "pledge sequence number" — in the DP system, with a separate set of instructions given against each.

Two facts about the agreement number sit right next to each other:

• Multiple pledge instructions can be executed on the basis of a single agreement. In such cases, the same agreement number should be quoted for all the pledge instructions.
• Entering the agreement number is optional in the CDSL system.

The sequence:

1. The pledgor submits the request form containing all details — the securities to be pledged, the agreement number, the closure date of the pledge/hypothecation (this date is indicative of the duration), and the pledgee's details
2. The DP verifies the form for completeness and validity and ensures the securities to be pledged exist in the pledgor's account. If it is not in order, it is returned to the pledgor for correction
3. If the form is complete in all respects, the DP accepts it for processing and issues an acknowledgement to the pledgor
4. The DP enters the details in the DP system, on which a pledge sequence number for the request is generated
5. The DP then verifies it and confirms the request
6. Securities are debited from the free or locked-in balances and credited as "pledge setup balance" in the demat account of the pledgor
7. The DP intimates the pledge sequence number to the pledgor

Two flexibilities candidates rarely expect:

• The pledgor BO has the facility to set up the pledge request even in case of insufficient or nil balance in the pledgor BO account
• The pledgor BO has the facility to set up a pledge request with a future date as the execution date. And if none is given — if the execution date is not mentioned in the Pledge Request Form, the business date on which the pledgor DP verifies the pledge is taken as the execution date

The electronic routes

In CDSL, where both BOs are registered for the easiest facility, the BO can pledge as pledgor and the pledgee BO can accept as pledgee, and the pledgee can execute the confiscation if the pledgor fails to fulfil the obligation. The BO also has the facility to initiate the pledge for the purpose of margin from the easiest login, and the CM can accept a margin pledge from its easiest login as pledgee, as well as re-pledge the securities to the CC as pledgor.

In NSDL, the instruction can also be submitted by a client whose depository account is registered for the e-Token based facility for accessing the SPEED-e facility.

Confirmation by the pledgee

Once a pledge request has been created and verified, the pledgor submits the duly stamped and signed PRF to the pledgee, along with the letter generated confirming the pledge set-up. In parallel, the details are electronically communicated to the DP system of the pledgee's DP for confirmation, and the request is displayed there.

In CDSL, if the pledgee DP has not obtained a standing instruction from the pledgee BO to confirm the pledge set-up, the pledgee BO shall submit a duly signed PRF to its DP with the PSN.

The DP compares the details on the form with the details shown by the DP system against the pledge number. On being satisfied, the DP executes the order accepting or rejecting the request. In the case of rejection by the pledgee, the DP enters the reason for rejection in the DP system as specified in the form, and confirmation of the acceptance or rejection is electronically communicated to the DP system of the pledgor's DP.

What you then see:

• Acceptance appears in the DP system of both DPs as a status change. The status of the pledge instruction changes to "Accepted-Verified".
• Once the pledge is confirmed, the statement of holding shows the quantity of pledged securities separately as "pledged balance".
• The reason for rejection is displayed in the DP system of the pledgor's DP.
• The pledgor's DP cannot cancel the pledge order after confirmation of creation by the pledgee.

And a deadline that applies in one depository only: the DP of the pledgee must confirm the creation of the pledge before the date of expiry of the pledge mentioned in the request form submitted by the pledgor — not applicable in the case of NSDL.

Same DP makes no difference

A pledgor and pledgee may have their accounts with the same DP or with different DPs. The procedure does not change. Even if both have their accounts with the same DP, the procedure of receiving the pledge confirmation from the lender has to be followed.

The line the exam quotes almost verbatim: the pledge will get credited only after the confirmation advice is entered in the DP system. That is the moment the transaction is complete — not when SEBI approves anything, not when the depository nods.

Closure — the unpledge

The pledgor can request un-pledging or closure of the pledge after the performance of the underlying agreement, meaning after the loan is repaid. In the CDSL system, pledge closure is referred to as unpledge.

The flow mirrors creation, with the roles the same way round:

1. The pledgor submits an instruction in the prescribed form to its DP. The DP verifies for completeness and validity, returns it for rectification if not in order, and issues an acknowledgement if it is
2. The DP compares the details with those displayed against the pledge instruction number, and enters the closure request in the DP system against that number
3. The details are communicated electronically through the depository system to the pledgee's DP for confirmation
4. The pledgee's DP furnishes the details of the closure requests to the pledgee, who submits his acceptance or rejection in the prescribed form
5. The pledgee's DP verifies, acknowledges, compares, and executes the order accepting or rejecting the closure
6. The acceptance or rejection is electronically communicated to the DP system of the pledgor's DP

The outcome is the important part:

• Securities accepted for un-pledge or closure get debited from the pledged balances of the pledgor and credited to its free or locked-in balances
• In case of rejection by the pledgee, the securities continue to remain as pledged balances in the pledgor's account

Why a lender might refuse to unpledge

The workbook lists the standard rejection reasons, and they are worth reading as a list of things that go wrong in practice:

• Un-pledge / Closure date not accepted
• Pledged quantity not accepted
• ISIN not accepted
• Security details not accepted
• Market value of pledged ISINs insufficient
• ISIN delisted from trading
• POA not received from all holders
• Holders not acceptable to the pledgee
• Agreement number differs from that on the agreement
• Others

These rejection reasons are not present in the CDSL system. If the pledgee DP is rejecting the unpledge request there, he enters the reason in a remark field provided for the purpose.

Unilateral closure

Sometimes the lender wants to let go and the borrower is not around to ask. The facility for unilateral closure (unpledge) of pledge by the pledgee is provided by the depositories.

The pledgee submits an instruction in the prescribed form to its DP to initiate unilateral closure. The process is otherwise the same as ordinary closure, with one decisive difference: no action — confirmation or rejection — is required to be taken by the pledgor and/or the pledgor's DP.

Invocation — when the borrower defaults

If the pledgor fails to discharge his obligations under the agreement of pledge, or for any other reason, the pledgee may invoke the pledge. He can then claim the beneficial ownership of the concerned securities after taking the necessary steps in terms of the pledge agreement, the Bye-Laws of the depository and SEBI regulations.

The mechanics:

1. The pledgee fills up the Invocation Request Form (IRF) and gives it to his DP
2. The DP verifies the form for completeness and validity, returns it if not in order, accepts it for processing and issues an acknowledgement to the pledgee
3. The DP compares the details on the form with those displayed against the pledge number
4. The DP enters (maker) the invocation request details in the DP system against the pledge instruction number and verifies (checker) the details
5. On verification, the securities are transferred from the "pledged balance" of the pledgor's beneficial owner account to the "free balance" of the pledgee's beneficial owner account

Two rules define pledge invocation:

• In the case of pledge, no confirmation is required in the DP system of the pledgor's DP for transferring securities from the pledgor's account to the pledgee's account. That is the unilateral right, working exactly as advertised
• If the pledge is for lock-in securities, the invocation request cannot be set up till the lock-in period is over. Locked-in securities cannot be invoked before the lock-in release date.

In the case of hypothecation, the pledgor instructs its DP to confirm the invocation of the hypothecation in the DP system. That single sentence is the whole difference in operation.

Invoking a hypothecation (not applicable in CDSL)

The lender submits a request in the prescribed form to his DP, which verifies, acknowledges and compares as usual. But then: on receiving the instructions from the borrower, the DP executes the order accepting or rejecting the invocation request in the DP system. In case of rejection by the borrower, the DP enters the reason for rejection, the acceptance or rejection is communicated to the DP system of the lender's DP, and the securities continue to remain as pledged balances in the borrower's account.

Stamp duty on invocation

Under Rule 5(7) of the Indian Stamp (Collection of Stamp-Duty through Stock Exchanges, Clearing Corporations and Depositories) Rules, 2019: in the case of transfer of securities pursuant to invocation of pledge, duty shall be collected from the pledgee on the market value of the securities.

Operationally that means the consideration is to be obtained in the case of "pledge invocation" from the pledgee, along with the Pledge/Hypothecation Form. Note who pays — the pledgee, the party receiving the shares.

Who gets the dividend on pledged shares?

This one is asked directly, and the answer surprises people.

Ownership of the pledged or hypothecated securities remains with the pledgor (borrower) until the pledge is invoked. Hence all corporate benefits — cash and non-cash — like dividends, bonus, rights etc. will accrue to the borrower.

The mechanics differ by benefit type:

The pattern is consistent: cash flows out to the borrower; new securities stay inside the pledge. A lender who took 1,000 shares as collateral does not lose his cover because the company issued a bonus.

The DP's checklist

Box 9.1 in the workbook lists what a DP must do when processing a pledge request:

1. Ensure that the instruction form is submitted in duplicate
2. The pledgor DP and the pledgee DP each shall create at least two users to implement the maker-checker feature, and ensure that all compulsory fields in the instruction form are entered
3. Ensure that the request for confirmation of pledge is given before the closure date mentioned in the instruction form — not applicable in the case of NSDL
4. The DP shall maintain copies of all Pledge Request Forms (PRF), Unpledge Request Forms (URF) and Invocation Request Forms (IRF) for a minimum period of 5 years, or any such period informed by SEBI/NSDL/CDSL from time to time

Non Disposal Undertakings

Not every encumbrance is a pledge. Some shareholders, primarily promoters, enter into non-disposal agreements or non-disposal undertakings (NDU) for borrowing funds from various lenders.

NDUs are typically undertakings given by a shareholder not to transfer or otherwise alienate the securities, and are in the nature of a negative lien given in favour of another party, usually a lender. No securities move. Nothing is credited to the lender. The shareholder simply promises not to sell.

Why the depository is involved at all: the SEBI (Substantial Acquisition of Shares and Takeovers) Regulations, 2011 require promoters of a company to disclose details of their encumbered shares, including NDUs by promoters, which are covered under the scope of disclosures of "Encumbrances". To make that disclosure verifiable, depositories are permitted to offer a system for capturing and recording NDUs.

The specifics:

• DPs of clients on whose securities a hold is created for NDU shall be charged at 0.01 percent of the value of securities upon creation of hold, subject to a minimum of ₹25
• SEBI, by its circular dated July 24, 2020, advised the depositories to record all types of encumbrances specified under Regulation 28(3) of the SEBI (SAST) Regulations, 2011
• All other encumbrances are to be treated as "Other Encumbrances" in the CDSL system
• The PAN of the ultimate lender is required to be mentioned on the form
• The NDU / lien / encumbrance reason is compulsory

Lien, defined

The workbook gives a precise definition worth quoting: lien is the right of a creditor in possession of goods, securities or any other assets belonging to the debtor to retain them until the debt is repaid, provided that there is no contract express or implied to the contrary. It is a right to retain possession of specific goods or securities or other movables of which the ownership vests in some other person, and the possession can be retained till the owner discharges the debt or obligation to the possessor. It is a legal claim by one person on the property of another as security for payment of a debt.

Notice the structural contrast with an NDU. A lien is about retaining possession. An NDU is a negative promise by someone who keeps possession.

Margin pledge — collateral for trading

Until 2020, brokers routinely took clients' shares into their own demat accounts as margin. That is how client securities went missing when brokers failed. SEBI closed the door.

SEBI, by circular dated February 25, 2020, specified that margin obligations can be given by way of pledge/re-pledge in the depository system. The provisions came into effect from August 1, 2020.

The core rules:

• TMs and CMs may accept collateral from clients in the form of securities only by way of "margin pledge", created in the depository system in accordance with Section 12 of the Depositories Act, 1996 read with Regulation 79 of the SEBI (Depositories and Participants) Regulations, 2018 and the relevant Bye Laws of the depositories
• Transfer of securities to the demat account of the TM/CM for margin purposes — that is, title transfer collateral arrangements — shall be prohibited
• Where a client has given a POA in favour of a TM/CM, such holding of POA shall not be considered as equivalent to the collection of margin by the TM/CM in respect of securities held in the demat account of the client. This also came into effect from August 01, 2020
• Depositories were advised to provide a separate pledge type, "margin pledge"
• The TM/CM is required to open a separate demat account for accepting such margin pledge, tagged as "Client Securities Margin Pledge Account"

The three-link chain

For the purpose of providing collateral in the form of securities as margin, a client can margin pledge securities with the TM, the TM can re-pledge the same with the CM, and the CM in turn can re-pledge the same to the Clearing Corporation (CC).

The complete trail of such re-pledge shall be reflected in the demat account of the pledgor. The client can see, in his own account, exactly how far down the chain his shares have travelled.

The operational detail from Annexure 3:

• The client shall initiate the margin pledge only in favour of the TM/CM's separate client securities margin account tagged as "Client Securities Margin Pledge Account", through physical or electronic instruction. Such instructions shall have details of client UCC, TM, CM and Default Segment
• Where a client has given a POA to the TM/CM, the TM/CM may be allowed to execute the margin pledge on behalf of such client to that tagged account
• The pledge request form shall have a clause regarding express consent by the client for re-pledge of the securities by the TM to the CM and further by the CM to the CC
• The status of the instruction remains pending till confirmation is received from the client/pledgor. The client submits acceptance by way of One Time Password (OTP) confirmation on the mobile number or registered e-mail id of the client, or other verifiable mechanism. Such OTP confirmation from the client is also required if securities of such client are being re-pledged
• In the client account, margin pledge or re-pledge shall be reflected against each security — whether it is pledged or re-pledged, and in whose favour, i.e. TM/CM/CC
• The TM can re-pledge only in favour of the CM's demat account tagged as "Client Securities Margin Pledge Account". The CM shall create a re-pledge of securities on the approved list only to the CC, out of the "Client Securities Margin Pledge Account". While re-pledging to the CC, the CM/TM shall fully disclose the details of the client-wise pledge

Releasing a margin pledge

The TM/CM may release the margin pledge after their internal exposure and risk management checks. The request for release of pledge can be made by the client to its DP or to the TM/CM, who shall release the pledge in the depository system.

Where the securities have gone all the way to the CC: the CM shall make a request to the CC. The CC shall do a margin utilisation check at the CM level before releasing the re-pledge of securities to the CM. The CC will release the re-pledged client securities to the CM after blocking other available free collateral of the CM. The CM and TM then release down the chain.

Selling pledged shares — release for early pay-in

If a client sells shares that are sitting under a margin pledge, the old way needed a chain of instructions. Now: where a client sells securities which are pledged in favour of the TM/CM as margin pledge securities (including pledge funded stock) or CUSPA pledge, depositories shall provide a functionality of single instruction in the form of "pledge release for early pay-in" to the TM/CM. Under this facility, the pledge will be released and an early pay-in will be set up immediately in the client's demat account, subject to pay-in validation — i.e. only to the extent of the delivery obligation of the client as provided by the CCs to the depositories. This functionality works without requiring any physical instructions, electronic instructions, or DDPI/POA.

Invoking a margin pledge

SEBI, through its circular dated June 3, 2025, introduced a framework for handling the invocation of margin pledged securities (including pledged funded stock).

And the default cascade, from Annexure 3: in case of default by a client of a TM who has pledged securities with the TM, the TM shall invoke the pledge. Where the securities were re-pledged with the CM, the TM makes the invocation request to the CM, the CM releases the re-pledged securities to the TM's Client Securities Margin Pledge Account, and the TM in turn invokes the pledge. Where they went all the way to the CC, the CC blocks equivalent available free collateral provided by the CM and releases the re-pledged securities of that defaulting client to the CM, who passes them to the TM, who invokes in the client's account.

One protection matters more than all the rest: in case of default by the CM, the CC shall invoke securities pledged by the CM. After exhausting the CM's own collateral, the CC may also invoke re-pledged securities of a client who has an open position. The re-pledged securities of other clients who did not have any open position with the CC shall not be available to the CC for invocation to meet the settlement default of the CM.

How the CC values collateral

From Annexure 4, two numbers matter:

• The CC requires a minimum 50% of the collateral to be deposited in cash and cash equivalent. If the total securities pledged by the CM with the CC exceed the total cash and cash equivalent, the value of securities will be restricted to the amount of cash and cash equivalent
• The CC shall not allow any exposure to the CM on re-pledged securities of the client/TM. Where such a client trades, the CC shall first block the available collateral provided by the CM, and at periodical intervals — latest by end of day — the CC shall release the blocked securities collateral of the CM to the extent of the re-pledged securities collateral of that client/TM available with the CC

Also worth holding: the day-to-day real-time risk management with respect to client/TM exposure and margin requirement shall continue to be the responsibility of the CM; the CC shall not monitor client-level exposure against available client-level collateral in real time. And the TM's proprietary margin requirement will be treated as a client of the CM and aggregated along with other clients.