Reaching the IPO, allotment and NEPSE data IPO Bulk Apply pulls together

Three separate Nepali capital-market backends sit behind this one app. IPO applications and allotment run through MeroShare, the depository portal operated by CDS and Clearing Limited (CDSC). Demat holdings sit in the central depository. Index, floorsheet and depth come off the Nepal Stock Exchange front end, and live order entry belongs to a broker's Trade Management System. The app's job is to put all of that under a single login and a bulk-apply button. The integration job is the reverse: pull those flows back out as a clean, queryable interface a third party can run.

The bottom line for an integrator: the valuable, hard-to-get data here is per-investor and lives behind MeroShare — bulk IPO submissions, allotment outcomes, blocked-amount state, and Demat holdings. The market data (index, gainers and losers, floorsheet, depth) is comparatively open but served behind a rotating token handshake on the NEPSE front end. We treat the two differently, and recommend running the per-investor flows on the user's own consented MeroShare credentials while pulling the market layer through protocol analysis of the same endpoints the app already calls.

The data sitting behind the login

Mapped to where each domain actually originates, not a generic feature list:

The routes that apply here

Investor-consented credential access to MeroShare / CDSC

The per-investor flows — apply, re-apply, allotment, Demat holdings — open with the investor's own DP code, BO ID and password, which they already use daily. With their consent captured and held, the build authenticates as that user and exercises the same ASBA endpoints the official client uses. This is the cleanest path for the data that matters, because the credential and the consent both belong to the end user; we handle the consent capture, token issuance and refresh as part of the work.

Authorized protocol analysis of the app's traffic

Watching how the app talks to MeroShare, the NEPSE site and the TMS host gives the request and response shapes, the auth handshake and the token rotation on the market endpoints. Effort is moderate; durability is tied to how often those front ends change. We add a guard that re-checks the token handshake and payload shape on each run so a portal change surfaces as a clear failure rather than silent bad data.

On-screen extraction as a backstop

Where a surface has no clean call — some corporate-action and broker-ranking views are rendered, not served as data — a structured read of the rendered MeroShare or app screen under the user's own session fills the gap. Lowest durability, used only where the first two routes do not reach.

For a typical build we run the per-investor IPO and portfolio data on route one and the NEPSE market layer on route two, joined into one schema. The credential path carries the data a buyer is actually paying for; the protocol path keeps the market feeds cheap to refresh.

Who regulates this, and the consent that matters

Nepal's securities market is regulated by the Securities Board of Nepal (SEBON) under the Securities Act, 2006; SEBON licenses the depository company, depository participants and brokers (per SEBON's published mandate). There is no account-information or open-banking data-sharing scheme for securities in Nepal, so this is not a regulated AIS integration — access rests on the investor's own consented credentials with SEBON-licensed entities (CDSC for MeroShare and the depository, NEPSE for the TMS).

Personal-data handling falls under the Individual Privacy Act, 2018, which came into force in September 2018 (per Nepali legal commentary). It is consent-based and purpose-limited, with rights of access, rectification and erasure, and no dedicated data-protection regulator. We operate to that posture: access is authorized and consented, consent and access are logged, data is minimized to the domains the client asked for, and an NDA is in place where the engagement needs one. Compliance here is how we work, not a gate the client clears first.

What lands in your repo

For this app, the deliverable set is concrete:

• An OpenAPI specification covering the MeroShare auth, IPO-apply, allotment-status and Demat-holding operations, plus the NEPSE market read endpoints.
• A protocol and auth-flow report: the MeroShare login and JWT-style token chain, token refresh, and the rotating handshake on the NEPSE market endpoints.
• Runnable source for the key surfaces in Python and Node.js — bulk apply across multiple BO IDs, allotment polling, holdings pull, index/floorsheet fetch.
• Automated tests, including the allotment lifecycle (applied → blocked → allotted / not allotted → released) so regressions in result parsing are caught.
• Interface documentation and data-retention guidance written against the Individual Privacy Act consent model.

The MeroShare call, in outline

Endpoint paths and field names below are illustrative of the MeroShare ASBA flow as the public web client exercises it; exact paths and payloads are confirmed during the build against a consenting account.

# 1. Authenticate (DP code + BO ID + password are the investor's own)
POST /api/meroShare/auth/
  { "clientId": <dp_code>, "username": "<boid>", "password": "***" }
  -> 200, response header: Authorization: <bearer token>

# 2. List open issues for this BO ID
GET  /api/meroShare/companyShare/applicableIssue/
  Authorization: <token>
  -> [ { "companyShareId": ..., "scrip": "ABC",
         "issueOpenDate": "...", "issueCloseDate": "..." } ]

# 3. Submit the application (one per BO ID; DP + ASBA bank vary per account)
POST /api/meroShare/applicantForm/share/apply/
  { "demat": "130100...", "boid": "...", "appliedKitta": "10",
    "accountNumber": "...", "customerId": <asba_branch>,
    "bankId": <asba_bank> }
  -> { "status": "CREATED", "applicationId": ... }

# 4. Poll the lifecycle, not just the submit
GET  /api/meroShare/applicantForm/report/detail/<applicationId>
  -> { "statusName": "ALLOTTED" | "NOT_ALLOTTED" | "BLOCKED",
       "blockAmount": ..., "allottedKitta": ... }

# Error handling: token expiry -> re-auth; duplicate apply -> 4xx with
# a reason string the client surfaces per BO ID rather than aborting the batch.
      

What this particular build has to get right

These are the things we account for and handle, not hurdles put in front of the client:

• Per-account DP and bank binding. Each BO ID sits under a different Depository Participant with its own DP code and a chosen ASBA bank. We model that binding per account so a bulk run files every application against the correct DP and ASBA account, instead of assuming one profile across the batch.
• Block, not debit, then lottery. MeroShare blocks the application amount rather than debiting it, and allotment is a lottery resolved after the issue closes — one entry per applicant regardless of units (per public MeroShare application guides). We design the result sync around those status transitions so the client reports the true outcome and the released amount, not just a successful submit.
• Two-layer data sources. The market endpoints sit behind a token handshake on the NEPSE front end and the payload changes intraday across pre-open, continuous and close. The build re-checks the handshake and shape on each run, so a front-end change is caught early and the client refreshed under maintenance.
• Broker-specific TMS host. The TMS portal host depends on the broker number, so the broker host is a parameter rather than a constant and a portfolio or floorsheet pull works whichever broker the investor trades through.

Where teams use this

• A wealth or advisory firm running bulk IPO submissions for many clients' BO IDs from one operations console, with allotment reconciled automatically.
• A portfolio product syncing Demat holdings and dividend events into its own ledger overnight.
• A market-data or research tool ingesting NEPSE floorsheet and depth on a schedule for analytics and alerts.
• An internal back office matching allotment outcomes against blocked-amount releases for cash forecasting.

What the app's screens show

Listing screenshots, used here to read the surfaces an integration would map. Tap to enlarge.

The rest of the NEPSE app shelf

Other apps Nepali investors run alongside this one. Neutral context — several of these touch the same backends, which is why a unified integration is worth doing.

• Share Hub — portfolio tracking, watchlists and IPO/FPO alerts over live NEPSE data.
• ShareSansar — NEPSE index, per-scrip data, dividends and historical prices with portfolio tools.
• Mero Lagani — widely used portfolio app with IPO and AGM push notifications and analysis tools.
• MeroShare — CDSC's own depository portal: the source of record for IPO apply, allotment and Demat holdings.
• npstocks — NEPSE analytics platform aimed at active traders.
• Nepalytix — research and data platform covering NEPSE settlement and trading.
• Bulk IPO Apply - NEPSE (by C&N Infotech) — a separate app in the same bulk-apply niche.
• NEPSE TMS broker portals — broker-hosted trade management systems for live order entry.

Questions integrators ask about this one

Can one bulk run cover BO IDs that sit under different Depository Participants?

Yes. Each BO ID belongs to a Depository Participant with its own DP code and a chosen ASBA bank, so the build models the DP and bank binding per account rather than assuming one profile. A bulk submission then files each application against the correct DP and ASBA account.

Does the allotment result come back as more than just submitted or failed?

It can. MeroShare moves an application through a lifecycle — applied, amount blocked, then allotted or not allotted with the blocked amount released. The result sync is built around those My Application status transitions so a poller reports the real outcome, not only that the form was accepted.

Is the NEPSE market data sourced from the same place as the IPO data?

No. IPO application and allotment data come from MeroShare and CDSC, Demat holdings from the depository, and index, floorsheet and depth from the NEPSE front end, while broker context comes from the TMS portal. The integration stitches these distinct backends into one normalized model.

Is there a Nepali open-banking scheme we plug into for this app?

There is no account-information or open-banking regime for securities in Nepal. The securities market is regulated by the Securities Board of Nepal under the Securities Act, 2006, with CDSC and NEPSE as licensed entities. Access is therefore on the investor's own consented MeroShare and TMS credentials, handled under the Individual Privacy Act, 2018.

Sources and who checked them

Checked in May 2026 against the MeroShare ASBA flow, the CDSC issue listing, NEPSE market surfaces and the regulatory and privacy framework for Nepal's securities market. Primary references opened for this brief:

• CDSC — issue / IPO listing
• Securities Board of Nepal — mandate and licensing
• Individual Privacy Act, 2018 (2075) — commentary
• MeroShare ASBA / C-ASBA application walkthrough

Compiled by the OpenBanking Studio integration desk · May 2026.

Source-code delivery for this app starts at $300: you get the runnable bulk-apply and market client, the OpenAPI spec, the protocol report and the tests, and you pay only after delivery once it runs on your side. If you would rather not host anything, the same coverage is available as an endpoint you call and pay per request, with nothing upfront. A build like this runs one to two weeks. Send the app name and what you need from its data through our contact page — access to a consenting account and any compliance paperwork are arranged with you from there, not asked of you up front.