IPO Allotment Engine

When a company decides to go public through an Initial Public Offering (IPO) in the Indian capital markets, it needs a neutral, regulated intermediary to manage the transaction. This intermediary is the Registrar and Transfer Agent (RTA).

This system was engineered for Niche Technologies Pvt. Ltd. (via JRat’s Studio), a SEBI-registered Category I RTA with over three decades of experience in India’s securities market, to modernize their core public issues processing infrastructure.

The RTA serves as the vital bridge connecting multiple key financial players:

The Engineering Problem

During an IPO bidding window, RTAs face massive spikes where millions of bids arrive on the evening of the bidding close. With India's shift towards a strict T+3 listing timeline, the RTA has an extremely narrow window (typically overnight) to ingest, validate format structure, deduplicate duplicate PAN bids, perform three-way payment reconciliations, and execute the Basis of Allotment (BOA).

Because any financial allocation error, share mismatch, or delayed bank release triggers immediate regulatory penalties and audits, there is zero error tolerance.

Regulatory Constraints

• ASBA (Applications Supported by Blocked Amount): Bidders funds are blocked at SCSBs or NPCI. Post-allotment, the platform triggers debit signals for successful lots and release signals for unallotted funds.
• Third-Party Payment Ban: Enforces that the PAN on the Demat account matches the bank account owner PAN blocking the funds.
• Basis of Allotment: Mandates mathematical equity where over-subscribed portions are allotted via seeded, audit-compliant lotteries.

The platform adopts a hybrid design: a containerized, event-driven batch processing pipeline (Data Plane) handles heavy calculations and file transformations, while a low-latency microservice (Control Plane) manages configurations, overrides, and administrative stage sign-offs.

The Ingest & Processing Pipeline Flow

Every business day during an active IPO, the batch execution executes sequentially:

1. Trigger & Dispatch: A cron-based orchestration system fires daily at set timeframes (interim and final close), querying active IPO statuses and invoking the compute pipeline.
2. SFTP Connector Ingest: Secure file-transfer connectors log into exchange SFTP directories using secure keys, download CSV bid files, and transfer them to raw storage.
3. Validation Batch Processing: Containerized compute tasks execute parsing, verify PAN/Demat structures, and run multi-way in-memory joins against Bank confirmations and UPI Mandate logs.
4. Lottery & Exchange Handover: The allotment engine performs category adjustments, resolves over-subscription lotteries, verifies math checksums, and dispatches acknowledgment files back to exchange SFTP directories.

The Administrative Control Path

To manage configurations or execute manual overrides, administrative staff authenticate via the Admin Portal utilizing Multi-Factor Authentication. Requests hit the secure API Gateway, which validates JWT claims before forwarding traffic to the containerized backend.

The backend control plane service is written in Go to maximize concurrency and ensure low memory footprint. By adopting Clean Architecture patterns, database, HTTP routing, and core domain logics remain decoupled:

• API Presentation Layer handles HTTP routing, JSON serialization, and request binding.
• Middleware Interceptors validate JSON Web Tokens, evaluate user roles (Admin vs. Standard Operator), and capture before/after snapshots for audits.
• Business Service Layer handles allotment state gates, parameter updates, and coordinates multi-table mutations inside single database transactions.
• Repository Layer executes raw parameterized SQL statements directly to connection pools, avoiding the overhead of heavy Object-Relational Mappers (ORMs).

Transactional Safety

Multi-row database operations execute within explicit transaction boundaries. If a write fails or audit-trail logging encounters an error, database transactions roll back automatically to maintain state consistency.

The computing engine uses Polars (compiled with Rust on Apache Arrow memory layouts) to achieve vectorization. Parallel hashing and joins process millions of files in seconds, bypassing Python's Global Interpreter Lock (GIL).

Linear-Time Format Checks

Standard regular expression engines risk CPU execution halts if input files contains maliciously crafted strings (Regular Expression Denial of Service, or ReDoS). We mitigate this by using Google-RE2, which guarantees linear-time $O(N)$ execution bounds during heavy application surges.

Deduplication & Multiplicity Audits

Window functions partition bids over Permanent Account Number (PAN) profiles. If an investor submits bids under restricted categories (such as Retail or Employees) across multiple applications or broker accounts, the engine group-wise flags all associated bids for rejection to enforce SEBI mandates.

Deterministic Basis of Allotment Solver

To prevent pseudo-random seed manipulation, the solver reverses application ID digits to shuffle rows uniformly before sorting. Cycle indices match pre-configured magic numbers to distribute shares cyclically, ensuring absolute lottery reproducibility during tiebreaker draws.

The relational database layer runs on Amazon Aurora PostgreSQL. The schema uses SQL-first migration scripts versioned chronologically.

Index Lock Mitigation

Standard indexing operations on large tables block database writes. In production environments, we require all migration index creation scripts to execute concurrently with strict statement timeouts, preventing database locks during high-volume intake periods.

Storage Optimizations

• Custom Enum Types: Fields like category flags or classification rules store enums (occupying only 4 bytes), reducing disk/RAM sizing footprint by gigabytes compared to raw string columns across millions of transaction rows.
• JSONB Audit Archiving: Audit events log mutations into structured binary `jsonb` fields, allowing fast indexing and key lookup operations.

Provisioned via OpenTofu / Terraform, the cloud topography isolates the primary database cluster, backend services, and execution tasks inside secure private subnets. All outbound calls route through isolated NAT Gateways with static Elastic IPs allowlisted by external exchange APIs.

Cognito User Sync Lambda Flow

To prevent credential synchronization discrepancies, user provisioning triggers a sync task to register user records inside the relational database, resolving DB connection details dynamically from Secrets Manager using secure KMS keys.

Batch Orchestration

A workflow state machine coordinates the lifecycle: triggering exchange ingestion connectors, running parallel batch verification tasks, evaluating ingestion statuses, and executing the Basis of Allotment scripts.