Skip to content

Batch Pipeline

When a customer finishes their KYC (Know Your Customer) onboarding journey and a checker gives final approval, the real back-office machinery kicks in. Think of the batch pipeline as a factory assembly line — raw KYC applications come in at one end, and fully registered trading accounts come out the other. Multiple government agencies, stock exchanges, and depositories each need to receive, validate, and approve the same customer data before that customer can place their first trade. This page walks you through every step of that assembly line, the intermediate statuses your operations team will monitor, and the SLA (Service Level Agreement) targets you should expect at each stage.

The first thing to understand about the batch pipeline is that it does not run in a single sequence. Instead, submissions to seven different agencies fire in parallel the moment the checker clicks “Approve.” Each agency has its own internal sequence of steps, but from our system’s perspective they all start at the same time. This parallel design is critical — if we ran them one after another, a single customer’s activation could take weeks instead of hours.

Checker Approved
├─→ [KRA Pipeline] Submit → Under Process → Registered → Validated (2-3 days)
├─→ [CKYC Pipeline] Upload → Queued → Validated → KIN Generated (4-5 days)
├─→ [NSE Pipeline] UCC Submit → PAN Verify → "A" Approved → Trading Active (same day)
├─→ [BSE Pipeline] UCC Submit → 3-Param PAN Verify → Approved → Segments Live (same day)
├─→ [MCX Pipeline] UCC Submit → Income Verify → Approved (next working day, if commodity)
├─→ [CDSL Pipeline] BO File (Lines 01,02,05,07) → KYC Check → Bank Valid → Active (1-2 hrs)
├─→ [NSDL Pipeline] UDiFF Submit → CDS Process → DPM Update → PAN Flag → Active (~15 days)
└─→ [Income Pipeline] Perfios/AA verify → Confirmed (1-2 hrs, if F&O)
Final Gate: KRA Registered + BO Active + UCC Approved → ACTIVE (can trade)

In plain English: seven different submissions happen simultaneously. The customer cannot trade until at least three of them — KRA (KYC Registration Agency), a depository (for their demat account), and an exchange (for their trading code) — have all reached an approved or active state.

Now let us look at each pipeline in detail, starting with the two regulatory registrations (KRA and CKYC) and then moving to the exchanges and depositories.

The KRA pipeline is the regulatory backbone of the entire process. Every new customer’s identity details must be submitted to a KRA, which cross-checks their PAN (Permanent Account Number), name, and date of birth against official databases. Until the KRA marks the record as at least “Registered,” the customer is not legally permitted to trade on any exchange.

StepActionVendorInput/OutputStatusSLA
1Submit KRA recordDigio API (Application Programming Interface) / CVL SOAP / bulk TXTFull KYC payload → App ref numberSUBMITTEDImmediate
2KRA receives and validatesKRA (CVL/NDML)Cross-checks PAN format, name, DOBUNDER_PROCESS1-2 working days
3Identity cross-checksKRAPAN-Aadhaar link, name consistencyREGISTEREDSame batch cycle
4Email + mobile validationKRASends validation link to clientVALIDATED+1 working day

In plain English: your customer can start trading as soon as the KRA marks them “Registered” — they do not need to wait for the validation email step to complete.

With the KRA submission underway, the system simultaneously pushes the same customer’s data to CKYC (Central KYC) for a separate, centralized identity record.

CKYC is the centralized identity repository maintained by CERSAI (Central Registry of Securitisation Asset Reconstruction and Security Interest of India). While the KRA pipeline handles the securities-market-specific KYC record, the CKYC pipeline creates a universal identity record that any financial institution in India can later retrieve. SEBI (Securities and Exchange Board of India) mandates dual upload — both KRA and CKYC — since August 2024.

StepActionVendorInput/OutputStatusSLA
1Submit JSON payloadDecentro APIPhoto, POA, contact, IDs → AcknowledgementUPLOADEDImmediate
2CERSAI queues for processingCERSAIRecord enters validation queueQUEUED1-2 working days
3Document OCR and verificationCERSAIAuto-verification of submitted documentsVALIDATED+1-2 working days
4KIN generatedCERSAI14-digit CKYC Identification Number → SMS/emailKIN_GENERATED+1 working day

In plain English: the CKYC pipeline runs slower than most others (4-5 working days), but it does not block trading. It is a compliance obligation that runs in the background.

Now let us turn to the exchange pipelines — these determine when the customer actually gets a trading code.

The NSE (National Stock Exchange) pipeline creates the customer’s UCC (Unique Client Code) — the identifier that ties every trade they place on NSE back to their identity. NSE is typically the fastest exchange to activate, with same-day turnaround if you submit before the 5 PM cutoff.

StepActionFormatInput/OutputStatusSLA
1Submit UCCAPI (REST JSON) or batch (pipe-delimited, max 10K)client_name, PAN, DOB, segments → ackSUBMITTEDImmediate
2PAN + Name + DOB verificationNSE via Protean3-param check against ITD”A” (Approved) or “I” (Invalid)Same batch cycle
3Activation confirmationResponse batch file or API callbackUCC code + segment flags → trading permittedACTIVESame day (5PM cutoff)

In plain English: submit the customer’s details before 5 PM, and they will have an active NSE trading code by end of day.

The BSE (Bombay Stock Exchange) pipeline runs alongside NSE with a very similar structure but its own verification system.

BSE has a slightly different verification approach — it uses a strict 3-parameter PAN verification where the customer’s PAN, name, and date of birth must all match against the Income Tax Department’s records via Protean. BSE also supports larger batch sizes (up to 30,000 records) and a separate segment activation batch (up to 50,000 records).

StepActionFormatInput/OutputStatusSLA
1Submit UCCETI/API (fixed-length, max 30K)Client master dataSUBMITTEDImmediate
23-parameter PAN verificationBSE via ProteanPAN + Name + DOB must all verifyVERIFIEDSame batch cycle
3UCC approved + segment activationSegment activation batch (max 50K)Segments liveACTIVESame day

The MCX (Multi Commodity Exchange) pipeline is only relevant for customers who want to trade commodities, but it has an important additional requirement.

MCX requires income proof for all commodity traders — this is an additional hurdle that equity-only customers do not face. Every MCX client must also be categorized as a Hedger (HE), Speculator (SP), or Arbitrageur (AR), which affects their margin requirements and position limits.

StepActionFormatInput/OutputStatusSLA
1Submit UCCMCX CONNECT / CTCL APIFull KYC + income proof + client category (HE/SP/AR)SUBMITTEDImmediate
2Income verificationMCXIncome proof validated for commodityVERIFIEDSame day
3ApprovalMCXUCC approved for commodity tradingACTIVENext working day

With exchange registrations covered, let us move to the depository pipelines. These create the customer’s demat account — the electronic account where their shares and securities are actually held.

CDSL (Central Depository Services Limited) is the depository promoted by BSE and is where the majority of retail investors hold their demat accounts. The “BO” in “BO account” stands for Beneficial Owner — the person who actually owns the securities. CDSL uses a fixed-length positional file format with numbered “lines” (01 through 07), where each line carries different categories of customer data.

StepActionFormatInput/OutputStatusSLA
1Submit BO fileFixed-length positional (Lines 01,02,05,07)DP ID + holder + contact + bank + nominationSUBMITTEDImmediate
2BO record creation + KYC checkCDASCross-check KYC status, PAN validityCREATEDMinutes (API)
3Bank account validationCDAS (Line 05)Dividend/interest bank account verifiedBANK_VALIDMinutes (API)
4Nomination acceptanceCDAS (Line 07)Nominee details recorded or opt-out flaggedNOM_ACCEPTEDMinutes (API)
5CDAS activationCDAS16-digit BO ID active; optional DDPI (24h)ACTIVE1-2 hours (API)

In plain English: CDSL via API is remarkably fast — a new demat account can go from submission to active in under two hours. The 16-digit BO ID (8-digit DP ID + 8-digit Client ID) is what uniquely identifies this customer’s holdings.

NSDL (National Securities Depository Limited) is the other depository, and its pipeline is notably slower.

NSDL, promoted by NSE, uses a different file format called UDiFF (Unified Distilled File Formats) with ISO-tagged fields (adopted since March 2024). The most important thing to know about NSDL is that the PAN flag enablement step — the final gate before trading is actually permitted — can take 5-7 working days on its own. This makes the total NSDL pipeline roughly 15 working days, significantly longer than CDSL.

StepActionFormatInput/OutputStatusSLA
1Submit via Insta InterfaceUDiFF format (ISO-tagged, since Mar 2024)Full KYC recordSUBMITTEDImmediate
2CDS processingCDSAccount ID + BO ID (“IN” + 14 chars)PROCESSING3-5 working days
3”Out file” sent back to DPMDPM (Depository Participant Module)Client_IDs returned in response fileDPM_UPDATED+2-3 working days
4Back-office client master createdInternalTrading + margin limits set in ODINCLIENT_CREATED+1 working day
5PAN flag enablementDPMPAN flag enabled → trading enabledACTIVE+5-7 working days

The final pipeline in our parallel set is the Income Pipeline, which only applies to customers who want to trade in derivatives.

If the customer has requested F&O (Futures and Options) or commodity segments, their declared income must be independently verified before those segments can be activated. This is a SEBI requirement to ensure that customers trading in leveraged instruments have adequate financial capacity.

StepActionVendorInput/OutputStatusSLA
1Verify incomePerfios ITR / Setu AA (Account Aggregator)ITR/bank statement → verified incomeVERIFIED1-2 hours

In plain English: the system fetches the customer’s income data — either by parsing their ITR (Income Tax Return) via Perfios or by pulling bank statements through the Account Aggregator framework — and confirms it aligns with their declared income range.

Once the critical pipelines have completed and the customer’s account is active, several follow-up jobs run to finalize the onboarding experience. These are not blocking — the customer can already trade — but they are necessary for full compliance and a complete customer setup.

JobVendorOutputSLA
Segment ActivationNSE/BSE/MCXSegments liveSame day
Back-Office Sync63 Moons ODINClient master recordImmediate
Welcome KitKaleyra + AWS SESEmail + SMSOn activation
Nominee Video (if opt-out)HyperVergeVideo declarationWithin 30 days
DDPI Setup (if opted)CDSL/NSDLDDPI registered1 day

With all the parallel pipelines running, the system continuously monitors statuses and checks whether the three mandatory conditions for trading have been met. Until all three are satisfied, the customer’s account remains in a “pending activation” state.

All three conditions must be met for the client to trade:

ConditionSourceRequired Status
KRA RegisteredKRA (any of 5)REGISTERED or VALIDATED
BO Account ActiveCDSL and/or NSDLACTIVE
UCC ApprovedNSE and/or BSEACTIVE

In plain English: the customer needs three green lights — their identity must be registered with a KRA, they must have an active demat account at a depository, and they must have an approved trading code at an exchange. Only when all three are in place does the system flip their status to ACTIVE, and they can place their first trade.