The National Common Mobility Card (NCMC) initiative is revolutionizing the way India travels, offering seamless, interoperable payment solutions across transit systems, retail outlets, and other digital platforms. At the heart of this powerful ecosystem lies a critical technological component: the NCMC Level 2 (L2) Kernel. This sophisticated software engine ensures secure and standardized communication between the card and the payment terminal, playing a pivotal role in transaction authentication, processing logic, and compliance with regulatory and interoperability frameworks.

In this blog, we delve into the core architecture, development workflow, and compliance requirements that define the NCMC L2 Kernel. Whether you’re a transit authority, payment terminal manufacturer, fintech provider, or embedded software developer, understanding the intricacies of L2 Kernel development is essential for building reliable, future-ready mobility and payment solutions aligned with India’s digital transformation goals.

Let’s explore the critical components and development strategies that power the NCMC experience.

What is NCMC?

The National Common Mobility Card (NCMC), often dubbed “One Nation One Card,” is an interoperable transport and payment solution initiated by the Ministry of Housing and Urban Affairs, implemented by NPCI (National Payments Corporation of India). NCMC allows users to pay for travel, toll, parking, retail shopping, and withdraw cash using a single contactless card powered by RuPay and EMVCo standards.

At the core of this functionality lies the NCMC Kernel a software module embedded within a payment terminal or reader that understands how to process NCMC transactions securely and efficiently.

NCMC Kernel Architecture 

The NCMC kernel’s architecture is composed of several tightly integrated modules, each designed to handle a specific stage in the life cycle of an NCMC transaction. Here’s a breakdown:

EMV Level 1 Communication Layer

This layer acts as the foundational communication interface between the card and the terminal hardware. It adheres to the ISO/IEC 14443 standard (Type A/B), enabling contactless RF communication. It establishes a secure channel, initiates card detection, handles ATR (Answer To Reset), and transmits APDU commands back and forth with minimal latency.

NCMC Level 2 Kernel (Transaction Engine)

At the heart of the architecture lies the transaction engine, which manages the entire EMV transaction flow specific to NCMC use cases. It interprets EMV data objects, manages session state machines, validates card authenticity, enforces NPCI-mandated transaction rules, performs cryptographic operations, and ensures that every step meets NPCI and EMVCo requirements.

Cryptographic & Security Services

A dedicated cryptographic module within the kernel secures all sensitive operations. It includes support for:

• Symmetric encryption (e.g., 3DES, AES) for secure messaging
• Asymmetric encryption (e.g., RSA) for card and issuer authentication
• MAC generation and validation to ensure data integrity
• Secure key storage, often integrated with a SAM (Secure Access Module) or Trusted Execution Environment (TEE).

Terminal Interface & Host Communication APIs

This layer acts as a bridge between the kernel and the host terminal application. It provides a standardized interface to pass transaction data, retrieve fare configurations, trigger receipt printing, handle UI interactions, log transactions, and request online authorization where required.

Card Management & Blacklist Handling Module

This component handles dynamic risk controls by maintaining an up-to-date local blacklist of invalid, expired, or hot listed cards. The kernel uses this list to instantly reject blacklisted cards before a transaction progresses, thus enhancing security and minimizing risk exposure.

2. NCMC Kernel Transaction Workflow

The transaction workflow outlines each event from card detection to transaction completion. Each step involves coordinated interaction between the terminal hardware, kernel software, and optionally, backend systems.

Terminal Initialization and Readiness

Once the terminal powers on, it initializes its components — including the operating system, EMV Level 1 library, and the NCMC kernel. The terminal is then placed in standby mode, continuously polling for a card to be tapped via the RF interface.

Card Detection and Activation

When a user taps an NCMC-enabled card, the terminal’s RF interface detects the card presence, establishes an anti-collision sequence, and selects the right card from the pool (if multiple cards are in range). It then exchanges ATR (Answer To Reset) data to initiate communication.

Application Identification and Selection

The kernel sends a SELECT command to choose the NCMC application from the card. The card responds with the necessary AID (Application Identifier), indicating that it supports NCMC standards. The kernel confirms version compatibility to ensure seamless processing.

Get Processing Options (GPO)

This command determines how the kernel should process the card. The card returns Application Interchange Profile (AIP) and Application File Locator (AFL), which direct the terminal to relevant data records and indicate the card’s supported capabilities.

Reading Card Application Data

Following the AFL guidance, the kernel reads important data files:

• Cardholder details
  
• Application expiration and effective date
  
• Available offline balance
  
• Transit-related configurations (e.g., travel history, fare caps)
  
• Card authentication certificates

Offline Data Authentication (ODA)

This step is vital for trust. Depending on terminal capabilities and card type, the kernel performs:

• SDA (Static Data Authentication) to verify static signed data
  
• DDA (Dynamic Data Authentication) using dynamic cryptograms
  
• CDA (Combined DDA with Application Cryptogram Generation) for enhanced mutual verification
  

This ensures the card is genuine, unaltered, and issued by a trusted institution.

Cardholder Verification (CVM) Processing

Based on fare amount, terminal risk settings, and card rules, the kernel determines if the cardholder must be verified. For low-value, tap-and-go payments, No CVM is required. For higher-value transactions, PIN or biometric verification might be requested if the terminal supports it.

Terminal Risk Management & Transaction Decisioning

The terminal checks for predefined thresholds:

• Velocity checks (number of taps per time frame)
  
• Floor limits (maximum offline fare per transaction)
  
• Offline balance limit
  

Based on this, it decides to proceed offline, go online, or decline the transaction.

Generate Application Cryptogram (ARQC)

This is the digital fingerprint of the transaction. The card uses transaction data and cryptographic keys to generate an Authorization Request Cryptogram (ARQC). This is used for both offline logging and, in online mode, sent to the acquirer/NPCI backend for authorization.

Fare Calculation and Deduction

The kernel either:

• Retrieves fare from a locally stored fare table
• Calculates based on dynamic data (e.g., travel zones, entry/exit time)
• Communicates with a central host (e.g., in postpaid AFC models)
  

Once calculated, the fare is deducted from the card’s offline balance block securely. The transaction is marked as complete only if balance suffices.

 Transaction Logging & Storage

Each transaction is logged securely in the terminal’s memory (and optionally on the card) with:

• Timestamp
  
• Terminal ID
  
• Fare deducted
  
• Card PAN (masked)
  
• Cryptogram details
  

This is used for audit trails and backend reconciliation.

Completion & Post-Processing

Once successful, the terminal may display transaction status to the user, print a receipt, and reset the system to await the next transaction. In offline-first systems, logs are periodically uploaded to the backend for batch processing.

Certification, Compliance & Standards

Ensuring that the NCMC kernel complies with international and Indian standards is non-negotiable. Here’s what’s required:

EMVCo Certification

• Level 1: Ensures that the contactless RF interface complies with ISO/IEC 14443 protocols.
  
• Level 2: Confirms that the kernel accurately follows the EMV specifications for transaction logic, data handling, and cryptographic procedures.
  

NPCI NCMC Kernel Certification

Must pass exhaustive test suites provided by NPCI for:

• • Offline fare logic
    
  • Low-value transaction handling
    
  • Emergency fare wallet rules
  • Blacklisting, error handling, timeout management

Certification is conducted in a staged manner: pre-certification > beta > UAT > production

RBI & IT Security Guidelines

• Terminals must store transaction data securely with encryption at rest
  
• Customer data privacy and masking must be implemented
• KYC compliance for postpaid or linked wallet implementations

Terminals must support OTA security patches and remote audit logging