Hrithik.Fix.Protocol 1.0.0

Hrithik.Fix.Protocol

Hrithik.Fix.Protocol is a production-grade FIX message construction and outbound protocol library for .NET.

It allows clients to send JSON-based requests that are dynamically converted into valid FIX messages, validated against official FIX dictionaries, and sent via a pluggable transport (e.g. QuickFIX).

This package focuses strictly on FIX message creation and outbound sending. It does NOT manage FIX sessions or inbound FIX business messages.

✨ Key Features

✅ JSON → FIX message conversion (dynamic fields)

✅ Supports NEW / CANCEL / MODIFY orders

✅ FIX 4.4 / FIX 5.0 dictionary validation

✅ Required field & type validation

✅ Automatic FIX fields (e.g. TransactTime)

✅ Protocol-level security hooks (replay protection, signing)

✅ Transport-agnostic design via interfaces

✅ Clean separation of protocol vs session lifecycle

❌ What This Package Does NOT Do

To keep the library reusable and production-safe, the following are intentionally out of scope:

❌ FIX session lifecycle (logon, logout, heartbeats)

❌ TCP / socket management

❌ Host / port configuration

❌ Inbound FIX message handling (ExecutionReports, Rejects)

❌ Trading / order state management

❌ Venue-specific business rules

These responsibilities belong in the application layer (e.g. a FIX Gateway or API).

🧠 Architecture Overview Client JSON ↓ Hrithik.Fix.Protocol

• Mapping
• Validation
• Security
• FIX message creation ↓ IFixSender (abstraction) ↓ Application Layer (e.g. QuickFIX) ↓ FIX Session / Venue (FiX, Exchange, Broker)

📦 Installation dotnet add package Hrithik.Fix.Protocol

🚀 Quick Start 1️⃣ Register FIX Protocol Services services.AddFixProtocol(options ⇒ { options.FixVersion = FixVersion.Fix44; options.EnableReplayProtection = false; });

2️⃣ Provide a Transport (Sender)

The package requires an implementation of IFixSender.

Example using QuickFIX (managed in your application, not this package):

services.AddSingleton<IFixSender>( sp ⇒ new QuickFixSender(sessionId));

The transport implementation is responsible for:

Knowing whether the FIX session is logged on

Knowing host/port

Sending messages over the wire

3️⃣ Send an Order var request = new FixOrderRequest { OrderType = "NEW", Fields = new Dictionary<string, object> { ["ClOrdID"] = "order-123", ["Symbol"] = "AAPL", ["Side"] = "1", ["OrderQty"] = 10, ["OrdType"] = "1", ["TimeInForce"] = "0" } };

await fixProtocolClient.SendAsync(request);

📄 Example JSON Request { "orderType": "NEW", "fields": { "ClOrdID": "order-123", "Symbol": "AAPL", "Side": "1", "OrderQty": 10, "OrdType": "1", "TimeInForce": "0" } }

🧪 Validation Behavior

The library validates:

✔ MsgType exists in FIX dictionary

✔ Required FIX fields are present

✔ All fields exist in the FIX dictionary

✔ Field types are valid

It does not enforce:

Message-component placement

Venue-specific rules

This mirrors how real FIX engines behave in production.

🔌 Transport Abstraction public interface IFixSender { Task<FixSendResult> SendAsync(FixMessage message); }

This allows:

QuickFIX

Custom FIX engines

Mock senders for testing

🔐 Security & Observability

Optional protocol-level features:

Replay protection

Request signing

Correlation IDs

Logging hooks

These are orthogonal to FIX session handling.

🏗 Recommended Usage Pattern

Library (Hrithik.Fix.Protocol)

Message creation

Validation

Outbound send abstraction

Gateway / API Project

QuickFIX configuration

Session lifecycle

Inbound FIX message handling

Persistence, webhooks, APIs

📌 Design Principles

Clean Architecture

Dependency Inversion

FIX-standard aligned

Venue-agnostic

Production-first

📄 License

MIT License

👤 Author

Hrithik Kalra

📧 Email: hrithikkalra11@gmail.com

If you find this package useful, consider supporting its development:

• ☕ Buy Me a Coffee: https://www.buymeacoffee.com/alkylhalid9
• ❤️ GitHub Sponsors: https://github.com/sponsors/hrithikalra

Support is entirely optional and helps sustain ongoing development and maintenance.

🔗 Other Related Packages used in security

This package is part of the Hrithik.Security ecosystem:

• Hrithik.Security.ApiKeyManagement
  API key generation, storage, and scope-based authorization

• Hrithik.Security.RequestSigning
  HMAC-based request signing for tamper-proof APIs

• Hrithik.Security.ReplayProtection
  Short-window replay attack prevention

• Hrithik.Security.RateLimiting
  Flexible, API-key–aware rate limiting for ASP.NET Core APIs

• Hrithik.Security.Idempotency Exactly-once request processing using client-supplied or server-generated keys

• Hrithik.Security.Jose JOSE (JWS/JWE) utilities for signing, verification, and optional encryption of JSON payloads

These packages are independent and can be used together or individually.