UPI IPO Process

You fill in a bid on your broker's IPO screen, choose a number of lots, type a UPI ID into a field near the bottom and submit. Some minutes later your phone shows a notification from your UPI application. It does not say pay. It says something closer to authorise a block, and it names an amount, a validity date and a merchant-like identifier you have probably never seen before. Approving that request is what turns a bid into a funded application. Ignoring it, or approving it too late, leaves you with a bid that the system will discard.

Why a Broker Needs Your UPI ID at All

A stockbroker is not your bank. It can place a bid on the exchange platform on your behalf, but it has no ability to reach into your savings account and reserve money there. Under India's public issue framework the application money must be blocked in the applicant's own bank account, which only that bank can do. So a way was needed to carry an instruction from the broker's bid, through the exchange, to whichever of hundreds of banks happens to hold your account, and to get your personal authorisation on the way.

UPI already solved a very similar problem for payments: a short, portable identifier that routes to the right bank and triggers an authorisation on the account holder's own device. Reusing it for public issues meant brokers could offer IPO applications without becoming banks, and applicants could authorise a block from a phone in under a minute. The blocking itself is unchanged from the older mechanism, described in the sibling article on ASBA. UPI is the messenger, not the money.

The Chain Behind One Notification

1. You, entering a bid and a UPI ID with a registered stockbroker or other trading member.
2. The broker, which validates the bid and pushes it onto the exchange's public issue bidding platform.
3. The exchange platform, which holds the bid record and forwards the payment instruction for that bid.
4. The sponsor bank, appointed for the issue, which acts as the single point that converts exchange bid records into mandate requests on the payments network.
5. The payments network operator, which routes the mandate request to the bank that owns your UPI handle.
6. Your bank and your UPI application, which present the request to you and create the lien on your account once you approve.
7. The registrar to the issue, which later reconciles bids, demat details and blocked funds to work out allotment.

The sponsor bank is the part of this chain most applicants have never heard of, and it is the one that makes the design work. Rather than every broker connecting to every bank, the issue has one bank appointed to sit between the exchange platform and the payments network. It receives the bid file, raises the mandate requests, tracks which ones were approved, declined or left to expire, and reports the results back so the exchange and the registrar know which bids are genuinely funded. Later, it also carries the instruction to debit for allotted shares and release the rest.

Understanding this chain explains a behaviour that otherwise looks like a fault: the delay between submitting a bid and receiving the mandate on your phone. The request is not generated by the broker's app on your screen. It travels through the exchange and the sponsor bank in batches, so a gap of some minutes, occasionally longer during heavy load, is normal rather than a sign that something failed.

A Mandate Is Not a Payment

The request you approve is a one-time mandate to block funds, and it is worth separating its two distinct moments. Creation is when you approve it: your bank marks a lien for the full application amount, your available balance drops and your total balance does not. Execution is what happens later, and only if shares are allotted to you: the mandate is invoked for the value of those shares, the money is actually debited, and anything blocked beyond that value is released.

Several consequences follow. You cannot approve a mandate for a smaller amount than the one presented, because the amount is derived from your bid and the top of the price band, not chosen by you. You cannot approve it twice to increase your chances. And approving it is not paying for shares, so seeing the mandate in your app's active mandates list is a sign the block exists, not a sign that anything has been bought.

An illustration helps fix the amount. If an issue has a lot of 75 shares and an upper price band of 150 rupees, one lot is 11,250 rupees and a two-lot bid produces a mandate of 22,500 rupees. Allotment of one lot would mean 11,250 rupees debited and the balance released. These figures are invented to demonstrate the arithmetic and describe no particular issue.

The Journey of a Single Application

1. Choose the issue and the number of lots, in multiples of the lot size stated in the issue documents.
2. Choose a price within the band, or select the cut-off option where it is available to your category.
3. Enter a UPI ID that belongs to a bank account in your own name, held with a bank that supports public issue mandates.
4. Submit the bid, which the broker forwards to the exchange platform.
5. Wait for the mandate request to arrive in your UPI application, and open the app rather than relying only on the notification.
6. Check the amount, the validity date and the details shown before approving, and enter your UPI PIN to authorise.
7. Confirm afterwards that your available balance has fallen by the mandate amount and that the mandate appears as active.
8. Note the application number from the broker so you can track the bid and later check allotment status.

The route is available for applications up to a value ceiling fixed by regulation, which has been revised upwards over time. Larger applications use other routes. Because that threshold has changed more than once, confirm the current limit with SEBI or the exchange rather than assuming a figure you have read somewhere.

The Approval Window

A mandate does not sit waiting indefinitely. Each bidding day has a cut-off on the exchange platform, and the final day of the issue has its own earlier arrangement for the categories that use UPI. Intermediaries frequently set internal cut-offs earlier still, so that they have time to push bids before the platform closes. The practical effect is that the deadline you actually face may be well before the one printed as the issue closing time.

These timings are set by the exchanges and can be revised, and they are stated in the schedule for each issue, so read the specific issue's timetable and your broker's stated cut-off rather than working from a remembered clock time. The general rule that does not change is directional: apply early in the issue period, approve the mandate as soon as it arrives, and treat the last day as a fallback rather than a plan. A bid whose mandate is approved after the applicable cut-off, or left unapproved until it expires, is not a funded application, however visible it may still look on a broker screen.

Revising or Withdrawing a Bid

Bids can generally be revised during the issue period, and the mandate has to keep up. Increasing the number of lots or the bid price raises the amount that must be blocked, so a fresh mandate request is generated for the higher figure and it needs a separate approval. If you revise upward and then ignore the new request, you can end up with a revision that is not backed by funds.

Reducing a bid or withdrawing it does not put money back in your available balance the moment you tap the button on the broker's screen. The instruction has to travel back down the same chain to your bank before the lien is altered or lifted, and that takes time. Certain categories also face restrictions on withdrawing or lowering bids, so read the category rules for the issue. The article on the different applicant categories covers who may do what.

Where It Commonly Goes Wrong

1. The UPI handle is with a bank or application that does not support public issue mandates, so the request is never delivered.
2. The UPI ID belongs to an account that is not in the applicant's own name, or the PAN and demat details do not match the same person, which fails at verification even if the money is blocked.
3. The applicant expects the request instantly, assumes failure when it does not appear within seconds, and submits a second bid, producing a duplicate application on one PAN.
4. The notification is dismissed or lost, and the applicant never opens the pending mandates section of the UPI app to find it waiting there.
5. The available balance is short of the mandate amount at the moment of approval, because part of the balance is committed elsewhere or held in a linked deposit.
6. The mandate is approved after the applicable cut-off, so the bid is not considered funded even though the money has been blocked.
7. The applicant approves the mandate but never verifies that the available balance actually fell, and so does not notice a failure at the bank end.
8. The applicant deletes or revokes the mandate from the UPI app after approving it, believing it is a leftover request, which removes the funding behind a live bid.
9. The same UPI ID or bank account is reused across multiple applications in a way the rules do not permit, causing rejection of more than just the extra application.

Mandate failures are common enough, and specific enough, to have their own article in this pack on UPI mandate failure, which goes through the individual error states and what each one means. The pattern behind most of them, though, is the same: the applicant treats the mandate as a receipt rather than as a step that must be completed and verified.

After the Bidding Closes

When the issue closes, the registrar reconciles the bid records with the funded applications and works out allotment for each category. The timeline from closure to listing is compressed and is fixed by regulation, and it has been shortened over the years as more of the process moved onto electronic rails. Read the schedule printed in the issue documents for the dates that apply to your specific application.

Once the basis of allotment is settled, the instruction flows back through the sponsor bank to your bank. Mandates are executed for the value of shares allotted, the surplus block is released, and mandates behind unsuccessful applications are simply released in full. Shares are credited to the demat account named in the bid, not to whichever account you might prefer afterwards, which is another reason to check that field carefully before submitting. The articles on the allotment process and on checking allotment status cover what happens on that side.

Habits That Prevent Most Problems

• Apply on an early day of the issue period rather than in the last hours, so that a failure leaves room to retry.
• Use a UPI ID you have tested for ordinary transactions, linked to an account in your own name with the same PAN as your demat account.
• Open the UPI application and look in its pending mandates section instead of waiting for a notification that may not arrive.
• Read the amount on the mandate against your own calculation of lots multiplied by the cap price before approving.
• Verify the drop in available balance after approving, and keep both the application number and the mandate reference.
• Leave a margin in the account for scheduled auto-debits that fall due while the money is blocked.
• Never approve a mandate request that does not correspond to a bid you actually placed, and never share a UPI PIN or an OTP with anyone.

The last habit is a security point rather than a process one, but it belongs here. Because IPO seasons train people to expect unfamiliar collect requests on their phone, they are also a period when unsolicited requests are more likely to be approved without thought. A genuine public issue mandate is always the direct consequence of a bid you submitted moments earlier, for an amount you can reconstruct yourself, and it will never require you to disclose a PIN to anyone.

Seen as a whole, the UPI route is a short instruction travelling a long path. The broker cannot block your money, so the exchange and a sponsor bank carry the request to the one institution that can, and your approval on the phone is the consent that authorises the lien. Everything that goes wrong tends to go wrong at a handover: an unsupported handle, a mismatched identity, a request that arrives late or is never opened. Checking each handover is what separates an application that counts from one that merely looks like it does.