IPO UPI Status Codes Explained

This is a lookup page. Search it for the exact words on your screen. Each entry says what the string means, whether money is blocked while you are reading, and where the wording comes from, because most of these strings are not written by your broker at all. They are machine codes travelling between the stock exchange, a sponsor bank, NPCI and your own bank, and your app is only relaying them.

Read this first: three systems, three different truths

The reason two screens can disagree is that they are looking at different stages of the same request, and none of them is lying.

• Your broker app shows the exchange record. It knows what the sponsor bank last reported and nothing more recent than that.
• Your payments app shows the mandate as NPCI sees it, in the mandates section. SEBI's own FAQ on UPI in ASBA points investors there for the status of an active request.
• Your bank account shows the lien. This is the only one of the three that is money rather than a message.
• A Unique Mandate Number, the UMN, is the identifier that ties all three together. SEBI's FAQ tells investors to quote it to the bank for any block or unblock complaint. Find it before you call anyone.

“A status is evidence that a block happened. A hold in your bank balance is the block. When the two disagree, the balance wins.”

Four capital letters where you expected a word: UTIB, KKBK and the rest

UTIB is not a status. Neither is KKBK. They are the first four characters of an Indian Financial System Code, the eleven-character IFSC that identifies a bank branch: four characters for the bank, a zero, then six for the branch. Seeing one in a status field means the record has picked up a bank identifier, not that something went wrong.

We decoded these against the Reserve Bank of India's own consolidated IFSC file, the List of NEFT enabled bank branches published on the RBI's NEFT page, as on 31 July 2026. It carries 182,108 branch records across 234 distinct four-character prefixes, and not one prefix is shared by two banks. The code is unambiguous.

• UTIB is Axis Bank.
• KKBK is Kotak Mahindra Bank.
• HDFC is HDFC Bank.
• ICIC is ICICI Bank.
• SBIN is State Bank of India.
• PUNB is Punjab National Bank.
• BARB is Bank of Baroda.
• CNRB is Canara Bank.
• UBIN is Union Bank of India.
• BKID is Bank of India.
• IDIB is Indian Bank.
• CBIN is Central Bank of India.
• IOBA is Indian Overseas Bank.
• IBKL is IDBI Bank.
• UCBA is UCO Bank.
• YESB is Yes Bank.
• MAHB is Bank of Maharashtra.
• INDB is IndusInd Bank.
• BDBL is Bandhan Bank.
• AUBL is AU Small Finance Bank.
• PSIB is Punjab and Sind Bank.
• FDRL is Federal Bank.
• IDFB is IDFC First Bank.
• JAKA is Jammu and Kashmir Bank.
• KVBL is Karur Vysya Bank.
• KARB is Karnataka Bank.
• CIUB is City Union Bank.
• SIBL is South Indian Bank.
• RATN is RBL Bank.
• DCBL is DCB Bank.
• ESFB is Equitas Small Finance Bank.
• UTKS is Utkarsh Small Finance Bank.

Whose bank is it, though. There are two candidates: the account the block was placed on, which is yours, and the sponsor bank the issuer appointed to raise mandates. NSE's Sponsor Bank API Protocol settles it for the successful case. The protocol defines a field named ifsc as the IFSC of the client bank account, and marks it valid and mandatory only when the payment status is 100. In other words the bank identifier belongs to your own account, and it appears once the block has actually gone through.

Sponsor banks are a small club, which makes the other possibility easy to rule out. Across the 89 issues in CAPITA1's IPO Center as on 17 August 2026, 17 records name a sponsor bank in the exchange data, and only five banks appear anywhere in them: Axis in eight, HDFC in seven, Kotak in five, ICICI in five, IndusInd in one. Nine of those seventeen issues appointed two. So if the four letters match the IFSC of the account you bid from, the record is describing your account.

Block request accepted by client. Payment successful.

This sentence is a status number wearing a description. NSE's Sponsor Bank API Protocol, version 0.14.0 of September 2023, sets out the payment statuses a sponsor bank reports back to the exchange for every UPI application. These are the exact definitions.

• 10 means block or release request accepted by sponsor bank. The mandate has been raised. Nothing is blocked yet.
• 11 means the request was rejected by the sponsor bank because the UPI handle was invalid.
• 12 means rejected by the sponsor bank for other reasons.
• 13 means rejected because the investor's bank does not support UPI 2.0.
• 21 means rejected by the client bank, that is, by your own bank.
• 22 means rejected by your own bank for a technical reason.
• 31 means rejected by the client. Someone declined the request in the payments app.
• 100 means block request accepted by client, payment successful. The lien exists.
• 110 means the release request was processed successfully. The block has been lifted.

Two things follow. First, 100 is the only value that proves a block, and it is the value that carries the account details and the amount blocked. Second, the phrase payment successful is misleading in ordinary English. Nothing has been paid. Money has been earmarked in your account, and it will only be debited if shares are allotted to you.

Confirmation status pending, and confirmation status 10

Apps label the middle of the process inconsistently: pending, awaiting approval, mandate requested, or the bare number 10. They are the same moment. The sponsor bank has taken the instruction and pushed a mandate towards your UPI handle. Your money is untouched and the application is not yet funded. The gap between 10 and 100 is exactly the gap that closes when you enter your UPI PIN and your bank places the lien.

So a screen stuck on pending is not a bank error by default. It is more often a request sitting unopened in a mandates list. Open the payments app yourself rather than waiting for a push notification, which many apps never send.

Mandate request failed, and why the app will not tell you why

Mandate request failed is a summary written by your broker's interface. It is not a code and it carries no diagnosis. The diagnosis sits one field away. NSE's protocol defines a separate rejectReason field as the rejection reason code and description as received from NPCI, and instructs sponsor banks to map it from NPCI's own error documents. Your broker can therefore quote you a specific code even when the screen you are looking at shows a sentence.

Ask for that code. It is the difference between a wrong handle, an unresponsive bank and an outright decline, and those three have nothing in common except the word failed. What every failure at this stage does share is that no lien was created, so there is no money to recover and nothing will appear in the allotment file.

UM8, UM9 and IR: the codes on a cancellation that would not go through

These three surface in messages like UPI mandate could not be cancelled due to UM8. They are NPCI response codes, published in the UPI response code list that Axis Bank hosts for its own API users. In UPI language the remitter is the payer's side, which in an IPO means you and your bank. Read them that way and they become plain.

• UM8 is defined as respmandate declined by remitter bank. Your own bank refused the mandate instruction and the transaction is marked rejected.
• UM9 is defined as respmandate timeout at remitter end. Your bank did not answer within the permitted window, so the instruction lapsed rather than being refused.
• IR is defined as unable to process due to internal exception at server or CBS on the remitter side. CBS is the core banking system. Something broke inside your bank.

Now the part that matters. On a cancellation these codes mean the cancellation failed, not that your money vanished. The original mandate was never revoked, so the block stands and continues on its ordinary schedule: debited if shares are allotted, unblocked in the exchange's fund release cycle if they are not, and lapsing at the mandate's validity end in any case. Your money is where it was. What did not happen is the removal of the hold.

Two related codes from the same published list explain the symptoms that travel with this. IE is defined as adequate funds not available in the account because funds have been blocked for mandate, which is what a working IPO block looks like from some other payment's point of view. IB is defined as revoke mandate after the remitter unblocked the amount, which is the harmless case where you tried to cancel something your bank had already released.

Mandate end: a date, not an event you missed

Every UPI mandate carries a validity window with a start date and an end date, and NPCI's specification rejects a mandate that is missing either, under codes MB0 and MB1 in the same published list. Mandate end in your app is simply that end date. It is not the allotment date, not the listing date, and not a deadline for you to do anything.

It is an outer limit on the bank's authority to touch the money. SEBI's FAQ on the use of UPI with ASBA puts it directly: where shares are not allotted, the money is unblocked or reinstated to the account with the expiry of the mandate period. In practice the release normally happens earlier, on the exchange timetable set out further down this page. The mandate end date is the backstop.

Mandate cred block not matched: the one string we could not verify

We are not going to explain this one, because we could not find it. That exact wording does not appear in the published UPI response code list we worked from, and it is not a payment status in NSE's sponsor bank protocol. The nearest documented codes are U54, transaction ID or amount in credential block does not match with that in reqpay, and UO7, mandate orgid or UMN address not matched with payer VPA address. Both concern a mismatch between a signed request and the mandate it refers to, but neither is the same string, and a guess presented as a fact is the wrong thing to hand someone whose money is sitting under a hold.

The practical move is to get the underlying code rather than the sentence. Ask your broker for the rejection reason exactly as received from NPCI, and ask your bank for the status against the UMN. Then match the code, not the paraphrase.

The mandate that never arrived

NSE's own e-IPO FAQ answers this from the broker's side rather than the investor's, which is why it is more useful than most explanations. It says that on non-receipt of the mandate the investor should check the UPI status and contact the member through whom the bid was placed, and it sets out what that member can then do.

• A member can re-initiate the bid, and the system allows that only once during the whole issue period.
• Re-initiation is only permitted after the day's bidding closes, that is, every day after 5 pm. Nothing can be resent to you at two in the afternoon.
• If the exchange platform shows the status as request sent to investor's UPI app for acceptance, the FAQ tells the member to coordinate with the investor first and then with the sponsor bank, because on the exchange's record the request has already left.
• Where a wrong UPI ID was typed, the status shows invalid UPI, and for a mainboard issue the member can cancel and re-place the bid or edit it.

That once-per-issue limit is the detail worth knowing. It is why the first job with a missing mandate is to establish whether the request is genuinely absent or merely unopened in your mandates list.

Every clock that applies to a UPI bid

These come from Annexure XXIII of SEBI's Master Circular for Issue of Capital and Disclosure Requirements, which sets the indicative activity timeline for listing on T+3, where T is the issue closing date. The SME timings are from NSE's e-IPO FAQ, following the replacement of the retail category on that platform.

• Bank ASBA and syndicate UPI ASBA applications through online channels: up to 4 pm on T day.
• Issue closure: 4 pm on T day for QIB and NII, 5 pm on T day for retail and other reserved categories.
• UPI mandate acceptance: 5 pm on T day. This is the hard one. After it the mandate cannot be acted on.
• SME issues: bidding closes at 4 pm on the last day, with UPI mandate confirmation completed by 5 pm the same day.
• Third-party check on UPI applications: completed before 9:30 am on T+1.
• Finalisation of rejections and completion of the basis of allotment: before 6 pm on T+1, with exchange approval before 9 pm on T+1.
• Fund transfer and unblocking instructions: initiated no later than 9:30 am on T+2, debits completed before 2 pm on T+2, unblocking completed before 4 pm on T+2.
• Credit of shares by corporate action: initiated before 2 pm and completed before 6 pm on T+2.
• Trading starts on T+3.

Read that list once and the common panic dissolves. Allotment is decided on T+1, money moves on T+2, and the share starts trading on T+3. A block still sitting there on the evening of T+1 is not late.

Not allotted, still blocked

This is the one situation with a number attached to it. Annexure XXI of SEBI's ICDR master circular puts the compensation for delayed unblocking at one hundred rupees per day or fifteen per cent per annum of the application amount, whichever is higher, payable by the self-certified syndicate bank. The circular's own worked example fixes the day it starts: an issue closing on 2 November 2020 has an effective unblocking date of 4 November, which is T+2, and the compensation period runs from 5 November — the day after the deadline. Where a complaint is raised and not resolved, Annexure XXII adds a second layer on the same scale from the post-issue lead managers, running from the day after the complaint, and the two are additive. Before any of that, SEBI's own FAQ gives the simpler first step: if the amount is not unblocked after the allotment is finalised, approach your bank and ask them to unblock the funds manually.

The order of escalation is set by SEBI's UPI FAQ and is worth following rather than improvising. Blocking and unblocking questions go to your bank, quoting the UMN. Allotment questions go to the registrar to the issue. Questions about the application process go to the intermediary you applied through. If none of them resolves it, the complaint goes to the stock exchange and then to SEBI's SCORES platform.

What the exchange bid verification page will not do for you

There is a widely repeated instruction to check your bid on the NSE website. It is real, and it is useless in the moment you need it. NSE's e-IPO FAQ describes the IPO bid verification module, reached from Invest and then Resources and Tools, and states plainly that the data would be available six days after the issue closure date. It is an after-the-fact audit trail, not a live tracker.

While an issue is open, the live sources are the three from the top of this page: the mandates section of your payments app, the balance and lien in your bank account, and your broker's order book. Everything else is a copy of a copy.

How much is usually blocked, and why the figure looks so uniform

One question sits behind several of these searches: whether the amount held looks right. Taking the mainboard issues in CAPITA1's IPO Center that carry both a lot size and an upper band as on 17 August 2026, fifteen records, one lot priced at the top of the band works out to a median of 14,880 rupees, in a range from 14,526 to 15,000. The block for a single retail lot clusters just under fifteen thousand rupees across those records. SEBI's UPI FAQ describes the block as being for the amount you have bid, so the hold should reconcile to your own bid quantity and price, and not to whatever price the issue is eventually priced at.

If the hold on your account is a clean multiple of a figure like that, it is behaving normally. If it is double what you bid for, that is a duplicate block, and SEBI's FAQ routes it to your bank against the UMN.

If your string is not on this page

There are hundreds of NPCI response codes and only a handful ever reach an investor, so a string that is not here is more likely to be your app's own phrasing than a code at all. Two questions get you past it every time. What is the rejection reason exactly as received from NPCI, which your broker holds. And what is the status against this UMN, which your bank holds. Those two answers are specific enough to act on. A sentence on a screen usually is not.

Write the UMN down the moment a mandate appears. Almost every case that drags on in this area turns out to be one where nobody could identify which mandate was being discussed.