NEAT (National Exchange for Automated Trading)

Overview & History: NEAT is the core trading engine of India’s NSE, initially used by BSE. Launched in the early 1990s, it was India’s first fully electronic matching engine, transitioning markets from floor to electronic trading. NEAT evolved into variants like NEATPlus, NEAT-CM (equities), NEAT-F&O (futures & options), and NEAT-CD (FX). It’s a back-end system for order matching, not user-facing, prioritizing high throughput, sub-millisecond execution, and 99.999% uptime.

Architecture & Technology: NEAT uses a 3-tier in-memory architecture with scalable subsystems. Orders flow through accumulators, a Risk Management System (RMS), the matching engine, and dissemination servers for market data. It runs on Stratus fault-tolerant servers with TCP/IP networking. Low latency is achieved via in-memory databases and fast connections (leased lines, satellite, internet). Trades are batched into “ticks” by a Primary Data Server (PDC) and sent via Tick-by-Tick (TBT) or snapshot feeds, using multicast since 2016 (previously TCP).

Front-Ends & APIs: NEAT provides trading front-ends (NEAT/NEATPlus) for dealers’ PCs, supporting equities and F&O. Brokers can develop Non-NEAT Front-End (NNF) applications, connecting via Computer-to-Computer Link (CTCL) using NEAT Adapter middleware or direct TCP (“trimmed protocol”) sockets. The protocol defines packet structures for order entry, cancellation, confirmation, and market data, with separate versions for equities, F&O, currency, and commodities.

Programming Languages & Frameworks: NEAT’s proprietary core likely uses C/C++ on Stratus. Front-ends/NNF apps can use any TCP/IP-supporting language, often Windows-based (VB/C++ or vendor apps like ODIN). NEATPlus and NEAT Combo are native Win32 apps (likely Visual C++), but details are undisclosed. No public NEAT API exists beyond protocol specs.

Integration (OMS/RMS, Connectivity): NEAT integrates with brokers’ Order Management Systems (OMS) and Risk Management Systems (RMS). Orders pass through broker OMS/RMS for checks (limits, margins), then via CTCL to NEAT, which applies exchange-level risk checks and matches trades. Confirmations return through CTCL to the OMS and front-end. Market data flows separately from NEAT to brokers or vendors.

Trade Flow Example: A dealer using NEATPlus enters a buy order for 100 equity shares. The order hits NEAT’s Order Gateway, passes RMS checks, and enters the order book. If matched, trade details are sent to the PDC, bundled into a tick, and disseminated to members. The broker’s back-office updates the client’s position, and the dealer sees the fill. Institutional flows may use FIX, converted to NEAT protocol by brokers.

Key Features & Use-Cases:

  • Supported Segments: Equities, F&O, currency futures, and more across NSE.
  • User Base: All NSE trading members (retail, institutional, HFT).
  • Performance: Millions of orders/day, <1 ms latency, 99.999% uptime.
  • Customization: Limited; clients adapt to protocols or use standard front-ends.
  • Compliance: Meets SEBI rules with auto-risk checks (SPAN margin, RMS).

Pros: Reliable, fast, fully electronic, low-latency in-memory architecture, global connectivity (VSAT/leased/internet), open for custom front-ends via CTCL.
Cons: Proprietary, opaque matching logic, rigid protocols for non-NEAT front-ends, steep learning curve for legacy GUIs (improved in NEATPlus).

Adoption & Trends: Dominant on NSE since 1994, NEAT continues with upgrades (e.g., multicast data since 2016). NSE encourages custom front-ends and algorithmic engines via CTCL. Future plans include transitioning to advanced matching engines, but NEAT remains critical.

NOW (NEAT on Web)

Overview & History: NOW, launched around 2000, is NSE’s free internet-based trading portal for members and clients. It enabled early online trading, especially for small brokerages, with startups like Zerodha initially relying on it.

Architecture & Technology: NOW is a web/terminal front-end connecting to NEAT. Clients access it via internet or members’ VSAT/leased lines, using a secure NSE network. The interface, originally Windows-based, may now include HTML5 or thick-client apps. It integrates NSE’s RMS, offering risk management, high-speed terminals, and online trading.

Languages & Frameworks: NOW’s internals are proprietary (likely C/C++ or Java for early versions). Its planned replacement, NSE NOW NEXT (web portal), was shelved. Modern versions likely use standard web tech (.NET or Java) server-side, with an installed app or web UI client.

Integration: NOW connects to NEAT like other front-ends, using CTCL/NEAT Adapter. Orders entered in NOW flow to NEAT, with fills and positions returned to the interface. NOW covers only NSE markets, requiring separate access for BSE. It includes order routing, risk checks, and basic back-office reporting, with a single shared connection per member.

Trade Flow Example: A client on a small broker’s NOW portal places an order via the website/app. It reaches NSE servers, enters NEAT, and is processed like a terminal order. Fills return to the NOW interface, and the broker’s back-office downloads reports. Larger brokers using custom front-ends (e.g., Omnesys NEST) support multi-exchange trading, unlike NOW’s NSE-only scope.

Key Features & Use-Cases:

  • Target Users: Small/medium brokers avoiding custom platforms; startups like Zerodha used it initially.
  • Assets: NSE equities, derivatives, currency futures.
  • Advantages: Free, easy setup, includes RMS and admin tools.
  • Limitations: NSE-only, lacks advanced features (bracket orders, algos), limited back-office integration, single shared connection.

Pros: Free, reliable, no development needed for new brokers.
Cons: Limited to NSE, outdated interface, minimal customization, phased out for modern platforms (discontinued for new activations ~2017).

Adoption & Trends: NOW was popular around 2010 for new brokers but declined as firms adopted multi-exchange platforms (e.g., Omnesys NEST, ODIN). NSE restricted new NOW users by the mid-2010s, and only legacy users remain. Modern trading uses broker-built front-ends or APIs.

Omnesys NEST (Broker OMS/EMS)

Overview & History: Omnesys NEST (now OmneNEST) is a leading broker trading platform in India, developed by Omnesys Technologies. Acquired by Thomson Reuters in 2013, it later joined Refinitiv (LSEG). In 2023, the original team reformed as OmneNEST Technologies, backed by Zerodha’s founders. NEST serves hundreds of brokers, holding ~20% market share (with ODIN at ~80%).

Architecture & Technology: NEST is a high-throughput, Linux-based client-server system. Its multi-tier architecture includes a low-latency core connecting to exchange gateways, with broker-hosted servers linking to front-end clients. Likely using C++ for core functions, it supports exchange protocols (NSE CTCL, BSE BOLT).

APIs and Languages: NEST offers APIs (REST, C++, Java, .NET) for custom front-ends and integrations, covering order entry, market data, and reports. It supports streaming updates and is likely C/C++ internally, using TCP/IP messaging.

Integration (OMS/RMS, Connectivity): NEST is a complete OMS/EMS, handling order routing, risk management, and back-office functions. It connects to exchanges via CTCL/FIX and includes an RMS for margins and exposure checks. NEST integrates with back-office systems, depositories, and third-party services (SMS, payment gateways), supporting single sign-on.

Trade Flow Example: A Zerodha trader clicks “Buy” in Kite (built on NEST). The order hits NEST’s API, undergoes RMS checks, and is sent via CTCL to NEAT. NEAT confirms the trade, NEST updates the trader’s status, and the fill appears in Kite. Market data from exchanges flows through NEST to client UIs.

Key Features & Use-Cases:

  • Multi-asset, Multi-exchange: Equities, derivatives, currency, commodities, mutual funds across Indian exchanges.
  • Algorithmic Trading: NEST Strategies supports custom algos (pair trades, multi-leg options).
  • Scalability: Handles high volumes, supports co-location.
  • Use by Segments: Retail, institutional, HNI desks, and exchange front-ends.

Pros: Feature-rich, customizable, built-in OMS/RMS, plug-and-play modules (alerts, charting).
Cons: Proprietary, licensing costs, complex customization, uncertain updates post-ownership changes.

Adoption & Trends: Widely used by brokers like Zerodha, 5Paisa, and SBICAP, NEST regained focus under OmneNEST in 2023. It evolves with new APIs and cloud offerings, remaining a top choice for Indian brokerages.

Refinitiv (Thomson Reuters / LSEG Trading Platform)

Overview & History: Refinitiv, formerly Thomson Reuters’ financial arm, is now part of LSEG. In India, it’s known for Eikon workstations, data feeds, and trading tools like REDI EMS and FXall. Omnesys NEST was under Refinitiv (2013–2023). Eikon is evolving into LSEG Workspace.

Architecture & Technology: Refinitiv’s global, cross-asset stack includes REDI EMS (Java/.NET thick-client) for multi-broker trading and Elektron for market data. It uses FIX/proprietary links and APIs (WebSocket, Python, C++). Back-ends run on server farms, with secure client connections.

APIs and Languages:

  • Refinitiv Data Platform (RDP): REST/WebSocket for data (Python, Java, C#).
  • Eikon/Workspace: COM/REST for Excel/custom apps.
  • REDI: COM/C++ SDK for order management.
  • FIX: Used internally for orders/feeds.

Integration (OMS/RMS, Connectivity): Refinitiv tools serve clients, not exchanges. Eikon/Workspace GUIs connect to REDI or in-house OMS. REDI routes orders to brokers, integrating news and data. LSEG is merging REDI into TORA by 2025.

Trade Flow Example: A trader on REDI EMS sends an order via FIX to a broker (e.g., Citibank), which routes it to NSE via CTCL. Fills return through FIX to REDI. Market data from Refinitiv’s Streaming Service updates REDI/Eikon GUIs.

Key Features & Use-Cases:

  • Products: REDI EMS, FXall, Eikon/Elektron data, analytics.
  • Assets: Global equities, FX, fixed income, derivatives.
  • Clients: Institutional investors, sell-side firms, wealth managers.
  • Workflow: Integrates data, trading, and compliance.

Pros: Comprehensive ecosystem, global connectivity, high-end analytics.
Cons: Expensive, complex, REDI retiring by 2025, overkill for small brokers.

Adoption & Trends: Eikon is widely used by Indian institutions; REDI less so. LSEG’s shift to TORA and Workspace continues, with Refinitiv’s influence stronger in institutional and global segments.

FIX API (Financial Information eXchange Protocol)

Overview & History: FIX, started in 1992, is a global messaging standard for electronic trading, maintained by the FIX Trading Community. Evolving from ASCII to binary (FAST), it supports equities, futures, FX, and more.

Technical Architecture: FIX operates over TCP/IP as a persistent socket connection. FIX engines (QuickFIX, Onixs, proprietary) handle messages (login, order, execution reports). It supports point-to-point or many-to-one flows, often unicast.

Integration & Use: NSE adopted FIX 4.2 in 2010 for FIIs. Brokers like Morgan Stanley and Zerodha offer FIX APIs for institutional/algo traders. FIX connects OMS to exchange gateways or brokers internally.

Trade Flow Example: An FII’s algo sends a FIX NewOrderSingle to a broker’s FIX gateway, which maps it to NEAT for NSE. Fills return via FIX. Alternatively, a trading bot uses a FIX library to send orders directly to a broker’s API.

Key Features & Use-Cases:

  • Standard: Universal across asset classes.
  • Control: Enables custom algo logic, HFT.
  • Connectivity: Links global and domestic systems.
  • Languages: C++, Java, C#, Python (QuickFIX, commercial engines).

Pros: Standardized, flexible, supports STP, essential for algos.
Cons: Complex, verbose, requires expertise, broker-specific variations.

Adoption & Trends: FIX is standard in Indian institutional trading, with NSE supporting higher versions (FIX 5.0, FAST). Binary FIX and newer standards (FASTFIX, FIXP) are emerging.

Comparison of Platforms

Feature/Stack

NEAT (NSE Core)

NOW (NSE Web)

Omnesys NEST

Refinitiv (LSEG)

Type

Exchange matching engine

Exchange web front-end

Vendor OMS/EMS

Vendor data/trading suite

Introduced

1992

~2000

~2006

1990s (current)

Provider

NSE India

NSE India

OmneNEST

Refinitiv (LSEG)

Architecture

Stratus servers, in-memory DB, TCP/IP

Web/desktop client, internet

Linux-based, multi-tier, API layers

Enterprise client-server, cloud APIs

Front-End

NEAT/NEATPlus (Windows)

NOW web/desktop UI

NEST GUI, custom via API

Eikon/Workspace, custom apps

Connectivity

TCP/IP (VSAT/leased/internet)

Internet (TCP)

CTCL/FIX, REST/WebSocket

FIX, REST, proprietary

Markets

NSE: Equities, F&O, Currency, Debt

NSE-only

Multi-exchange/asset

Global multi-asset

Order Entry API

NEAT protocol

NOW web API

REST, C++, Java, .NET

FIX, Redi API

Data Feed

TBT (multicast/TCP), L2 snapshot

Via portal

NSE/BSE via NEST

Elektron, Eikon Streaming

RMS/Margin

Exchange-level (SPAN)

Exchange RMS

Built-in broker RMS

Pre-trade risk (broker-integrated)

User Base

NSE members

Small brokers, clients

Retail/institutional brokers

Institutional traders

Use Cases

All NSE trading

Online NSE trading

Broker trading, algos

Global trading, data

Pros

Reliable, low latency

Free, easy

Feature-rich, customizable

Comprehensive ecosystem

Cons

Proprietary, legacy UI

NSE-only, outdated

Licensing, complexity

Expensive, REDI retiring

Current  Trend

Upgrades to faster engine

Phased out

Leader under OmneNEST

REDI→TORA, Workspace


System Interactions

A trader’s order via a broker’s front-end (e.g., Zerodha’s Kite on NEST) hits the NEST OMS, which sends it via CTCL/FIX to NEAT. NEAT matches the order and returns confirmations through NEST to the UI. Market data streams from NEAT to the broker’s systems and trader’s screen. Refinitiv may provide global data, with FIX used for institutional routing.

Example (Zerodha): A Kite order hits NEST’s REST API, converts to NEAT protocol, and reaches NSE. Confirmations return via NEST to Kite. BSE orders use similar BSE protocols, with combined positions shown.

Network: NEAT uses VSAT/leased lines; NOW/NEST use internet or private links. NSE supports FIX for DMA, and co-location is common for speed.

Who Uses What

  • Startups/Small Brokers: Start with NOW, then NEST/ODIN or SaaS OMS, possibly FIX for algos.
  • Mid-size Brokers: Use NEST for RMS/multi-asset, Refinitiv data, occasional FIX.
  • Large Brokers/Institutions: Run NEST/ODIN for retail, proprietary OMS or REDI for institutional, with FIX and Refinitiv analytics.
  • Algo Traders/HFT: Use FIX, co-located engines, raw feeds, sometimes NEST/REDI.
  • Banks/FIIs: Refinitiv (Eikon/REDI), FIX to local brokers, in-house OMS.
  • Retail Traders: See broker front-ends (often NEST-based).