Author: Jayakrishnan M

CDSCO SaMD Guidance: 2026 Critical Hospital IoT Compliance Risks

Posted on by Jayakrishnan M
CDSCO SaMD Guidance

CDSCO SaMD Guidance is changing how Indian hospitals and MedTech companies need to approach connected medical software.

In October 2025, CDSCO released its draft Guidance Document on Medical Device Software the first time India’s drug regulator formally classified standalone software as a medical device. The category is Software as a Medical Device (SaMD). If your hospital runs a connected infusion pump with a cloud alert backend, a remote patient monitoring platform for post-discharge cardiac patients, or a clinical decision support system that recommends medication dosing, each of those is now a Class A, B, or C medical device under the new classification. The software team that built it may not know that yet.

For a 200-bed tertiary care hospital network in Kerala we work with, the news arrived not through a regulatory update but through a vendor audit. A diagnostic equipment supplier asked for documentation of the hospital’s SaMD risk classification before renewing a service contract for their ECG analysis system. The hospital’s IT team had no framework to answer the question. The clinical device software had been treated as a procurement item, not a regulated product, for its entire five-year deployment.

This post covers what CDSCO’s SaMD classification actually requires, what compliant IoT architecture looks like in a hospital or MedTech context, and a readiness scoring tool your engineering team can use to assess the gap.

CDSCO SaMD Guidance: What It Actually Classifies

SaMD is standalone software not firmware embedded in hardware that performs a medical function independently. The draft guidance covers diagnostic apps, AI-based imaging analysis tools, remote patient monitoring platforms, clinical decision support systems, and continuous glucose monitoring (CGM) software backends.

The risk classification uses three criteria:

1. The medical purpose of the software (informing, diagnosing, treating, or preventing a condition)

2. The significance of the information it provides for clinical decision-making (informing clinical management vs. driving it directly)

3. The severity of the associated clinical condition (non-serious, serious, critical)

A remote monitoring platform that alerts clinicians to deteriorating post-surgical vitals is Class B at minimum. A CGM backend that recommends insulin dose adjustments is Class C. A symptom checker that generates a triage recommendation is Class A. The classification drives the documentation requirements, and the documentation requirements drive the architecture decisions because documentation that cannot be traced to the actual system behavior is not compliant documentation.

The Architecture Problem Hidden Inside the Regulatory Language

CDSCO’s draft introduces two requirements that most Indian MedTech engineering teams have not accounted for in their architecture.

The first is the Device Master Record (DMR) for software. The DMR must document software architecture, data flows, version history, intended use environment, and known anomalies at each version. In practice, this means your connected device backend needs a documented architecture that matches the deployed system not the architecture diagram from the original design sprint that diverged from the codebase two years ago.

The second, and more expensive, requirement is the Algorithm Change Protocol (ACP) for AI and ML components. If your SaMD includes a model that learns or updates post-deployment a deterioration risk classifier, a fall detection model, a CGM calibration algorithm the ACP must describe how the model can change, what triggers revalidation, and what clinical performance thresholds must hold at each version. The ACP must be reviewed and approved before any model update is deployed to production.

This is not a documentation checkbox. It is an architectural constraint on your MLOps pipeline. You cannot use a standard continuous delivery model for AI components in a Class B or Class C SaMD without building the ACP gate into your deployment workflow. Most MLOps pipelines built for enterprise software do not have this gate.

Clinical IoT Compliance Readiness Score (CICRS)

The CICRS provides a five-dimension snapshot of where your connected device stack stands against CDSCO’s SaMD draft. Each dimension scores from 1 (not addressed) to 4 (documented and verified).

Dimension 1: Software Classification Accuracy. Have you formally classified each software component against the three-criteria CDSCO risk model? Score 4 if you have a written classification rationale for each SaMD component reviewed by both clinical and engineering stakeholders. Score 1 if your regulatory team has not been involved in the classification exercise.

Dimension 2: Device Master Record Fidelity. Does your DMR reflect the deployed system? Score 4 if your DMR is generated from version-controlled source documentation and updated with each release. Score 1 if the DMR was written at project inception and has not been updated since.

Dimension 3: Algorithm Change Protocol Coverage. For each AI or ML component, do you have an ACP with defined revalidation triggers and performance thresholds? Score 4 if the ACP is integrated into your deployment pipeline as a mandatory pre-release gate. Score 1 if your ML models are deployed to production through a standard CI/CD workflow with no clinical performance check.

Dimension 4: IEC 62304 Lifecycle Alignment. IEC 62304 defines software development lifecycle requirements for medical device software. Score 4 if your software development process is formally aligned with IEC 62304 safety class B or C as applicable. Score 1 if your development process has not been assessed against IEC 62304.

Dimension 5: ABDM Integration Security. If your SaMD interacts with ABDM-linked health records, does the integration meet ABDM’s Health Data Management Policy requirements for access control and audit logging? Score 4 if you have an audit log for every data access event with patient consent traceability. Score 1 if ABDM integration was added as a feature without a security architecture review.

The Algorithm Change Protocol is the most expensive requirement most Indian MedTech teams have never budgeted for.**

A total CICRS score of 14 or above suggests a team ready for formal compliance engagement. Below 10, the architecture requires significant modification before documentation work will produce honest results.

Three Architecture Decisions That Determine Your Compliance Path

Version your device configuration alongside your software.A connected infusion pump running firmware version 3.2 on a backend running application version 4.1 is a different device configuration than the same pump on backend version 4.0. Your DMR must track this combination. Most IoT device management platforms do not correlate firmware versions with backend versions in a way that supports DMR documentation. Build that correlation into your device registry design from the start.

For the hospital network in Kerala, the most consequential finding was in the audit log architecture. Their connected monitoring devices wrote events to an application database, not to an immutable event stream. When a dosing alert was logged at 2:14 AM but the nurse acknowledgment was logged at 2:19 AM, there was no way to prove the five-minute gap did not reflect an application error rather than a clinical workflow. That is not a documentation problem. It is an architecture problem that the documentation was revealing.

What This Means for Healthcare Leaders

If you lead technology at a hospital, diagnostic chain, or MedTech company in India, here is what to do in the next 30 days without engaging a consultant:

Inventory your connected device software.List every software component that touches patient-generated data or clinical decision workflows. For each, ask: does this meet the SaMD definition? Most teams will find three to five unclassified SaMDs in a 200-bed hospital.

Get your IEC 62304 safety class assessed for each classified SaMD. Safety class B and C carry substantially different documentation requirements. Knowing your class now prevents expensive retroactive documentation work.

Bring your MLOps team into the regulatory conversation. If you have deployed any AI component that updates or retrains, the ACP requirement applies. Your MLOps engineer needs to understand the gate structure before the next model update ships.

Review your ABDM integration for audit completeness. CDSCO and ABDM requirements overlap significantly on audit logging. A single well-designed audit infrastructure satisfies both. Most existing integrations satisfy neither.

A connected infusion pump with a cloud backend is not an IoT project. It is a regulated software product with a device master record.

More Blogs: ABC Integration for Universities: How NEP 2020 Is Reshaping Academic Credit Systems

Essential Legal AI Audit Checks for Law Firms in India 2026

Posted on by Jayakrishnan M

A Legal AI Audit is becoming a critical requirement for Indian law firms deploying AI in production. In June 2026, India’s Supreme Court committee published the Draft Regulations for Use of Artificial Intelligence in Courts.

They are proposed operational requirements for every Indian law firm and LegalTech platform that has shipped AI into a production workflow in the past two years. The Rs 14,800 crore ($1.8 billion) Indian LegalTech market was built largely without MLOps governance. That is the problem these regulations are designed to fix. The firms that fix it first will not just be compliant they will be the ones clients trust with high-stakes matters.

What a Legal AI Audit Must Check Under Regulation 38

Regulation 38 (AI Audits) is the most technically demanding provision in the draft. It establishes that legal AI systems must be auditable against three criteria.

Acceptable error rates. The regulation does not specify a number, but it requires that the operator can produce one. A legal AI system with no error rate measurement in production has no defensible answer to this requirement.

Unbiased training data. This is a model lineage requirement. The system must be traceable to its training data, and that data must be documented for potential examination. A firm running a fine-tuned model on third-party data with no data card or provenance record cannot satisfy this.

Sufficient explainability. The AI’s output in any specific filing must be explainable. Not “the model generally produces accurate summaries” but “this paragraph in this pleading was generated with these inputs and these confidence indicators.”

None of these are achievable without MLOps infrastructure. A model deployed as a SaaS subscription with no production logging, no inference trace, and no error rate monitoring cannot be audited under Regulation 38. Most legal AI in production at Indian firms today fits that description.

Regulation 38 does not ask what your model does. It asks what your model does when it is wrong.

Working with a mid-tier law firm in Mumbai (120 attorneys, 8 practice groups, AI deployed for contract review and litigation research since late 2024), our team conducted a Legal AI Audit against the draft Regulation 38 criteria.

The firm was using a commercial legal AI platform through a subscription interface. The platform produced outputs. The firm had no way to retrieve the specific inference that produced any given document. No inference log. No model version recorded at time of output. No error rate computed against a validation set of known-correct legal summaries.

Disclosure compliance under Regulation 3 was also unaddressed. The firm had no workflow for flagging AI-assisted documents at the time of filing. Partners were making ad-hoc disclosure decisions based on personal judgment, not a documented policy.

The gap is not malicious. It is structural. Legal AI was adopted as a productivity tool, evaluated on features, not auditability. The Supreme Court draft regulations are the first external force requiring firms to retrofit governance onto existing deployments.

Most legal AI deployments in India were designed for the demo, not the audit. The Supreme Court’s draft regulations are going to make that visible.

The Legal AI Production Governance Framework (LAPGF) gives law firms and LegalTech platforms a structured path to Regulation 38 readiness. It has six components.

A Legal AI Audit using this framework should establish whether every production AI output can be traced, evaluated, and explained.

1. Model registry. Every AI model in production is registered with its version, training data summary, fine-tuning details if applicable, and deployment date. When a model is updated, the registry records the change and preserves the prior version for retrospective audit queries.

2. Inference logging. Every inference every document drafted, research query answered, or contract clause flagged is logged with a unique identifier, input hash, model version, timestamp, and output. Logs are retained for a minimum of 7 years to match legal matter lifecycle requirements.

3. Error rate monitoring. A sample validation set of known-correct legal outputs is maintained per practice group. The production model is evaluated against this set on a weekly basis. Error rate trends are tracked. A threshold of 3 percent degradation from baseline triggers a model review before the firm continues using the output in filed documents.

4. Explainability interface. For each filed document containing AI-assisted content, a human-readable inference record is retrievable: what inputs the AI received, what version of the model produced the output, and what sections were AI-generated versus human-edited. This record is the evidence produced in response to a Regulation 38 audit.

5. Disclosure workflow. A structured checklist in the matter management system prompts the responsible attorney to declare AI use at document creation and again at filing. The disclosure record is linked to the inference log for that document.

6. Bias monitoring. Training data provenance documentation is maintained per model. For custom fine-tuned models, a bias evaluation report against Indian legal corpus diversity (case law from multiple High Courts, judgment language distributions) is produced at each model version change.

Harvey AI’s ISO 42001 Approach and What India Requires Beyond It

Harvey AI, now serving over 200 of the Global 2000 firms, announced ISO 42001 certification for AI governance. ISO 42001 is the international standard for AI management systems. It establishes governance processes at the organizational level: policy, risk assessment, oversight structures.

Regulation 38 goes further than ISO 42001 in one critical respect: it is matter-specific and inference-specific, not organizational. ISO 42001 can certify that a firm has an AI governance policy. Regulation 38 requires that the firm can produce an audit trail for a specific paragraph in a specific pleading filed on a specific date. The LAPGF bridges this gap by implementing inference-level traceability on top of organizational governance frameworks.

The implication for LegalTech vendors: ISO 42001 is now table stakes for selling to law firms in India. Inference-level audit trails are the next requirement. Platforms that do not build this into their product architecture in the next 12 months will face procurement rejection from larger firms operating under the regulations.

A legal AI model with no production monitoring is a negligence risk. In 2026, it is also a regulatory risk.

If you are a managing partner, CTO of a LegalTech platform, or head of IT at a law firm in India, three actions this week establish your position before the regulations are notified.

Inventory your AI tools against the LAPGF. For each tool, identify whether inference logs exist and are retrievable. If you cannot answer that question from your procurement documentation, the answer is no.

Establish a disclosure policy. Before the regulations are notified, draft and circulate a firm-wide policy on when AI use must be disclosed in filed documents, who is responsible for the disclosure decision, and how it is recorded.

Request audit documentation from your AI vendor. Ask them: “Can you produce an inference trace for any output generated by your platform in the last 12 months?” If the answer is no or requires a professional services engagement, add LAPGF-compliant logging as a procurement requirement for any renewal or replacement.

More Blog: https://codelynks.com/ais-230-api-standard/

AI Travel Agent Hallucinations: Fix Hotel Booking Errors

Posted on by Jayakrishnan M

Your AI Travel Agent Lies About Hotels. Here Is Why and How to Fix It.

An AI chatbot at a Canadian airline told a grieving customer that a bereavement fare existed. The fare did not exist. The airline honored it anyway, then went to court to argue the chatbot was a separate legal entity. The court disagreed. This is the trajectory for every OTA and travel platform deploying LLM-based agents without a verification architecture in place.

The problem is not that models hallucinate. The problem is that travel is a domain where the cost of a hallucination is a missed flight, a non-existent hotel reservation, or a refund dispute that erases the booking margin entirely. IDC named agentic AI the defining travel technology of 2026. What IDC did not explain is why most agentic travel systems fail between demo and production, and what it takes to ship one that does not.

Why Inventory Hallucination Is a Travel-Specific Problem

LLM hallucinations in most domains produce wrong answers. In travel, they produce bookings for inventory that does not exist. The failure mode is not a confabulated fact in a chat response. It is a confirmed reservation in a system of record for a flight seat that was sold to someone else 400 milliseconds ago, at a rate that expired, with a policy that changed.

This is a travel-specific problem because travel inventory is real-time priced (airline fares change every few seconds), held rather than reserved (hotel inventory is available until another hold releases or expires), policy-governed (cancellation terms and baggage fees are not static), and terminal (a booking error cannot be walked back after check-in).

A standard RAG architecture retrieves from a vector store of cached flight and hotel data, passes it to an LLM, and generates a conversational response. This works for planning: “Which airlines fly Delhi to Dubai on Fridays?” It fails for booking: “Book me the 10:40 IndiGo flight to Dubai next Friday for under Rs 18,000 in economy,” because the cached data is stale the moment it was written.

A human travel agent who guesses availability is fired. An AI that guesses availability is praised for its tone until a customer arrives at an airport.

The Sabre/MindTrip Architecture and What It Gets Right

In February 2026, Sabre, PayPal, and MindTrip announced what they described as the travel industry’s first end-to-end agentic booking pipeline. A traveler describes a trip in natural language. MindTrip queries Sabre’s Mosaic APIs, covering over 420 airlines and 2 million hotel properties. PayPal’s agentic commerce infrastructure handles payment. The entire search, book, and pay loop closes inside a single conversational interface, with a planned Q2 2026 launch.

The detail that matters is the middle step: querying Sabre’s Mosaic APIs live, at booking time, not from a vector store. The LLM generates the intent and the parameters. The actual inventory check happens against a live distribution system. The LLM does not guess availability. It asks for it.

This architecture separates two functions that most travel AI demos conflate: intent extraction (what the user wants) and inventory resolution (what is actually available right now). The LLM owns intent extraction. A live API owns inventory resolution. The failure mode most travel AI teams produce is asking the LLM to own both.

Working with a mid-size OTA processing 3 million bookings annually in Southeast Asia, our team rebuilt their agentic booking prototype after it hallucinated hotel rates at approximately 1 in 12 searches during load testing. The core issue was a single-pipeline architecture where the LLM produced a hotel recommendation, a price estimate, and a booking confirmation in one generation step, with no verification between the price estimate and the live inventory system.

The Travel Agent Verification Stack (TAVS)

The Travel Agent Verification Stack (TAVS) is a five-layer architecture that separates intent, retrieval, verification, commitment, and audit into distinct system boundaries. Each layer has a defined responsibility and a defined failure mode.

Layer 1: Intent extraction. The LLM receives the user’s natural language request and produces a structured intent object: origin, destination, date range, traveler count, budget, and preference signals. No inventory is queried at this layer. The LLM is not aware of current availability.

Layer 2: Inventory search. A live inventory adapter queries the GDS (Sabre, Amadeus, or direct supplier APIs) with the structured intent object. Results return as structured JSON, not as prose. The LLM does not see these results yet.

Layer 3: Verification and scoring. A deterministic scoring function, not an LLM, ranks inventory results against user preferences, applies policy filters (refundability, baggage, loyalty tier), and selects a candidate set for presentation. This layer is rule-based, testable, and auditable.

Layer 4: Conversational presentation. The LLM receives the verified, scored candidate set and generates the conversational response. It cannot invent prices or policies. It can only describe what the verification layer returned. The system prompt explicitly instructs the model to refuse to state any price or availability claim not present in the candidate set.

Layer 5: Commitment and audit. On user confirmation, the booking is placed via the live supplier API. The full conversation, intent object, inventory search results, scoring decision, and booking confirmation are written to an immutable audit log. Chargebacks and disputes are resolved against this log, not a conversational transcript.

The Retry Budget Problem

Most vendor demos never survive production because an agent running four exploratory searches per user turn burns through a 3 to 5 percent merchant margin inside a quarter. This is the production failure mode that demo architectures ignore: retry cost.

Agentic systems retry when they are uncertain. A travel agent with no retrieval budget will search for flights, receive stale results, search again, receive an error, try a hotel, receive a timeout, retry, and present a hallucinated option from memory. Each API call costs money. Some travel APIs charge per search. The TAVS addresses this with a retrieval budget at Layer 2: a maximum of two live searches per conversation turn, with progressive disclosure of results rather than exhaustive search before presenting options.

The contrarian position worth defending explicitly: bigger models make this worse. A more capable LLM generates more plausible-sounding hallucinated inventory when it cannot access live data. The fix is not a better model. It is a verification layer the model cannot bypass.

The gap between a travel AI demo and a travel AI product is a verification layer, not a better model.

What This Means for Travel and Hospitality Leaders

If you are building or evaluating an agentic travel product, three tests tell you whether it is production-ready or demo-ready:

Ask it to book a specific flight for tomorrow with a budget constraint. If it produces a confirmation without querying a live GDS, it is hallucinating. If it returns a graceful error and offers alternatives, the architecture has a verification layer.

Ask it to find a hotel in a city sold out due to a major event. If it still produces hotel options, they are fabricated. A production-ready system should acknowledge unavailability and offer date or location alternatives.

Ask what happens if the booking fails after the user confirms. If there is no answer, there is no commitment layer. A payment has no idempotency guarantee and the audit trail has a gap.

More Blog: Two Channels, Two API Contracts: Why Indian D2C Brands Need Headless Commerce Now

Powerful DISCOM Data Pipeline for 5 Crore Smart Meters

Posted on by Jayakrishnan M

5 Crore Smart Meters. Zero Real-Time Analytics. India’s DISCOM Data Problem.

India crossed 5 crore smart meter installations in December 2025, with 3.90 crore installed under the Revamped Distribution Sector Scheme. The headline target is 250 million meters by March 2028, across consumers, distribution transformers, and feeders. Every energy minister in every state has cited these numbers as proof that AT&C loss reduction targets are achievable. They are right about the target. They are wrong about what achieves it.

AT&C loss reduction is not a hardware problem. It never was. It is a data processing problem masquerading as an installation problem. And most DISCOMs cannot process the data they already have. This post describes the pipeline architecture that changes that, based on work with a distribution company managing 2 million consumers across three distribution circles in central India.

What Is Actually Happening With the Meter Data

A smart meter with a 15-minute interval reading generates 96 data points per day. At 5 crore installed meters, that is 4.8 billion data points per day. This is Advanced Metering Infrastructure data, flowing through the Head-End System into a Meter Data Management system, where it is supposed to enable load forecasting, tamper detection, outage localization, and AT&C loss calculation.

In practice, most DISCOM MDM deployments are batch systems. They process data once every 24 hours. The analytics dashboards show yesterday’s consumption. The tamper alerts fire after the billing cycle closes. The AT&C loss calculation happens monthly, by which point the energy theft that drove it has been running for three weeks.

A DISCOM that collects 15-minute interval data from 2 million meters and processes it in daily batches is flying a passenger jet using yesterday’s weather report. The data exists. The insight does not.

The problem is not the HES or the meters. It is the pipeline between them and the analytical layer. Most AMISP contracts specify meter installation, HES provision, and MDM software. They do not specify real-time streaming, event-driven alerting, or integration with the DISCOM’s load dispatch center. That gap is where the AT&C reduction targets go to die.

The Architecture Gap in Current AMISP Deployments

The AT&C loss target under RDSS is 12 to 15 percent for most DISCOMs, down from current averages of 20 to 25 percent. The pathway is: reduce energy theft (technical loss) and improve billing efficiency (commercial loss). Both pathways require knowing about the loss event within hours, not days.

Theft detection requires comparing feeder-level consumption (DT meter) with consumer-level consumption (individual smart meters) in near-real-time. If a distribution transformer serves 200 consumers and shows 1,000 kWh consumed, but the sum of consumer meters is 700 kWh, 300 kWh is unaccounted. That gap needs to close within hours, not a billing cycle.

Current MDM batch systems produce this comparison once a day. A real-time streaming architecture produces it continuously. The difference in AT&C reduction outcomes between the two approaches is not marginal. One client reduced identified theft cases by 340 percent in the first quarter after switching from batch to streaming, not because more theft was occurring, but because the alerts fired while the theft was still happening.

India is building the world’s largest AMI network. The meter data is being collected. It is not being used.

Building the DISCOM Data Intelligence Layers (DDIL)

The DISCOM Data Intelligence Layers (DDIL) model defines five pipeline layers that together convert raw AMI data into operational intelligence.

Layer 1: Edge ingestion. Raw meter readings from the HES arrive in a message queue (Apache Kafka or AWS Kinesis) within 5 minutes of the interval close. Each message carries a meter ID, interval timestamp, consumption reading, power quality flags, and tamper event codes. The queue is the single source of truth. Downstream consumers read from it without polling the HES.

Layer 2: Stream processing.Apache Flink or AWS Kinesis Data Analytics runs three concurrent jobs: feeder-consumer balance calculation, comparing DT meter readings with the sum of downstream consumer readings in real-time; tamper pattern detection, flagging meters with sudden consumption drops, bypass indicators, or reverse energy flow; and outage localization, inferring outage boundaries from the last-reported meter readings across the feeder topology. These jobs produce alerts, not reports.

Layer 3: MDM integration. The verified stream output writes to the MDM system via API for billing and regulatory records. The MDM is the system of record for billing. It is not the analytical engine. Separating these concerns is the most important architectural decision in any DISCOM data project.

Layer 4: Operational dashboards. Real-time AT&C dashboards for load dispatch centers show feeder-level balance, active tamper alerts, and outage events, updated every 5 minutes. Separate from the billing MDM views used by commercial teams.

Layer 5: Predictive analytics. Daily and weekly batch jobs, separate from the streaming pipeline, run load forecasting models, predictive maintenance scoring for distribution transformers, and outage probability maps. These consume from a time-series database (InfluxDB or TimescaleDB) rather than the streaming layer. They are deliberately not real-time to avoid feedback loops with the operational layer.

The GNA Energy Model and What to Learn From It

In March 2026, GNA Energy launched GNAi, a cloud-based power intelligence platform integrating smart meter, grid, and weather data. The architecture merges AMI streams with weather forecast APIs and ancillary market data to support demand forecasting and battery dispatch optimization. This is the advanced use case. The foundational use case — real-time AT&C loss detection — must come first.

The lesson from GNAi is that the analytical layer is modular once the pipeline is right. Once you have a streaming pipeline ingesting HES data into a message queue and processing it through Flink, adding a weather data feed, a grid stability score, or a renewable generation forecast is a new consumer on the same stream. The pipeline architecture unlocks the use case surface. A batch MDM does not.

Procurement and AMISP Contract Considerations

Most AMISP contracts do not include a streaming data pipeline, a time-series database, or a real-time operational dashboard. They include an HES, an MDM, and a billing integration. DISCOMs that want real-time analytics must either negotiate an extension to the AMISP scope or procure the streaming layer independently.

The independent procurement path is faster and gives the DISCOM more architectural control. The AMISP HES exposes an API (REST or MQTT depending on vendor). Building a streaming ingestion layer on top of that API is a standard engineering task. Time-series storage, stream processing, and the dashboard layer are all available as managed cloud services, with no dependency on the AMISP vendor’s roadmap.

The position worth defending: the RDSS billing efficiency targets cannot be met through smart meter installations alone. They require a real-time data pipeline that most DISCOMs have not budgeted for and cannot procure under current AMISP contracts. This is the conversation that needs to happen between DISCOM leadership and the Ministry before the 250 million meter target is reached.

What This Means for Energy and Utilities Leaders

If you are a DISCOM CTO or IT head evaluating your RDSS technology stack, three questions decide whether you will hit your AT&C loss targets:

Does your current MDM produce feeder-consumer balance reports in under 1 hour? If the answer is no, or “we process these in the monthly billing run,” you have a batch pipeline problem, not a meter problem.

Is your tamper detection alert latency measured in hours or days? Alerts that fire after a billing cycle closes recover nothing from the theft event. Alerts that fire within 4 hours allow field dispatch during the same shift.

Do you have a time-series database storing interval-level meter data independent of the billing MDM? If the MDM is your only storage, running retrospective analysis or training a load forecasting model requires extracting from a billing system not designed for time-series queries. That is a two-week data project every time you want a new metric.

More Blog: Two Channels, Two API Contracts: Why Indian D2C Brands Need Headless Commerce Now

Bharat-VISTAAR Cloud Infrastructure: Powerful 120M-Farmer Stack

Posted on by Jayakrishnan M

Bharat-VISTAAR is live. Is Your Cloud Infrastructure Ready for 120 Million Farmers?

On February 17, 2026, India’s Agriculture Minister launched Bharat-VISTAAR (Virtually Integrated System to Access Agricultural Resources) in Jaipur, pushing the Digital Agriculture Mission into active deployment. The platform serves 120 million farming households. It pulls from AgriStack’s three foundational registries, integrates ICAR crop advisory packages, delivers real-time mandi prices and weather data, and runs in 11 languages planned for rollout by Q3 2026. The engineering problem is not the app. It is the cloud infrastructure behind the 10.31 crore Farmer IDs, the state-level federated registries, and the data pipelines that must work in districts where connectivity disappears for hours at a time. State implementation teams are discovering this now. Most are discovering it the hard way.

The Federated Architecture Is Not Optional

AgriStack is not a centralized database with a state API wrapper. It is a federated Digital Public Infrastructure built on InDEA 2.0 and the Vistaar Protocol, where each state maintains its own Farmer Registry, Geo-Referenced Village Maps, and Crop Sown Registry, and the central Ministry connects to these via standardized APIs. This is a deliberate design choice rooted in data sovereignty. States own their farmer data. The center aggregates and enables.

A federated DPI is not a distributed monolith. The difference matters from the first line of architecture.

This architecture has direct cloud consequences. You cannot build a single-region AWS deployment at the central level and call it done. You need:

– State-level compute environments close to local data sources

– Bidirectional sync protocols tolerant of intermittent connectivity

– Separate IAM boundaries per state with central audit federation

– Data residency controls aligned to DPDP Act provisions for state government systems

The Vistaar Protocol defines how data is represented and shared across the stack. It does not define how it survives a cloud zone failure at the state level. That is your engineering responsibility.

Where State Cloud Deployments Are Failing

Working with a state-level AgriTech implementation partner in Madhya Pradesh, our team reviewed infrastructure across four districts targeting the Kharif 2026 Farmer ID registration push. Three failure patterns appeared in every district.

Synchronous API coupling to central registries. State systems were calling central AgriStack APIs synchronously during field registration sessions. When central API latency exceeded 3 seconds, field officers abandoned the session. The fix is an event-driven architecture with local write-ahead queues and eventual consistency to the central registry, not synchronous coupling.

No offline fallback for the Gram Panchayat layer. Bharat-VISTAAR is designed to run on basic mobile devices in low-connectivity environments. The cloud architecture backing it must support an offline-first mobile API gateway at the Gram Panchayat level. Most deployments we reviewed had no concept of edge caching or offline token issuance for field agents. State AgriStack registries that cannot survive a 6-hour connectivity window will miss the farmers they were built for.

Single managed Kubernetes clusters running registry, analytics, and AI workloads together. Farmer Registry workloads have predictable, high-volume read patterns. Bharat-VISTAAR’s multilingual AI advisory model runs on-demand inference with unpredictable burst. Running these on the same cluster without workload isolation means a crop advisory request spike during sowing season can starve the Farmer ID lookup service at exactly the wrong moment.

The FACRM: Federated AgriStack Cloud Readiness Model

The Federated AgriStack Cloud Readiness Model (FACRM) gives state teams a structured lens to assess their cloud infrastructure before the next phase of Bharat-VISTAAR rollout. It has five dimensions:

1. Connectivity resilience. Can the state registry survive a 6-hour WAN outage without data loss or corruption? Are write-ahead queues in place at the taluk level?

2. Registry isolation.Are Farmer Registry, Crop Sown Registry, and Village Map services on separate compute boundaries with independent scaling policies?

3. Central API coupling. Is the state’s connection to central AgriStack APIs asynchronous and queue-buffered, or synchronous and brittle?

4. AI workload isolation. Are inference workloads for Bharat-VISTAAR’s multilingual model separated from registry read/write workloads, with dedicated GPU burst capacity on a time-shared schedule?

5. Audit and data residency. Does the cloud architecture produce a complete audit log of all data reads and writes per Farmer ID, queryable by the Ministry’s central audit system without exposing raw farmer data?

Score each dimension from 1 to 5. A state ready for Kharif 2026’s final registration target should score at least 18 out of 25. Most state deployments we have audited score between 9 and 13.

Choosing the Right Cloud Services for AgriStack

The instinct among state technology teams is to reach for Kubernetes because it is what the cloud consultants they hired know. Kubernetes-first deployments are the wrong default for state AgriStack infrastructure. Most states need managed services and lightweight edge runners, not a container platform built for multi-tenant SaaS companies.

For the registry and sync layer: managed PostgreSQL with read replicas at the state level, AWS DynamoDB or Azure Cosmos DB for the offline queue buffer, and a message broker (Kafka or AWS SQS) for the central API decoupling layer. For Bharat-VISTAAR’s AI model: AWS SageMaker or Azure ML managed endpoints with auto-scaling disabled during off-peak windows to control costs. For the edge layer at taluk and Gram Panchayat: lightweight Node or Go API proxies on managed container services (AWS Fargate, GCP Cloud Run), not full Kubernetes clusters.

Multi-cloud is worth considering between the state and central layers. If your state runs on a government MeghRaj node and the central Ministry is on AWS, a cross-cloud event bridge with message transformation is a manageable integration pattern. A replicated private cloud across both is not.

What a Bharat-VISTAAR Rollout Requires at Scale

The Union Budget 2026 allocated Rs 150 crore to Bharat-VISTAAR. The Digital Agriculture Mission holds Rs 2,817 crore. The target is 30 crore farm plots across 604 districts by Kharif 2026. These numbers translate directly into infrastructure requirements: 300 million daily API calls at peak sowing and harvest periods, 11 language models serving advisory content simultaneously, and satellite imagery ingestion from the National Pest Surveillance System running continuous update cycles.

The states that will meet their registration targets are the ones that treat cloud architecture as a dependency of the political commitment, not a downstream implementation task. The ones that treat it as an IT procurement decision will spend Q4 2026 debugging production incidents during paddy harvest season.

A single Farmer ID resolution query that fails in the field sets back trust in the entire DPI by a season.

What This Means for Agriculture and AgTech Leaders

If your organization is building on AgriStack — as a state implementation partner, an AgriTech SaaS provider, or a platform integrator connecting ICAR data to field advisory apps — your cloud architecture needs a FACRM audit before the Rabi 2026 registration window opens. Specifically, this week:

Run a connectivity failure drill on your state registry. Disconnect the central API integration for 30 minutes and observe what happens to field registration sessions. If agents cannot continue working, you have a synchronous coupling problem that needs fixing before the next major registration push.

Review your workload placement. If AI advisory workloads share a compute boundary with Farmer Registry services, build a separation plan. The cost of isolation is low. The cost of a sowing-season outage is measured in farmer trust.

More Blogs : Building for the Bima Vahak: What Offline-First Really Means for Rural Insurance Apps

UPI Outage: Why Bank Core Banking Systems Fail Under Load

Posted on by Jayakrishnan M

The UPI Outage May Not Be an NPCI Problem. It Could Be Your Bank’s Core Banking Infrastructure.

UPI processed 22.72 billion transactions in June 2026, worth Rs 28.92 lakh crore. That is 23% growth year-on-year in volume, 20% in value. FY2026-27 projections put the network at 379 billion annual transactions a 57% increase over the year just completed. For context: 379 billion transactions spread across 365 days is 1.04 billion transactions per day, roughly 43 million per hour, averaged across the year. On peak days, during evening payment windows or year-end settlement runs, the real-time throughput is multiples of the average.

In January 2026, NPCI attributed a UPI outage to year-end transaction rush at banks. The attribution matters more than the headline: NPCI’s switching infrastructure sustained the load. The failures cascaded from bank-side core banking systems that could not sustain NPCI’s settlement reconciliation requests at peak throughput. The bottleneck was not on the national payment rail. It was in the bank’s own infrastructure the transaction posting engine, the settlement reconciliation service, and the real-time balance query layer that every UPI debit triggers.

For a mid-market scheduled commercial bank in South India we work with, the January outage produced a 40-minute degradation window during which UPI transaction confirmations were delayed by between 8 and 22 seconds. No transactions were lost, but 18% of their UPI retail customers received timeout errors and retried generating duplicate transaction attempts that the idempotency layer handled correctly but that added 35% additional load to an already saturated system. The root cause was not peak transaction volume alone. It was a settlement reconciliation batch job running concurrently with real-time transaction processing on shared database connections.

That is a performance engineering problem with a known set of solutions. It is also the problem that most Indian banks will face at higher severity when FY2026-27 volumes arrive.

Why Core Banking Performance Is Different From Application Performance

Enterprise application performance engineering typically focuses on request latency, throughput, and concurrency for web or API workloads. Core banking performance engineering is a subset of that discipline with three additional constraints that standard application performance work does not address.

Constraint 1: Settlement reconciliation is a batch workload running inside an OLTP system. Most core banking systems post real-time transactions to an OLTP database optimized for high-concurrency small reads and writes. The end-of-day (EOD) settlement reconciliation is a large sequential scan and aggregation workload that is fundamentally at odds with the OLTP profile. Running both on the same database, on the same compute, at the same time is the architectural root cause of the majority of UPI outage events at the bank level. The fix isolating the settlement batch to a read replica or a dedicated reporting layer is well understood. The deployment risk of migrating a live EOD process is the reason most banks have not done it.

Constraint 2: Every UPI transaction triggers a real-time balance check.Unlike card transactions, which tolerate an eventual-consistency balance confirmation, UPI transactions require the bank to confirm available balance in real time before authorization. At 22 billion monthly transactions, that is 22 billion real-time balance queries per month against the bank’s core balance system. The core balance query is typically the single highest-frequency database operation in a UPI-active bank. It must sustain sub-100ms response latency even during concurrent EOD batch operations. Most banks’ core banking balance tables are not partitioned or cached in a way that maintains this SLA under combined OLTP and batch load.

Constraint 3: NPCI’s timeout window is 30 seconds. If a bank cannot confirm or reject a UPI transaction within 30 seconds, NPCI marks it as a timeout and triggers a reversal. At high load, when core banking response times degrade, the timeout rate increases which generates reversals, which create additional posting entries, which increase the load on the same core banking system. This is the retry amplification loop that turned a manageable latency degradation in January 2026 into a 40-minute outage.

Payment System Performance Audit Protocol (PSPAP)

The PSPAP is a six-step audit framework for assessing a bank’s core banking infrastructure against its current and projected UPI load profile. Each step produces a finding and a remediation category.

Step 1: Project UPI Transaction Volume. Establish the bank’s current UPI TPS (transactions per second) at P50, P95, and P99 load levels. Project these against NPCI’s published FY2026-27 volume growth curve to determine the P99 load the system will need to sustain 18 months from now. For most mid-market banks, the P99 load is 3 to 4 times the P50 the daily volume curves spike sharply in the 6 to 9 PM window and on month-end and quarter-end dates.

Step 2:Profile Balance Query Latency. Instrument the real-time balance query path and measure P50, P95, and P99 latency at current P99 transaction load. The target is sub-100ms at P99. If your P95 balance query latency exceeds 80ms under normal load, it will exceed 300ms under combined OLTP and EOD batch load. This is the measurement that most banks have not taken, because the degradation only becomes visible under combined load conditions that standard performance testing does not simulate.

Step 3: Assess EOD Batch Isolation. Determine whether your EOD settlement reconciliation is sharing database compute and connections with real-time OLTP transaction processing. If yes, document the overlap window typically the 2 to 4 AM settlement run that now overlaps with international remittance activity and night-shift hospital payments. This overlap window is the highest-risk period for UPI performance degradation.

Step 4: Audit Idempotency and Retry Amplification. Review your UPI transaction idempotency implementation. Under load degradation, customers retry timed-out transactions. Your system must detect and suppress duplicate transaction postings while still providing a response to NPCI’s retry. Audit the ratio of retry transactions to original transactions during the January 2026 degradation window a ratio above 1.5x indicates an idempotency gap that amplifies load under exactly the conditions you cannot afford additional load.

Step 5: Assess Settlement Reversal Capacity. NPCI-initiated reversals from timed-out transactions must be processed in real time. Assess the throughput capacity of your reversal processing pipeline separately from your forward transaction pipeline. Banks that process reversals on the same queue as forward transactions discover under load that reversals queue behind forward transactions, extending the reversal processing window from seconds to minutes.

Step 6: Improve Monitoring and Alerting Assess whether your monitoring infrastructure can detect the performance degradation scenarios above before NPCI’s monitoring detects them externally. A bank that learns about its UPI degradation from an NPCI alert has already entered the 30-second timeout window. A bank with proactive monitoring on balance query P99 latency, EOD batch resource consumption, and retry transaction ratios can detect degradation in the 90-second to 3-minute range before NPCI’s timeout clock runs out.

More Blogs : Two Channels, Two API Contracts: Why Indian D2C Brands Need Headless Commerce Now

Two Channels, Two API Contracts: Why Indian D2C Brands Need Headless Commerce Now

Posted on by Jayakrishnan M
Two Channels, Two API Contracts: Headless commerce architecture for Indian D2C brands connecting ONDC and quick commerce through four layers—catalog publishing, inventory truth, order orchestration, and fulfillment routing.

Two Channels, Two API Contracts: Why Indian D2C Brands Need Headless Commerce Now

India’s D2C retail landscape bifurcated in 2026 and most engineering teams missed the moment it happened. On one side: ONDC, living in 400 cities, carrying over 3 lakh sellers on a 3% commission rail built on the open Beckn protocol. On the other: quick commerce, an $11.5 billion market run by Blinkit’s 2,100 dark stores, Zepto’s 1,100+, and Instamart’s growing footprint, each one wired for sub-10-minute fulfillment from hyper-local inventory.

Both channels are growing. Both are table stakes for D2C brands with national ambition. And they have fundamentally different API requirements. ONDC requires your product catalog to be published in Beckn’s JSON schema, your order management to process asynchronous webhook-based flows, and your server to maintain 99.99% uptime or your catalog disappears from search results instantly. Quick commerce requires your inventory API to return hard availability answers in under 500 milliseconds, support substitution rules, and lock stock at query time to prevent overselling. These two requirement sets cannot both be served efficiently by the same monolithic commerce backend.

ShopDirect Global, a cross-border D2C platform we built serving India and Southeast Asia, learned this the hard way. Their initial India launch used a single Shopify Plus storefront with ONDC integration via a middleware adapter. It worked until peak sale days, when the catalog sync delays on the middleware layer caused ONDC to serve stale inventory data while the quick commerce partner’s 500ms SLA was being breached on the same catalog update queue. The fix required separating the inventory read path from the catalog write path a headless restructuring that took 11 weeks to complete while they were live in production.

This post explains the architecture decision they should have made first, and a framework for evaluating where your current stack stands.

What “Headless Commerce” Actually Means in an ONDC Context

Headless commerce, in its original definition, separates the frontend presentation layer from the backend commerce engine. In an ONDC context, the relevant separation is different: it is the decoupling of the catalog management layer, the inventory management layer, the order management layer, and the fulfillment routing layer because each of these layers needs to serve different consumers with different latency and consistency requirements.

ONDC’s Beckn protocol models commerce as a sequence of asynchronous API calls: search, select, init, confirm, status, track, cancel, update, support. Each call generates a callback. Your Seller App backend must respond to these callbacks within the protocol’s defined timeout windows typically 2 to 30 seconds depending on the flow stage. The protocol is not synchronous. You cannot build an ONDC integration on a request-response commerce API and expect it to behave correctly.

Quick commerce channel APIs are the opposite: synchronous, sub-second, with hard consistency requirements. An inventory check that returns “available” must lock that unit for the next 90 seconds while the order is placed. A stale cache is not a nuisance it is a cancelled order and a platform penalty.

These two requirements asynchronous multi-step protocol with catalog visibility as the goal, vs. synchronous sub-second inventory lock with fulfillment as the goal cannot be served from the same read path.

ONDC Commerce Readiness Layers (OCRL)

The OCRL is a four-layer model for structuring a commerce backend that can serve ONDC and quick commerce channels concurrently without shared bottlenecks.

Layer 1: Catalog Publishing Service. A dedicated service that owns the authoritative product catalog and publishes it to all downstream channels. This service writes to ONDC via the Beckn protocol on a change-event basis (not a polling basis). It writes to quick commerce channel APIs via webhook or API push. It does not serve customer-facing requests directly. The key design constraint: catalog updates must propagate to ONDC within the protocol’s defined reconciliation window, typically 15 minutes for catalog changes, or your catalog falls out of search.

Layer 2: Inventory Truth Service. A dedicated service that owns real-time inventory across all dark store locations, warehouse nodes, and fulfillment centers. This is the service that quick commerce APIs query for availability. It must be designed for sub-500ms read latency and support optimistic locking for concurrent availability checks. It does not serve ONDC directly ONDC availability is calculated from the Inventory Truth Service at order-init time, not at search time.

Layer 3: Order Orchestration Service. A dedicated service that manages order state across all channels. For ONDC orders, this service handles the asynchronous Beckn flow receiving confirm callbacks, routing to fulfillment, publishing status updates. For quick commerce orders, it handles synchronous dispatch to the dark store picker workflow. The critical design principle: order state must be channel-agnostic. An ONDC order and a Blinkit-fulfilled order of the same product from the same inventory pool must use the same underlying inventory decrement operation.

Layer 4: Fulfillment Routing Engine. A dedicated service that selects the fulfillment node for each order based on customer location, available inventory, SLA, and channel constraints. This is where the ONDC “deliver in X days” and the quick commerce “deliver in 10 minutes” SLAs are reconciled against physical inventory distribution. Most D2C brands do not build this as a separate service they embed routing logic in the order management system. At moderate scale, embedded routing becomes the bottleneck that neither channel’s SLA can tolerate.

Selling on ONDC is not a channel decision. It is a backend architecture decision that you cannot undo cheaply.

The Beckn Protocol Details That Will Break Your Integration

Becoming an ONDC Seller Network Participant (SNP) requires your backend to implement the Beckn protocol stack, which is not a REST API in the conventional sense. Three technical decisions tend to cause the most integration failures.

Certificate-based participant registry. ONDC uses a decentralized participant registry where each SNP publishes a signing key. Every API call between buyer apps and your seller app is signed. If your middleware layer does not implement request signing correctly, buyer apps will drop your catalog from search results without an explicit error message. Debugging unsigned request failures in a decentralized network is substantially harder than debugging a 401 from a traditional API.

Catalog schema compliance at the category level. ONDC defines different catalog schemas for different product categories: grocery, fashion, electronics, food service, and others. A catalog published in the wrong schema for a category will not surface in buyer app searches for that category. Most D2C brands selling across categories need category-specific catalog adapters. A single generic Beckn catalog serializer covers approximately 60% of the cases before category-specific fields start causing silent failures.

Multi-availability zone deployment for catalog uptime. ONDC makes catalog visibility contingent on your SNP backend being reachable. If your backend is unavailable, your catalog disappears from buyer app searches not with a placeholder, not with a “temporarily unavailable” notice, just absence. This creates a 99.99% uptime requirement that most D2C backends were not designed to meet. Deploying across multiple availability zones with automated failover is not optional for an ONDC integration at production scale.

What This Means for E-commerce and Retail Leaders

If you are a CTO, Head of Engineering, or VP Product at a D2C brand considering or already pursuing ONDC integration and quick commerce channel expansion, here is what to focus on in the next 30 days:

Separate your inventory read path from your catalog write path. This is the single most impactful architecture change you can make before ONDC integration begins. It eliminates the primary bottleneck that causes availability data on ONDC to lag behind actual inventory state.

Assess your backend uptime against ONDC’s catalog visibility requirement. Run a 30-day availability audit on your current commerce backend. If you are seeing downtime events above 0.01% monthly (roughly 4 minutes per month), you will have catalog visibility gaps on ONDC. Multi-AZ deployment is the fix, not application optimization.

Build your ONDC Beckn integration against the staging environment, not production. ONDC provides staging, preprod, and production environments. Most teams rush to production integration. The certificate registry, the catalog schema validators, and the asynchronous callback flows all behave differently in staging. Budget four to six weeks in staging before requesting production onboarding.

More Blog” ABC Integration for Universities: How NEP 2020 Is Reshaping Academic Credit Systems

The DPDP rules are live, and the government is a data fiduciary. Most State Systems Are Not Ready.

Posted on by Jayakrishnan M
DPDP Rules Compliance for State Systems – five-step data privacy framework covering data discovery, purpose mapping, consent architecture, data minimization and retention, and breach response and audit readiness.

The DPDP rules are live, and the government is a data fiduciary. Most State Systems Are Not Ready.

India’s Digital Personal Data Protection Rules 2025 came into force with a clear provision that most government technology teams have not fully absorbed: government bodies are data fiduciaries under the Act. Not all of them, and not without qualifications Section 17 provides specific exemptions for certain national security and law enforcement processing but every state citizen portal, integrated beneficiary management system, property tax platform, and public health records database that collects, stores, or processes personal data is operating as a data fiduciary with active compliance obligations.

The DPDP Rules convert legal principles into operational requirements: consent design, breach reporting within 72 hours to the Data Protection Board, data retention limits, child data protections, and audit readiness. These are not policy commitments. They are system capabilities that either exist or do not.

A GCC government technology office we work with began its DPDP-equivalent compliance exercise in 2024 their national data protection framework maps closely to the DPDP Act’s structure and timeline. The first month was spent on data discovery: cataloguing where citizen personal data resided across 14 separate government systems, many of them built by different vendors over a decade. They found personal data in places no one remembered: a 2012 beneficiary database no longer actively used but still reachable on the internal network, a PDF archive of scanned identity documents in an NFS share with no access controls, and six separate citizen identity lookups spread across systems that each stored a copy of the data rather than referencing a central registry.

Discovery alone took six weeks. Until it was complete, no consent management project could proceed honestly. That sequencing error building consent flows before knowing where the data lives is the most common DPDP compliance mistake government technology teams are making in 2026.

What the DPDP Rules Actually Require of Government Systems

The Act distinguishes between the Data Principal (the citizen) and the Data Fiduciary (the government body processing their data). As a Data Fiduciary, government bodies must:

Give notice before collecting personal data.The notice must be in plain language, specify the purpose for which data is collected, and identify what categories of data are being processed. Most government systems collect data at service enrollment without separate notice the enrollment form is the notice, which does not meet the DPDP standard when data is shared across departments for purposes beyond the original enrollment context.

Collect and process data only for specified purposes. Data collected for a ration card application cannot be used for a law enforcement inquiry unless a legal basis under Section 17 applies. Cross-department data sharing a routine practice in integrated beneficiary management systems requires explicit legal authorization for each purpose beyond the originating service.

Honor data principal requests. Citizens have the right to confirmation of processing, access to their data, correction of inaccurate data, erasure of data no longer needed for the original purpose, and grievance redressal within defined timelines. The Act gives the Data Protection Board enforcement authority to impose penalties up to Rs 250 crore for systemic failures in honoring these rights. For government systems, honoring a deletion request requires knowing where that citizen’s data lives across all systems which returns to the data discovery problem.

Report breaches within 72 hours. The 72-hour breach notification requirement to the Data Protection Board demands an incident response workflow that most government IT operations teams do not currently have. A data breach in a legacy citizen database is a DPDP compliance event as well as a security event.

Citizen Data Systems Compliance Framework (CDSCF)

The CDSCF is a five-step compliance ladder for government technology teams working through DPDP obligations on legacy citizen data systems.

Step 1: Data Discovery and Classification. Before any technical controls can be built, you must know where personal data lives. This means cataloguing data across all systems active, legacy, and archived and classifying by sensitivity category (identity, financial, health, biometric) and volume. Data discovery for a medium-sized state government with 8 to 12 citizen-facing systems typically takes 4 to 6 weeks with the right tooling. Classification follows classification: identity data in a property tax system has different DPDP obligations than the same identity data in a health records system because the processing purpose differs.

Step 2: Purpose Mapping. For each data category in each system, map the processing purpose against the legal basis under the DPDP Act. Processing for a government function under a law is permissible without consent under Section 7(g). Processing for purposes beyond the original legal mandate requires consent or a separate legal basis. Purpose mapping reveals the cross-department data flows that are legally exposed typically 20 to 40% of identified data flows in an integrated government system have inadequate legal basis documentation.

Step 3: Consent Architecture. Where citizen consent is required, design the consent mechanism. Government systems often collect consent as a checkbox on an enrollment form. DPDP requires that consent be: freely given (the citizen must not lose access to a mandated service for refusing), specific (per processing purpose, not a blanket consent), informed (in plain language), and revocable (the citizen can withdraw consent and the system must respond). A compliant consent architecture for government systems is typically a consent management layer that sits above individual application systems and records consent grants and revocations against the citizen’s identity, not against a session or application.

Step 4: Data Minimization and Retention Controls. DPDP prohibits retaining personal data beyond the purpose for which it was collected. Government systems routinely retain data indefinitely a citizen who applied for a scheme in 2015 and was rejected may have their identity data persisting in the system without any active purpose. Implementing retention controls requires automated lifecycle policies, not manual review. For systems without data retention logic, this means building a scheduled purge process with audit logging.

Step 5: Breach Response and Audit Readiness. The final step is operationalizing the 72-hour breach notification workflow and building audit logs that support a Data Protection Board inquiry. Audit logs must capture: who accessed what data, when, from which system, for which stated purpose. Most government system audit logs were designed for system troubleshooting, not regulatory inquiry. They typically lack purpose-of-access fields and are not tamper-evident.

Data discovery is the step that every government technology team underestimates. You cannot consent-manage data you cannot locate.

The Systems That Need Attention First

Not all government systems carry equal DPDP compliance risk. Three categories deserve priority engineering attention.

Integrated beneficiary management systems. These systems sit at the intersection of identity, income, health, and family composition data. They share data across departments by design. The combination of high data sensitivity, high volume, and multi-purpose data flows makes them the highest compliance risk in a typical state government portfolio. The legal basis for each cross-department data share needs to be documented before the system can be brought into DPDP compliance.

Citizen portal identity systems. Any system that stores Aadhaar-linked identity data, PAN, or biometric authentication records falls under additional restrictions. Aadhaar data handling requirements under the Aadhaar Act interact with DPDP where the two frameworks apply simultaneously, the more restrictive requirement governs.

Legacy archived systems. The DPDP Act’s data minimization requirement applies to archived data, not just active databases. A 10-year-old beneficiary database that is no longer actively updated but still accessible is a compliance liability. The decision of whether to purge, anonymize, or isolate legacy archives is among the most consequential DPDP decisions government technology leaders will make in 2026.

A citizen portal built in 2018 is not DPDP-compliant because it has a privacy policy. It is DPDP-compliant when it can locate, restrict, and delete a citizen’s data within 72 hours on request.

What This Means for Government Technology Leaders

If you lead technology for a central ministry, state IT department, or government-owned entity processing citizen data, the most productive actions for this quarter do not require a compliance vendor or a platform purchase:

Commission a data inventory. Two weeks of structured discovery across your active citizen-facing systems will produce a data map that is the prerequisite for every downstream compliance decision. Without it, your DPDP compliance roadmap is guesswork.

Identify your Section 7 legal basis for each data processing activity. Government processing of data under a law or function specified by law is permissible without consent. Document which activities have this basis and which do not. The ones without a documented legal basis are the ones requiring immediate attention.

Assign a Data Protection Officer. The DPDP Act requires significant Data Fiduciaries to appoint a DPO. Government bodies processing health, biometric, or large-scale identity data are likely to meet the significant Data Fiduciary threshold. The DPO needs systems visibility, not just legal authority.

Audit your breach response readiness. Test the 72-hour breach notification capability with a tabletop exercise. If your incident response team cannot complete a breach assessment and submit a notification draft within 4 hours, the 72-hour clock is already a risk.

More Blog : OT Cybersecurity for Indian PLI Manufacturers: Why IT-First Zero Trust Fails

Why AIS-230 API Standard Is the Most Important API Standard Indian OEMs Have Never Heard Of

Posted on by Jayakrishnan M

Why AIS-230 API Standard Is the Most Important API Standard Indian OEMs Have Never Heard Of

On August 4, 2026, India’s Ministry of Road Transport and Highways published a draft notification mandating Vehicle-to-Vehicle (V2V) communication in all L, M, and N category vehicles every passenger car, truck, bus, motorcycle, and scooter manufactured after October 1, 2028. The standard is AIS-230. The protocol is C-V2X. The engineering deadline is tighter than it looks.

This is not a future-mobility thought experiment. It is a gazette notification with a compliance date. Every OEM shipping vehicles into India has roughly 24 months to build, test, and certify a connected vehicle telematics stack that most of their software teams have never touched. The engineering bottleneck is not the On-Board Unit (OBU) chipset. It is the API layer that connects that OBU to backend services, to road infrastructure, and eventually to a national V2X data exchange that the government has not finished specifying.

This post covers what AIS-230 actually requires at the API layer, where most OEM engineering teams will misread the mandate, and a framework for scoping the work before your compliance window closes.

What AIS-230 Actually Requires

The MoRTH draft names Cellular Vehicle-to-Everything (C-V2X) as the required protocol, operating in the 5.875 GHz to 5.925 GHz frequency band. The Department of Telecommunications exempted this band from licensing requirements through a separate notification on June 10, 2026, clearing the spectrum path for deployment. TRAI has opened a parallel consultation on the V2X ecosystem which means the regulatory stack is moving in real time.

AIS-230 mandates factory-fitted OBUs that support:

– Vehicle-to-Vehicle (V2V) broadcast: collision warning, emergency braking alerts, blind spot hazard messages

– Vehicle-to-Infrastructure (V2I): traffic signal phase data, road hazard broadcasts, toll infrastructure handshakes

– Vehicle-to-Pedestrian (V2P): proximity alerts for two-wheelers and pedestrians carrying V2X-enabled devices

India is the first country in the world to extend V2V requirements to every motorcycle and scooter. That coverage distinction matters for API design because two-wheeler OBUs operate under tighter power and compute constraints than passenger car units, which changes the message format, the transmission interval, and the backend processing requirements for managing the volume of V2X broadcasts at scale.

The OBU broadcasts Basic Safety Messages (BSMs) at 10Hz. In a dense urban traffic cluster of 50 vehicles within 300 meters, your backend infrastructure needs to process 500 BSM events per second, per cluster, in near real time.

The Four Layers Your V2X API Stack Must Address

AIS-230 is primarily a wireless protocol specification. It does not dictate backend architecture. That is where the engineering judgment comes in, and where shortcuts compound into expensive retrofit projects.

Layer 1: On-Board Message Broker. The OBU must serialize BSMs in the standard J2735 message format and broadcast over PC5 (direct V2V) and Uu (cellular uplink). The firmware API contract between the OBU vendor and your vehicle software stack determines how your powertrain and ADAS systems receive incoming hazard messages. Most OEMs are treating this as an ECU integration task. It is actually an API contract with latency SLAs in the 100-millisecond range.

Layer 2: Telematics Gateway. The cellular uplink connects the OBU to a cloud backend via a telematics gateway. This gateway must handle protocol translation (J2735 binary to your internal event schema), authentication (certificate-based mTLS for V2X as specified under IEEE 1609.2), and routing of incoming V2X messages from national infrastructure. The gateway is where most OEM backends are under-designed: built for diagnostic data polling, not for bidirectional real-time event streams.

Layer 3: National V2X Exchange API. The government’s Intelligent Transportation System infrastructure will eventually publish a national V2X data exchange API. The specification does not exist yet, but the architecture is directionally clear from TRAI’s consultation: a publish-subscribe model for road condition broadcasts, a registry for RSU (Road-Side Unit) endpoints, and certificate authority services for device identity. Your backend must be designed to integrate with this exchange when it publishes, not retrofitted after.

Layer 4: OEM Application API. Above the telematics gateway sits your OEM application layer: the ADAS integration, the in-cabin alerting system, the fleet management dashboard, and the over-the-air (OTA) software update pipeline. Each of these consumes V2X data differently. Your API design must separate the real-time event stream (latency-critical) from the aggregate reporting stream (analytics-oriented) at this layer.

Connected Vehicle API Contract Scorecard (CVACS)

The CVACS is a five-dimension evaluation tool for assessing V2X API readiness. Score each dimension from 1 (not started) to 4 (production-ready):

Dimension 1: Protocol Compliance. Does your OBU firmware implement J2735 message sets and IEEE 1609.2 certificate management? Score 4 if you have a test environment generating and consuming BSMs at spec. Score 1 if your OBU vendor has not confirmed C-V2X chipset availability.

Dimension 2: Gateway Latency Architecture. Can your telematics gateway handle bidirectional V2X event streams with sub-100ms processing latency? Score 4 if you have load-tested at 500 events/second per cluster. Score 1 if your gateway was designed for diagnostic data batched at 60-second intervals.

Dimension 3: Certificate Lifecycle Management. IEEE 1609.2 requires pseudonym certificates that rotate on a time and distance schedule to protect vehicle privacy. Score 4 if you have a PKI integration plan for certificate issuance, rotation, and revocation. Score 1 if certificate management is not yet on your architecture diagram.

Dimension 4: National Exchange Readiness. Has your API design included an adapter layer for connecting to the eventual national V2X exchange? Score 4 if you have built a configurable connector using standard publish-subscribe patterns (MQTT or AMQP). Score 1 if your backend assumes direct OBU-to-application communication with no exchange layer.

Dimension 5: OTA Update Pipeline V2X firmware will require updates as the national standard evolves. Score 4 if you have an OTA pipeline with rollback capability, staged deployment, and delta updates. Score 1 if OTA updates require physical service center access.

A score of 12 or above indicates teams that can meet October 2028 with focused engineering effort. Below 8, you are looking at a foundational rebuild.

We applied an early version of this scorecard at a fleet telematics company serving EV operators across South Asia. Their gateway latency score was a 1: the entire backend was built on a polling model with 15-second intervals. Retrofitting that for real-time V2X event streams required a full message broker redesign, not a configuration change.

>AIS-230 is not a safety feature. It is a 2028 API deadline embedded in a regulatory gazette.

Where Most OEM Telematics Teams Will Get This Wrong

Every OEM that treats the C-V2X OBU as a hardware procurement question will spend 2027 rebuilding the software layer from scratch.

The most common mistake is buying a certified C-V2X OBU from a Tier-1 supplier and assuming the compliance box is checked. The OBU handles the radio layer. It does not handle the backend API contract, the certificate management infrastructure, the latency architecture of your telematics gateway, or the integration surface for the national V2X exchange.

The second common mistake is designing for the vehicles in production today. AIS-230 mandates compliance for vehicles manufactured from October 2028. That means any model entering development or homologation now must be designed for V2X from the ground up. Model cycles in India typically run three to five years. The OEMs that start architecture planning now will be in production with compliant platforms. The ones that start in late 2027 will be requesting homologation extensions.

The third mistake is siloing this work inside the ECU team. V2X touches the OBU firmware, the telematics gateway, the ADAS stack, the OTA pipeline, the PKI infrastructure, and eventually the national exchange integration. It requires a cross-functional API contract definition that most OEM software teams have not produced before.

What This Means for Automotive Leaders

If you are a CTO, VP Engineering, or Head of Software at an OEM, Tier-1 supplier, or mobility platform operating in India, the practical steps for this quarter are:

Assess your telematics gateway architecture against real-time event stream requirements. If it was designed for diagnostics polling, document the gap now and scope the rebuild.

Confirm C-V2X chipset availability with your OBU vendor. Several Tier-1 suppliers are still delivering legacy DSRC-based OBUs. AIS-230 names C-V2X. Substitution is not currently permitted.

Map your PKI dependencies. IEEE 1609.2 certificate management requires a vehicle identity infrastructure that most OEM backend teams do not currently operate. Early engagement with established automotive PKI providers reduces later risk.

Assign an API owner for V2X. Not a hardware owner. Not a firmware owner. Someone who owns the API contracts between the OBU, your telematics gateway, and the downstream application layer. That role does not exist at most Indian OEMs today.

You do not need to have a production-ready V2X stack this quarter. You need to have a credible architecture plan and a clear understanding of your CVACS score. Both of those are achievable in 30 days.

More Blog: Multi-Agent AI in Indian 3PL: Powerful Freight Visibility Before Agent Automation

Building for the Bima Vahak: What Offline-First Really Means for Rural Insurance Apps

Posted on by Jayakrishnan M
Building for the Bima Vahak: What Offline-First Really Means for Rural Insurance Apps – offline durability, vernacular completeness, data persistence, and device compatibility for rural insurance access.

Building for the Bima Vahak: What Offline-First Really Means for Rural Insurance Apps

IRDAI’s Bima Vahak channel enrolled its first agents in April 2025. A women-led insurance distribution network, Bima Vahaks sell the bundled Bima Vistaar product combining life, health, and property coverage through a mobile app connected to the Bima Sugam marketplace backend. An InsurTech operating across Kerala and Karnataka that we work with had 3,800 enrolled Vahaks by mid-2026. In the first 90 days of operation, they received 2,100 support tickets. Eighty-three percent of those tickets described the same problem: eKYC data entered during a customer visit was lost before submission, requiring the Vahak to revisit the customer to recapture it.

The app was built by a competent team. It integrated correctly with the Bima Sugam API. It passed QA in the office. It failed in the field because it stored form state in memory rather than persistent local storage and every network interruption during the 4 to 6 minute eKYC flow wiped the session.

This is not an edge case. It is the design gap that appears in nearly every insurance agent app built for urban assumptions and deployed to rural realities.

The Distribution Problem Bima Vahak Is Solving

India’s insurance penetration sits at approximately 3.2% for life insurance and 1% for non-life well below the global average of 7% across both categories. The structural gap is not product pricing or product awareness in metros. It is reach in rural and semi-urban India, where the existing distribution channels corporate agents, bancassurance, POSP networks either do not operate profitably or do not carry the trust of the community they are serving.

Bima Vahak is a structural fix for the trust problem. Women from the local community, trained to sell a simplified bundled product through a digital workflow, serve as the credible distribution intermediary that no corporate agent can replicate.

The technical challenge this creates is significant: the distribution workforce is not insurance professionals, will not use the app in an office environment, and in 40 to 60% of customer interactions will have 2G-tier connectivity or intermittent signal. The app must eliminate product knowledge requirements from the sales flow, handle all regulatory compliance (eKYC, consent logging, policy issuance) without requiring the Vahak to understand what those processes mean technically, and complete the entire enrollment without requiring stable connectivity at any mandatory step.

Phase 2 of Bima Sugam (2026) adds claims intimation, health data API integration for health underwriting, and policy portability workflows. Each of these features is more connectivity-sensitive than basic policy enrollment which means the offline architecture decisions made in Phase 1 are the foundation Phase 2 is built on. Getting them wrong now means rearchitecting under operational pressure later.

Bima Vahak App Development: Why Standard Insurance Apps Fail Rural Agents

The standard insurance app development lifecycle assumes: 4G connectivity during use, Android 10 or above on a mid-range device (3 to 4GB RAM), and a user completing the enrollment flow in a single continuous session. These assumptions describe an urban bancassurance or corporate agent, not a Bima Vahak in a village in Vidarbha.

The failure modes in the field:

Session memory loss on network interruption.The most common failure, as described above. eKYC flows require 4 to 6 minutes of continuous data entry Aadhaar number, customer consent, biometric capture, nominee details. If any step requires an API call to proceed, and the API call fails on a dropped signal, a form-state-in-memory design loses everything entered before the failure.

eKYC API timeout on 2G. Biometric verification APIs have timeout thresholds that are calibrated for 4G latency. A fingerprint or face liveness API that expects a response in under 3 seconds will time out on 2G connections where round-trip time is 500ms to 2,000ms. The timeout is not logged as a connectivity failure it is logged as an eKYC failure, which is confusing to the Vahak and creates incorrect compliance records.

App crash on low-memory devices. Android Go devices (512MB to 2GB RAM) are the dominant device category among Vahaks in rural markets. Apps built and tested on developer workstations or mid-range test devices (4GB RAM) have memory allocation patterns that cause crashes on Go-class devices when background processes compete for RAM during a camera or biometric capture flow.

English-only error messages. When the app encounters an error, the message is in English. The Vahak reads Tamil or Marathi. She sees an incomprehensible error, restarts the app, loses her data, and files a support ticket.

An insurance app that drops eKYC data on network loss is not an offline-first app. It is an online app that silently fails offline.

The Rural Insurance App Readiness Score (RIARS)

RIARS is a four-dimension assessment that evaluates whether a Bima Vahak app is actually deployable to rural distribution networks. Each dimension has a clear pass criterion. An app must pass all four before field deployment. Partial passes create the failure modes described above.

Dimension 1: Offline Durability. The entire policy enrollment flow eKYC capture, customer details, product selection, consent recording, nominee capture completes without any live network dependency after the app has loaded. API calls for data submission happen in the background after the session is complete, not as blocking steps within the flow. Pass criterion: a complete enrollment can be captured in airplane mode, stored locally, and submitted when connectivity restores with no data loss and no re-entry required.

Dimension 2: Vernacular Completeness. Every screen, every error message, every field label, and every customer-facing document is available in the Vahak’s configured language. No English fallback appears in the primary enrollment or claims flow. Pass criterion: a complete end-to-end flow test in Tamil, Marathi, or Bengali produces zero English-language strings visible to the user. Error messages from the Bima Sugam API are translated before display, not passed through raw.

Dimension 3: Data Persistence Guarantee. Every form entry is written to local persistent storage (SQLite or Hive) before any network submission is attempted. Biometric captures are stored as encrypted local files, not as in-memory blobs. If the app is force-closed at any point during an enrollment, restarting the app resumes from the last persisted state without data loss. Pass criterion: kill the app process during eKYC capture, restart, and verify that all entered data is present and the Vahak can continue from the last completed step.

Dimension 4: Device Compatibility. The app has been profiled and tested on an Android Go Edition device with 2GB RAM under 2G network simulation. Camera and biometric capture flows complete without OOM crashes. The P90 screen render time under these conditions is under 2 seconds. Pass criterion: run a full enrollment flow on a Redmi Go or Nokia G11 on a 2G-simulated connection (use Chrome DevTools network throttling at the Android proxy level). If the flow completes without crash and all screens render in under 2 seconds P90, the app passes Dimension 4.

The Architecture: Offline-First with Bima Sugam Integration

Flutter is the right implementation choice for Bima Vahak apps, for three reasons: single codebase for Android deployment (the primary platform for rural India), strong localization infrastructure with ARB-based string management that scales to 12 to 15 Indian language variants without architectural changes, and efficient rendering on low-end Android hardware.

The offline-first architecture has four components:

Local data store (Hive or SQLite with encryption). Every enrollment session is a local record. The record schema mirrors the Bima Sugam API request body, so no transformation is needed at submission time. Encryption at rest is mandatory a device loss exposes customer PII without it. Hive with AES-256 encryption at the box level satisfies this requirement without complex key management.

Background sync queue. Completed enrollment records are queued for submission. The queue manager runs as a background isolate, submitting records when connectivity is available and retrying on failure with exponential backoff. Idempotency keys on all Bima Sugam API endpoints prevent duplicate policy issuance when the same record is submitted more than once due to sync interruptions.

Connectivity-aware eKYC flow. Aadhaar-based eKYC via DigiLocker requires connectivity. Biometric eKYC via a fingerprint or liveness API requires connectivity. Design the flow so that connectivity-dependent steps are isolated and have explicit offline fallback paths: if connectivity is not available, capture the customer’s Aadhaar number and consent locally, defer the OTP-based verification to a background step when connectivity restores, and notify the Vahak when eKYC is complete rather than blocking her during the wait.

Conflict resolution policy. When the same enrollment record is modified on-device and then compared against a server-side record at sync time, the conflict resolution rule must be explicit. For policy enrollment records: server wins (the Bima Sugam confirmation is authoritative). For biometric data captured offline: device wins (do not discard biometrics already captured). This distinction matters most when a Vahak completes enrollment offline and then the server returns a validation error for a field that was valid offline.

Claims Intimation: The Feature That Cannot Fail Offline

Phase 2 of Bima Sugam adds claims intimation the workflow where a Vahak helps a customer notify the insurer of a claim event: a crop loss, a health hospitalization, a property damage incident.

Claims intimation is the moment that matters most to the customer and requires the most offline reliability. Most insurers test it last.

A Vahak helping a farmer document a flood damage claim is standing in the affected field. Signal may be intermittent. The claim evidence photographs, GPS coordinates, incident details, policy number must be captured completely before the Vahak leaves the site. If the app cannot guarantee that captured evidence is persisted locally with the same reliability as an enrollment record, the claim is at risk of being incomplete or lost.

The architectural requirement: claims intimation uses the same offline-first framework as enrollment. Evidence captured as local files (photographs as compressed JPEG in the Hive store, GPS coordinates as a structured record) before any API call is attempted. Submission is background-queued. The Vahak receives a local confirmation (“claim documented”) immediately, and a connectivity-dependent confirmation (“claim registered with insurer”) when sync completes.

Phase 2 also adds health data API integration for underwriting Abha ID linkage and health record fetch. These are connectivity-required flows, and they must be clearly distinguished from the offline-capable flows so the Vahak knows when she must ensure connectivity before proceeding.

What This Means for InsurTech Leaders

Three things to test this week, before your next field deployment:

Open your Bima Vahak app on an Android Go device and enable airplane mode 2 minutes into an enrollment flow. Note what happens to the data you entered. If it is gone when you re-enable connectivity, Dimension 3 is failing.

Attempt a full enrollment in the native language of your highest-density Vahak geography. Note every English string you encounter. Each one is a Dimension 2 failure in that specific geography.

Check your claims intimation test protocol. Does it include an offline simulation capturing evidence with no connectivity and verifying that the evidence is persisted after an app restart? If the claims intimation test only runs on a connected device, you have not tested the scenario that matters most for a rural Vahak.

The highest-fidelity test of a Bima Vahak app is not a demo in Bangalore. It is a Vahak completing a full policy enrollment in a village in Vidarbha on a 2G connection. Build that test into your QA process before Phase 2 features are added. Retrofitting offline architecture onto a connected-first codebase costs 3 to 4 times more than building it in from the start.

More Blog : OT Cybersecurity for Indian PLI Manufacturers: Why IT-First Zero Trust Fails

GET IN TOUCH

  •   (+91) 484-402-6866

  • INDIA: Office No.10-B1, Trans Asia Cyber Park, Infopark SEZ Phase-II, Ambalamedu, P.O, Kochi, Kerala 682303

  •   (+1) 415-404-6656

  • info@codelynks.com

    • Newsletter

    Subscribe to our newsletter
    for latest updates

  • [footer_subscribe_form]

  • Copyright © 2026 codelynks.com. All rights reserved.

  • Terms of Use | Privacy Policy