• fintech
  • Algorithmic Trading & Fintech

QuantLeap: a multi-broker algo trading platform for Indian markets

A multi-broker trading engine on AWS serverless — automated options and equity strategies, executed across four Indian brokers from one platform.

  • Cloud Engineering
  • Serverless Architecture
  • Multi-Broker Execution

At a glance

Sector
Algorithmic Trading & Fintech
Type
fintech
Services
Cloud Engineering · Serverless Architecture · Multi-Broker Execution

The problem

What it had to solve

Retail algorithmic traders in India are trapped between two bad options: either stitch together brittle scripts running on a laptop — with cold-start risk, missed candles, and no failover — or pay institutional vendors a steep monthly fee for closed, inflexible terminals. Multi-leg options strategies such as straddles, strangles, iron condors, opening range breakouts, and wait-and-trigger entries need precise minute-level orchestration, stop-loss monitoring adjusted for circuit limits, and idempotent broker reconciliation that most retail tools simply don't offer.

With F&O participation climbing and execution-audit requirements tightening, traders needed a platform that stayed always-warm, worked across brokers, kept a full audit trail, and was cheap enough to run for a single user — yet could also power a white-label brokerage deployment.

What we built

How it works

We built a cleanly separated cloud architecture that isolates long-lived infrastructure from rapidly-iterating trading logic. Market data and broker calls run on always-warm containerized services behind internal load balancers, eliminating the cold-start penalty that plagues function-only trading stacks. A single API gateway fronts authentication, broker, strategy, orchestration, and marketplace services, while a minimalist React frontend gives traders a control panel for baskets, allocations, positions, and live P&L.

A scheduled event bus fires every trading minute, fanning out to orchestration workers that compute strategy triggers, resolve ATM and OTM strikes, and dispatch orders through the unified broker layer. Stop-losses, wait-and-trigger entries, and opening range breakout strategies are monitored continuously, with circuit-limit-aware re-placement and overnight-gate handling baked in.

Calls we would still defend

  • Always-warm containers on the execution path — broker calls and market data moved off cold-start-prone functions onto container services, with scheduled scaling aligned to Indian market hours — so an order dispatches without waiting on a cold start during a trading session.

  • Loose stack coupling via Parameter Store — replaced dozens of brittle cross-stack exports with parameter-store service discovery, so the trading layer redeploys independently without tearing down foundational resources.

  • Idempotent broker reconciliation — a dedicated sync service handles stuck rejections, partial fills and duplicate order IDs deterministically, so traders never see ghost positions even when brokers return inconsistent state.

  • Multi-broker dispatch layer — a single dictionary-dispatch abstraction hides Zerodha, Angel, Finvasia and Zebu behind one consistent API — a strategy is written once and runs on any of them without code changes.

  • White-label ready — tenant configuration drives branding, landing pages and OAuth flows, so the same codebase powers both a public marketplace and a broker-branded deployment — currently live for Zebu.

Built with

  • AWS CDK (Python)

    A single infrastructure-as-code monorepo orchestrating networking, identity, databases, API gateway, serverless functions, state machines, and containers — deployed via one command per environment.

  • ECS Fargate + Internal ALB

    Always-warm FastAPI services for market data and multi-broker execution, eliminating cold starts on the critical trading path and providing predictable latency during market hours.

  • DynamoDB

    Purpose-built tables with global secondary indexes tuned for the exact query patterns of a live trading engine — user profiles, broker accounts, trading configurations, positions, events, and marketplace listings.

  • EventBridge + Step Functions

    Minute-level event fan-out drives orchestration workflows covering entry, exit, stop-loss, wait-and-trigger, opening range breakout, end-of-day reconciliation, and instrument refresh.

  • React 18 + TypeScript + TailwindCSS

    A responsive frontend with a shared design system, white-label tenant configuration, and automatic token refresh — delivered via S3 and CloudFront for global low-latency access.

  • Cognito + Secrets Manager

    Per-user OAuth token isolation ensures one trader's broker session can never leak into another's execution context, meeting audit and compliance requirements out of the box.

Where it landed

What the build changed

4

Brokers unified

Zerodha, Angel One, Finvasia and Zebu behind one execution API

Per-minute

Orchestration cadence

a scheduled event bus recomputes strategy triggers every trading minute

White-label

Deployment model

one codebase runs a public marketplace and a broker-branded tenant, live for Zebu

FAQ

The questions this build raises

What was actually built, the constraints it had to meet, and how it holds up in use.

  • The broker and market data services run on always-warm containers with scheduled scaling that pre-warms capacity before market open and keeps it warm until after close. Combined with request-based autoscaling and health-checked internal load balancers, the execution path never pays a cold-start penalty during trading hours.

  • A function cold start is unacceptable on the critical trading path — even a second or two of warm-up can mean a missed entry on a fast-moving options leg. Always-warm ECS Fargate services behind an internal load balancer keep dispatch fast and predictable, while the non-execution layers — orchestration, reconciliation, analytics — still run on pay-per-use serverless.

  • The orchestration layer continuously monitors open positions and is circuit-limit-aware: when a stop-loss order is rejected because the underlying has hit the upper or lower circuit, the platform automatically re-places the order at the allowed bound and keeps retrying deterministically until fill, all without operator intervention.

  • Yes. A built-in public strategy marketplace lets authors list their baskets with performance history, and other traders can subscribe and run them against their own broker account through the unified execution layer — so the author monetises the logic without ever touching a subscriber's funds or credentials.

Keep looking

Other builds, taken apart the same way

Want to start a project?