Market-making systems engineered for control and observability.
BitAzure designs and builds the software stack behind liquidity provision: low-latency market-data connectors, quoting engines with spread and inventory logic, hard risk controls, multi-venue hedging and the monitoring and backtesting tools that keep strategies accountable.
- Quoting engine with spread, skew and inventory management
- Pre-trade risk controls, position limits and kill switch
- REST, WebSocket and FIX connectors across venues
- Strategy parameters, backtesting and live monitoring
What is market-making technology?
Market-making technology is the software infrastructure that continuously places and manages two-sided quotes on trading venues: it ingests market data, computes bid and ask prices from a pricing model and inventory state, submits and amends orders through exchange connectors, and enforces risk limits on every decision. It is an engineering system rather than a strategy, and its quality is measured in latency, uptime, correctness and control.
BitAzure builds this stack for exchanges that need to seed liquidity on new markets, token issuers working with liquidity partners, proprietary trading firms and brokers that internalise flow. Delivery covers venue connectivity, the quoting engine, inventory and hedging logic, a strategy configuration and backtesting layer, and operator dashboards with alerting.
We are a software and infrastructure company. We do not manage capital, run strategies on behalf of clients or make representations about trading profitability. Our responsibility is that the system quotes what the strategy intends, stops when limits are hit and gives operators a truthful picture of what happened.
Market-making technology capabilities
Components are modular, so a client can adopt the full stack or integrate individual pieces with existing trading infrastructure.
Market Data & Connectivity
- REST, WebSocket and FIX connectors per venue
- Order-book reconstruction with sequence gap detection
- Normalised market-data schema across venues
- Reference pricing from external and index feeds
- Connection supervision with automatic failover
Quoting Engine
- Two-sided quote generation from a pricing model
- Spread management by volatility, depth and time of day
- Order placement, amendment and cancel-replace logic
- Quote layering and size ladders
- Latency budgets from tick to order
- Replay-safe handling of acknowledgements and rejects
Inventory & Liquidity Management
- Inventory skew that shifts quotes toward a target position
- Per-market liquidity targets and depth obligations
- Multi-venue hedging to offset accumulated inventory
- Cross-market and cross-asset exposure netting
- Funding and borrow awareness for derivatives
Risk Controls
- Position and notional limits per market and per venue
- Loss limits with automatic quote withdrawal
- Kill switch with cancel-all across venues
- Stale-data and price-deviation guards
- Fat-finger and self-trade prevention checks
Strategy Management & Backtesting
- Parameter management with versioning and approvals
- Backtesting against recorded order-book data
- Simulation of fills, fees and latency
- Paper-trading mode on live feeds
- Gradual parameter rollout by market
Monitoring & Operations
- Real-time dashboards for quotes, fills and inventory
- P&L attribution by market, venue and parameter set
- Alerting on latency, rejects and limit proximity
- Audit log of every order decision
- Runbooks for venue outages and degraded modes
Reference market-making system architecture
The reference design keeps market data, pricing, risk and execution as separate processes with explicit latency budgets, so a slow venue or a bad parameter cannot silently affect the others.
Hover or focus a component to see its role in the architecture.
- Trading Venues (CEX · DEX · OTC): Centralised exchanges, on-chain venues and RFQ counterparties, each with distinct APIs, fees and rate limits.
- Market-Data Connectors (WebSocket · REST · FIX): Per-venue adapters that reconstruct order books, detect sequence gaps and publish a normalised feed.
- Execution Connectors (Order routing): Place, amend and cancel orders with venue-specific throttling and acknowledgement tracking.
- Quoting Engine (Fair value · spread · skew): Computes two-sided quotes from reference prices, volatility, depth and inventory, within a tick-to-order latency budget.
- Risk Controls (Limits · kill switch): Pre-trade checks on position, notional and loss limits; independent cancel-all path if the engine misbehaves.
- Hedging Service (Multi-venue): Offsets inventory beyond thresholds on other venues or instruments according to configured rules.
- Strategy & Backtest (Parameters · simulation): Versioned parameter sets with approvals, replayed against recorded books before going live.
- Monitoring (Dashboards · alerts): Live view of quotes, fills, inventory and P&L attribution with alerts on latency and limit proximity.
- Data Stores (ClickHouse · Redis): Recorded market data, order and fill history, and hot state for reconciliation and analysis.
Connectivity
- Venue adapters
- Book reconstruction
- Failover and supervision
Pricing & quoting
- Fair-value model
- Spread and skew
- Quote lifecycle
Risk & hedging
- Limits and kill switch
- Inventory targets
- Cross-venue hedging
Strategy & operations
- Parameter versioning
- Backtesting
- Dashboards and alerts
Where market-making technology is used
Exchange liquidity programmes
Exchanges seeding depth on new listings with designated market-maker tooling.
Token issuer liquidity
Projects running or overseeing liquidity on centralised and decentralised venues.
Proprietary trading desks
Firms replacing ad-hoc scripts with a supervised, multi-venue quoting stack.
Brokers internalising flow
Brokers quoting to clients and hedging residual exposure across venues.
DEX liquidity management
Active management of concentrated liquidity positions and on-chain RFQ responders.
OTC and RFQ desks
Automated pricing and hedging for request-for-quote workflows.
Why trading teams build with BitAzure
Deterministic risk enforcement
Limits are checked in the execution path, so no quote reaches a venue without passing them.
Latency-conscious design
Hot paths in Rust or C++ with measured tick-to-order budgets and no hidden allocations.
Venue isolation
Connector faults, rate limits and outages are contained without affecting other markets.
Backtesting fidelity
Simulations replay recorded books with fee and latency models so parameters are tested before they go live.
Operational transparency
Every decision, reject and limit event is visible to operators in real time and in the audit log.
Full code ownership
Clients receive the source, infrastructure definitions and documentation for the whole stack.
Technologies we use for market-making systems
Rust
BackendMemory-safe, low-latency engines, on-chain programs and tooling.
C++
BackendUltra-low-latency components in matching and market-data paths.
Go
BackendConcurrent network services, relayers and infrastructure daemons.
Python
BackendData pipelines, quant research tooling and AI services.
Kafka
DatabaseDurable event streaming between engines and services.
Redis
DatabaseCaching, sessions, rate limiting, pub/sub and order-book snapshots.
ClickHouse
DatabaseColumnar analytics for trade history and market data.
PostgreSQL
DatabaseTransactional ledgers, ledgers-of-record and analytical workloads.
Kubernetes
InfrastructureAutoscaling, rolling deployments and workload isolation.
Prometheus / Grafana
InfrastructureMetrics, dashboards and alerting for every service.
TypeScript
FrontendStrict typing across the entire stack, client to contracts tooling.
React
FrontendComponent-driven UIs for dashboards, exchanges and wallets.
How we deliver market-making technology
Every engagement follows a documented, milestone-driven path from discovery to continuous development.
- 01
Venue and market scoping
Identify venues, instruments, connectivity options and the obligations (depth, uptime, spread) the system must meet.
- 02
Architecture and latency budget
Define process boundaries, data schemas, risk-check placement and target latencies for each path.
- 03
Connectors and data recording
Build and certify venue connectors, reconstruct order books and start recording data for backtesting.
- 04
Engine, risk and hedging build
Implement the quoting engine, limit checks, kill switch and hedging logic with deterministic replay tests.
- 05
Simulation and controlled go-live
Validate parameters in backtests and paper trading, then enable markets progressively with tight limits.
- 06
Operations and iteration
Monitoring, on-call support and continued development of strategies, venues and tooling.
Security practices in market-making systems
Venue credential isolation
API keys and FIX credentials held in a secrets manager with per-venue, least-privilege scopes.
Kill switch architecture
An independent process that can cancel all orders across venues even if the engine is unresponsive.
Parameter change control
Versioned parameters with approval and rollback so a bad configuration cannot be applied silently.
Network hardening
Private connectivity to venues where available, allow-listed egress and mutual TLS between components.
Continuous reconciliation
Positions and balances reconciled with venues continuously to catch drift and missed fills.
Access and audit
Role-based operator access with a tamper-evident log of every manual action.
We coordinate independent third-party audits on request and never claim an audit, certification or compliance status unless it has actually been obtained.
What to decide before building a market-making stack
Latency versus control
Colocated, single-process designs are faster; separated risk checks add microseconds but make limits enforceable. Decide where the boundary sits.
Inventory policy
Target inventory, skew aggressiveness and hedge thresholds define the risk profile more than the spread formula does.
Venue behaviour
Rate limits, cancel penalties, maker rebates and downtime differ by venue and must be modelled in the engine.
Adverse selection
Quoting during news or thin liquidity exposes the system to informed flow; stale-data guards and widening rules are essential.
Regulatory obligations
Designated market-maker agreements and local rules may impose quoting, reporting and record-keeping duties.
Capital and operations
The technology is one input; capital, treasury management and on-call coverage determine whether a programme is viable.
Market-Making Technology questions
No. BitAzure builds and supports the software and infrastructure. Clients run the strategies with their own capital, parameters and operational oversight. We make no claims about trading results.
Building a liquidity provision stack?
Describe your venues, instruments and control requirements. We will propose an architecture with latency budgets and a phased delivery plan.