DEV Community: Sergiy Lutsak

Measuring Latency in .NET Without Fooling Yourself: Stopwatch, Percentiles and Coordinated Omission

Sergiy Lutsak — Tue, 29 Sep 2026 18:20:12 +0000

description: "Why the mean hides your worst latency, how to record percentiles without allocating, and how a test loop can under-report a one-second freeze by a factor of 900. Runnable C#."
tags: csharp, dotnet, performance, fintech

series: "Low-Latency Trading Infrastructure in C#"

"Sub-millisecond" is the most common number in trading software marketing, mine included. It is usually true and it usually answers a question nobody asked. The interesting questions are: sub-millisecond for which interval, measured with which clock, and what happens in the worst one request in a thousand?

Part 1 of this series ended with a quick benchmark loop. This part is about doing that properly: a clock you can trust, a histogram that costs nothing to record into, and the measurement mistake that makes almost every home-made latency test look better than reality.

Disclosure: I build trading infrastructure at HFT Software, including HFT Forex Copier and HFT Arbitrage Platform. Both are judged by their tails, not their averages, which is why I care.

Everything below is plain C# 7 with no packages and runs on .NET Framework 4.8 and current .NET.

Use the right clock

DateTime.UtcNow is a wall clock. It can jump when the system time is adjusted, and on Windows its effective resolution has historically been far coarser than the code you are timing. It is the right tool for timestamps you show to humans and the wrong tool for intervals.

Stopwatch wraps the monotonic high-resolution counter of the platform. Use the static GetTimestamp() so that timing does not allocate a Stopwatch object per measurement:

using System;
using System.Diagnostics;
using System.Globalization;
using System.Text;

public static class Clock
{
    static readonly double NsPerTick = 1e9 / Stopwatch.Frequency;

    public static long Now() { return Stopwatch.GetTimestamp(); }

    public static long ElapsedNs(long startTicks)
    {
        return (long)((Stopwatch.GetTimestamp() - startTicks) * NsPerTick);
    }
}

Check Stopwatch.IsHighResolution once at start-up. If it is false you are on a fallback timer and nothing below means much.

One boundary to respect: a monotonic counter is only comparable with itself on the same machine. The moment you subtract a timestamp taken on another host, you are measuring clock synchronisation error, which over the public Internet is milliseconds. I come back to this at the end.

Stop averaging

Latency distributions are not bell curves. They have a tight body and a long tail, and the tail is where timeouts, missed fills and angry users live. The mean blends the two into a number that describes neither. Report percentiles: p50 for the typical case, p99 and p99.9 for the tail, and the maximum.

Keeping every sample in a list to sort later works in a benchmark and is a bad idea in a live system, because it allocates and grows. A histogram with logarithmic buckets gives you percentiles at a fixed memory cost and a known relative error. This one uses 32 linear sub-buckets per power of two, which keeps the error around 3%:

// Log-linear buckets: 32 linear sub-buckets per power of two, so any value is
// recorded with a relative error of about 3%. Record() never allocates.
public sealed class LatencyHistogram
{
    const int SubBits = 5;
    const int SubCount = 1 << SubBits;
    readonly long[] _counts = new long[64 * SubCount];
    long _total, _max;
    double _sum;

    public long Count { get { return _total; } }
    public long Max { get { return _max; } }
    public double Mean { get { return _total == 0 ? 0 : _sum / _total; } }

    public void Record(long valueNs)
    {
        if (valueNs < 0) valueNs = 0;
        _counts[IndexOf(valueNs)]++;
        _total++;
        _sum += valueNs;
        if (valueNs > _max) _max = valueNs;
    }

    public long Percentile(double p)
    {
        long rank = (long)Math.Ceiling(p / 100.0 * _total - 1e-9);
        if (rank < 1) rank = 1;
        long seen = 0;
        for (int i = 0; i < _counts.Length; i++)
        {
            seen += _counts[i];
            if (seen >= rank) return Math.Min(UpperBoundOf(i), _max);
        }
        return _max;
    }

    static int IndexOf(long v)
    {
        if (v < SubCount) return (int)v;
        int msb = 0;
        for (long t = v; (t >>= 1) != 0;) msb++;      // on .NET Core 3.0+ use BitOperations.Log2
        int shift = msb - SubBits;
        return ((shift + 1) << SubBits) + (int)((v >> shift) - SubCount);
    }

    static long UpperBoundOf(int index)
    {
        if (index < SubCount) return index;
        int shift = (index >> SubBits) - 1;
        long sub = (index & (SubCount - 1)) + SubCount;
        return ((sub + 1) << shift) - 1;
    }

    // unitNs: 1e3 to print microseconds, 1e6 to print milliseconds
    public string Summary(string name, double unitNs, string unit)
    {
        return string.Format(CultureInfo.InvariantCulture,
            "{0,-10} mean={1,8:F2} p50={2,8:F2} p90={3,8:F2} p99={4,8:F2} p99.9={5,8:F2} max={6,8:F2} {7}",
            name, Mean / unitNs, Percentile(50) / unitNs, Percentile(90) / unitNs,
            Percentile(99) / unitNs, Percentile(99.9) / unitNs, _max / unitNs, unit);
    }
}

Record is an array increment and two additions. It never allocates, so you can leave it in production code paths. This is a deliberately small cousin of HdrHistogram, which you should use if you need configurable precision, merging or serialisation.

One consequence of bucketing: reported percentiles are bucket upper bounds. A true 1.00 ms shows up as 1.02 ms. That is the 3% at work, not a bug.

Measuring real code

Here is the pattern for timing a piece of code, using a deliberately allocation-heavy workload that resembles a naive string-based message parser:

public static class LiveMeasurement
{
    public static void Run()
    {
        var hist = new LatencyHistogram();
        var sb = new StringBuilder();
        const int N = 200000;

        for (int i = 0; i < 20000; i++) Work(sb, i);              // warm-up: JIT, caches

        int gen0 = GC.CollectionCount(0), gen2 = GC.CollectionCount(2);
        for (int i = 0; i < N; i++)
        {
            long t0 = Clock.Now();
            Work(sb, i);
            hist.Record(Clock.ElapsedNs(t0));
        }

        Console.WriteLine("high resolution clock: " + Stopwatch.IsHighResolution
            + ", tick = " + (1e9 / Stopwatch.Frequency).ToString("F0", CultureInfo.InvariantCulture) + " ns");
        Console.WriteLine(hist.Summary("work", 1e3, "us"));
        Console.WriteLine("gen0 collections: " + (GC.CollectionCount(0) - gen0)
            + ", gen2 collections: " + (GC.CollectionCount(2) - gen2));
    }

    // Deliberately allocation-heavy, like a string-based message builder.
    static int Work(StringBuilder sb, int i)
    {
        sb.Length = 0;
        sb.Append("35=D|11=ORD-").Append(i).Append("|55=EUR/USD|54=1|38=100000|40=1|59=3|");
        string s = sb.ToString();
        string[] parts = s.Split('|');
        return parts.Length;
    }
}

I am not going to print my numbers, because they describe my machine and not yours. Run it. The shape you will see is the same everywhere: the mean and the median sit close together, p99.9 is an order of magnitude above them, and the maximum is one or two orders above that. Then look at the gen0 count. A large part of that tail is the garbage collector, and the mean told you nothing about it.

Three habits that make these numbers honest:

Warm up before measuring. The first thousand iterations include JIT compilation and cold caches.
Print GC collection counts next to every latency result. A tail without its GC count is half a measurement.
Measure in a Release build, without a debugger attached.

Coordinated omission: how a test loop hides a one-second freeze

Now the mistake that matters most. Gil Tene named it coordinated omission, and nearly every hand-written load test commits it.

A typical test sends a request, waits for the reply, records the time, and sends the next one. Suppose the system freezes for a full second. The test is blocked inside that one request, so it records one slow sample. The hundred requests it should have sent during that second are never sent. When the freeze ends, the loop resumes and records fast samples again. The test has coordinated with the system to omit exactly the measurements that would have looked bad.

A real client does not wait politely. Orders, ticks and user clicks arrive on their own schedule, and every one that arrives during the freeze experiences it.

This is easy to demonstrate without any real waiting, by simulating the system in virtual time. The plan is one request every 10 ms for ten seconds. The system answers in 1 ms, except that five seconds in it freezes for one second. We record each request twice: from the moment it was actually sent, and from the moment it was supposed to be sent.

public static class CoordinatedOmission
{
    public static void Run()
    {
        const long Ms = 1000000;                  // nanoseconds in a millisecond
        const long interval = 10 * Ms;            // plan: one request every 10 ms (100 per second)
        const long service = 1 * Ms;              // the system normally answers in 1 ms
        const long stallAt = 5000 * Ms;           // five seconds in, it freezes...
        const long stall = 1000 * Ms;             // ...for one second
        const int requests = 1000;                // ten seconds of load

        var naive = new LatencyHistogram();
        var corrected = new LatencyHistogram();
        long freeAt = 0;
        bool stalled = false;

        for (int i = 0; i < requests; i++)
        {
            long intended = i * interval;                 // when the request SHOULD have been sent
            long start = Math.Max(intended, freeAt);      // a blocking tester cannot send earlier
            long cost = service;
            if (!stalled && start >= stallAt) { cost += stall; stalled = true; }
            long finish = start + cost;
            freeAt = finish;

            naive.Record(finish - start);                 // what most test loops measure
            corrected.Record(finish - intended);          // what a real client experiences
        }

        Console.WriteLine(naive.Summary("naive", 1e6, "ms"));
        Console.WriteLine(corrected.Summary("corrected", 1e6, "ms"));
    }
}

public static class Program
{
    public static void Main(string[] args)
    {
        if (args.Length > 0 && args[0] == "live") LiveMeasurement.Run();
        else CoordinatedOmission.Run();
    }
}

The simulation is deterministic, so you will get exactly this output:

naive      mean=    2.00 p50=    1.02 p90=    1.02 p99=    1.02 p99.9=    1.02 max= 1001.00 ms
corrected  mean=   57.06 p50=    1.02 p90=  102.76 p99=  922.75 p99.9= 1001.00 max= 1001.00 ms

Same system, same second of trouble, two very different reports:

The naive measurement says p99.9 is 1 ms. One sample in a thousand was slow, and it only shows up as the maximum.
The corrected measurement says p90 is about 100 ms and p99 is over 900 ms. In fact 112 of the 1,000 requests were delayed, because the backlog that built up during the freeze took time to drain.
The naive p99 is low by a factor of roughly 900. Even the means differ by a factor of 28: 2 ms against 57 ms.

The fix is in the last line of the loop: measure from the intended send time, not the actual one. If your load generator cannot do that, it is measuring its own politeness.

What this means for a trading path

In an order path the same discipline looks like this:

Decide which interval you are quoting. Time inside your own process, from event detected to bytes written to the socket, is one thing. Time from the master fill to the follower fill is another, and it is dominated by the network and the receiving broker. I split that second interval into six measurable components in a recent working paper, Trade Replication Latency in Retail Foreign Exchange, together with a reporting checklist.
Use Stopwatch timestamps for everything that happens on one host. For anything that crosses hosts, use the broker's own timestamps (52 and 60 in FIX) and state the clock error you are living with.
Record into a histogram on the live path, not only in the lab. Market open and news releases are when the tail appears.
Feed the test at a fixed rate that does not depend on responses, or correct for it as above.

If you want to see what such a breakdown looks like from the user side, our interactive copier simulator shows copier time and round trip separately for local and cloud routing. For why a few milliseconds decide whether a strategy exists at all, the numbers in our latency arbitrage software guide are a good illustration. And FIX API Terminal has a sober page on what low latency FIX trading does and does not depend on: mostly the broker, the network and where you host.

Checklist

Stopwatch.GetTimestamp() for intervals, never DateTime.
Never compare monotonic timestamps across machines.
Warm up, Release build, no debugger.
Histogram, not a list. Percentiles, not the mean.
Always report p99, p99.9, max and the GC counts together.
Drive load at a fixed rate and measure from the intended send time.
Say which interval the number covers.

I am Sergiy Lutsak (I also publish as Sergey Luts). I have been building high-frequency trading systems since 2000. More about my work: author page.

This article is about software engineering. It is not investment advice, and trading leveraged products carries a high risk of loss.

FIX Session Layer in C#: Logon, Heartbeats, Sequence Numbers and Resend

Sergiy Lutsak — Wed, 23 Sep 2026 13:48:51 +0000

In part 1 we built a FIX 4.4 order by hand, framed a TCP stream and parsed an ExecutionReport. That is enough to understand a log file. It is not enough to stay connected: send that order to a real broker without a session around it and you get silence, then a dropped socket.

The session layer is everything that is not about trading: who we are, are you still there, which message number are we on, and what did I miss while I was away. It is about 200 lines of code and most of the production incidents.

Same disclosure as before: I build HFT Forex Copier and other trading infrastructure at HFT Software, where a FIX session that recovers cleanly at 3 a.m. matters more than one that is a microsecond faster.

The code below reuses FixWriter, FixReader and FixField from part 1. As before it is plain C# 7 with no packages, so it runs on .NET Framework 4.8 and on current .NET.

What the session layer is responsible for

Seven administrative message types do all the work:

MsgType	Name	Job
`A`	Logon	Authenticate, agree the heartbeat interval, optionally reset sequence numbers
`0`	Heartbeat	"I am alive", sent when nothing else was sent for one interval
`1`	TestRequest	"Are you alive?", the other side must answer with a Heartbeat echoing `112`
`2`	ResendRequest	"I missed messages from number N, send them again"
`4`	SequenceReset	"Skip ahead to number N", used to answer a ResendRequest without replaying
`3`	Reject	"Your message broke session rules"
`5`	Logout	Orderly goodbye

Underneath all of it sits one rule: every message in each direction carries 34=MsgSeqNum, the numbers increase by exactly one, and both sides remember where they are, across disconnects. The authoritative text is the FIX Session Layer specification.

Sequence numbers must survive a restart

If your process restarts and starts again from 1 while the broker expects 5,812, the broker will refuse the logon. So the two counters live on disk, not in a field:

using System;
using System.Collections.Generic;
using System.Globalization;
using System.IO;
using System.Text;

public interface ISeqStore
{
    int NextOut { get; set; }   // sequence number of the next message we send
    int NextIn { get; set; }    // sequence number we expect to receive next
}

public sealed class FileSeqStore : ISeqStore
{
    readonly string _path;
    int _out = 1, _in = 1;

    public FileSeqStore(string path)
    {
        _path = path;
        if (File.Exists(path))
        {
            string[] p = File.ReadAllText(path).Split(':');
            _out = int.Parse(p[0], CultureInfo.InvariantCulture);
            _in = int.Parse(p[1], CultureInfo.InvariantCulture);
        }
    }

    public int NextOut { get { return _out; } set { _out = value; Save(); } }
    public int NextIn { get { return _in; } set { _in = value; Save(); } }

    void Save()
    {
        File.WriteAllText(_path, _out.ToString(CultureInfo.InvariantCulture) + ":" +
                                 _in.ToString(CultureInfo.InvariantCulture));
    }
}

Rewriting a tiny file on every message is fine for an order session that sends a few messages a second. For a market data session you would batch or memory-map it. Many retail brokers sidestep the problem by asking you to log on with 141=Y (ResetSeqNumFlag), which restarts both sides at 1 on every connection. That is simpler, and it also means anything you missed while disconnected is gone, so you must reconcile open orders and positions yourself after each logon.

Outbound side: Logon and a clock you can control

Two design choices make this class testable. The session never touches a socket, it calls a send delegate. And it never reads the system clock, it calls an injected utcNow. With those two seams you can run a full day of heartbeats in a unit test in a millisecond.

public sealed class FixSession
{
    readonly string _sender, _target;
    readonly ISeqStore _seq;
    readonly Action<string> _send;        // writes one complete message to the socket
    readonly Func<DateTime> _utcNow;      // injected clock: the session never calls DateTime.UtcNow
    int _heartBtInt = 30;
    DateTime _lastSent, _lastReceived;
    bool _testRequestPending, _resendPending;

    public bool LoggedOn { get; private set; }
    public event Action<byte[], int, int> ApplicationMessage;   // fills, rejects, market data
    public event Action<string> Disconnected;

    public FixSession(string sender, string target, ISeqStore seq,
                      Action<string> send, Func<DateTime> utcNow)
    {
        _sender = sender; _target = target; _seq = seq; _send = send; _utcNow = utcNow;
        _lastSent = _lastReceived = utcNow();
    }

    public void Logon(string username, string password, int heartBtInt, bool resetSeqNum,
                      params KeyValuePair<int, string>[] dialectHeader)
    {
        _heartBtInt = heartBtInt;
        if (resetSeqNum) { _seq.NextOut = 1; _seq.NextIn = 1; }
        var f = new List<KeyValuePair<int, string>>(dialectHeader);
        f.Add(F(98, "0"));                                                // EncryptMethod: none
        f.Add(F(108, heartBtInt.ToString(CultureInfo.InvariantCulture))); // HeartBtInt, seconds
        if (resetSeqNum) f.Add(F(141, "Y"));                              // ResetSeqNumFlag
        f.Add(F(553, username));
        f.Add(F(554, password));
        Send("A", f);
    }

    public void SendApplication(string msgType, List<KeyValuePair<int, string>> fields)
    {
        if (!LoggedOn) throw new InvalidOperationException("Not logged on");
        Send(msgType, fields);
    }

    void Send(string msgType, List<KeyValuePair<int, string>> fields)
    {
        int seq = _seq.NextOut;
        _seq.NextOut = seq + 1;                 // persist BEFORE the bytes leave
        _lastSent = _utcNow();
        _send(FixWriter.Build(msgType, _sender, _target, seq, _lastSent, fields));
    }

The order inside Send is deliberate. If the process dies after the counter is saved but before the bytes leave, the next message arrives with a number one higher than the broker expects. The broker asks for a resend, we answer with a gap fill, and life goes on. The opposite order can reuse a number the broker has already seen, and a sequence number that is too low is a fatal error.

The dialectHeader parameter exists because brokers differ. The cTrader FIX API, for example, runs separate price and trade sessions and tells them apart by 57=TRADE or 57=QUOTE in the header, as its specification describes. That is the kind of detail a product like our MT4 to cTrader copier has to get right per venue, and it is why the first document to read is always the broker's own rules of engagement.

Heartbeats and the dead line problem

TCP will not tell you promptly that the other side has vanished. A pulled cable or a frozen gateway can leave a socket looking healthy for minutes. FIX solves it at the application level:

    // call once a second
    public void OnTimer()
    {
        if (!LoggedOn) return;
        DateTime now = _utcNow();
        double quiet = (now - _lastReceived).TotalSeconds;

        if (_testRequestPending && quiet >= 2 * _heartBtInt)
        {
            Drop("No reply to TestRequest");
            return;
        }
        if (!_testRequestPending && quiet >= 1.2 * _heartBtInt)
        {
            _testRequestPending = true;
            Send("1", Fields(F(112, "TEST-" + now.ToString("HHmmss", CultureInfo.InvariantCulture))));
            return;
        }
        if ((now - _lastSent).TotalSeconds >= _heartBtInt)
            Send("0", Fields());
    }

Three rules. If we sent nothing for one interval, send a Heartbeat. If we heard nothing for a bit more than one interval, send a TestRequest. If that also goes unanswered, declare the line dead and reconnect. The 1.2 and 2 multipliers are my choice; the specification only asks for the interval plus a reasonable allowance for transmission time.

With a 30 second interval, worst case detection takes about a minute. If a minute of not knowing whether your orders are live is too long, negotiate a shorter 108.

Inbound side: the sequence check comes first

Every inbound message goes through the same gate before its type matters:

    // one framed, checksum-verified message (see part 1)
    public void OnMessage(byte[] buf, int start, int length)
    {
        string msgType = null, testReqId = null;
        int seqNum = 0, beginSeqNo = 0, newSeqNo = 0;
        bool possDup = false, gapFill = false;

        int pos = start, end = start + length;
        FixField f;
        while (FixReader.TryRead(buf, ref pos, end, out f))
        {
            switch (f.Tag)
            {
                case 35: msgType = Encoding.ASCII.GetString(buf, f.Offset, f.Length); break;
                case 34: seqNum = ToInt(buf, f); break;
                case 43: possDup = buf[f.Offset] == (byte)'Y'; break;
                case 112: testReqId = Encoding.ASCII.GetString(buf, f.Offset, f.Length); break;
                case 7: beginSeqNo = ToInt(buf, f); break;
                case 36: newSeqNo = ToInt(buf, f); break;
                case 123: gapFill = buf[f.Offset] == (byte)'Y'; break;
            }
        }

        _lastReceived = _utcNow();
        _testRequestPending = false;

        // SequenceReset in Reset mode ignores MsgSeqNum by definition
        if (msgType == "4" && !gapFill) { _seq.NextIn = newSeqNo; return; }

        int expected = _seq.NextIn;
        if (seqNum > expected)
        {
            // We missed something. Ask once for everything from the gap onwards (16=0 = "to infinity").
            if (!_resendPending)
            {
                _resendPending = true;
                Send("2", Fields(F(7, expected.ToString(CultureInfo.InvariantCulture)), F(16, "0")));
            }
            return;                               // do not process out-of-order messages
        }
        if (seqNum < expected)
        {
            if (possDup) return;                  // a resend of something we already have
            Drop("MsgSeqNum too low: expected " + expected + ", got " + seqNum);
            return;
        }

        _seq.NextIn = (msgType == "4") ? newSeqNo : expected + 1;
        _resendPending = false;

        switch (msgType)
        {
            case "A": LoggedOn = true; break;
            case "0": break;                                          // Heartbeat
            case "1": Send("0", Fields(F(112, testReqId))); break;    // TestRequest -> Heartbeat
            case "2": AnswerResendRequest(beginSeqNo); break;
            case "4": break;                                          // GapFill, already applied
            case "5": Drop("Logout from counterparty"); break;
            default:
                var handler = ApplicationMessage;
                if (handler != null) handler(buf, start, length);
                break;
        }
    }

The three branches are the heart of FIX recovery:

Too high means we missed messages. We ask for them and, importantly, we do not process the message that revealed the gap. A fill delivered out of order is how position state gets corrupted. It will come again, flagged 43=Y.
Too low without 43=Y means the two sides disagree about history. There is no safe automatic fix, so the session drops and a human looks at it.
Exactly right advances the counter, and only then does the message type matter.

Answering a ResendRequest without replaying orders

When the broker asks us to resend, the literal answer is to replay every message in the range. For an order flow that is dangerous: a NewOrderSingle that was relevant forty seconds ago is not an order you want executed now. The common policy is to replay nothing and cover the whole range with a single SequenceReset in gap fill mode:

    // Policy: never replay old orders. Cover the whole requested range with one GapFill.
    void AnswerResendRequest(int beginSeqNo)
    {
        DateTime now = _utcNow();
        string ts = now.ToString("yyyyMMdd-HH:mm:ss.fff", CultureInfo.InvariantCulture);
        var f = Fields(F(43, "Y"),                       // PossDupFlag
                       F(122, ts),                       // OrigSendingTime, required with 43=Y
                       F(123, "Y"),                      // GapFillFlag
                       F(36, _seq.NextOut.ToString(CultureInfo.InvariantCulture)));  // NewSeqNo
        _lastSent = now;
        // A GapFill carries the sequence number of the first message it replaces.
        _send(FixWriter.Build("4", _sender, _target, beginSeqNo, now, f));
    }

    void Drop(string reason)
    {
        LoggedOn = false;
        var handler = Disconnected;
        if (handler != null) handler(reason);
    }

    static int ToInt(byte[] buf, FixField f)
    {
        int v = 0;
        for (int i = f.Offset; i < f.Offset + f.Length; i++) v = v * 10 + (buf[i] - '0');
        return v;
    }

    static KeyValuePair<int, string> F(int tag, string value)
    {
        return new KeyValuePair<int, string>(tag, value);
    }

    static List<KeyValuePair<int, string>> Fields(params KeyValuePair<int, string>[] items)
    {
        return new List<KeyValuePair<int, string>>(items);
    }
}

Two details are easy to get wrong. The gap fill does not consume a new sequence number: it is sent with the number of the first message it replaces. And it must carry 43=Y together with 122=OrigSendingTime, or a strict counterparty will reject it.

After a gap fill you still owe yourself a reconciliation: ask the broker for order status and compare it with what you believe is open.

Running a whole day in a millisecond

Here is the payoff of injecting the clock and the transport. This scenario plays the broker, moves time forward by hand and prints both directions:

public static class Scenario
{
    static DateTime _clock = new DateTime(2026, 9, 23, 8, 0, 0, DateTimeKind.Utc);
    static int _brokerSeq = 1;

    static KeyValuePair<int, string> F(int tag, string value) { return new KeyValuePair<int, string>(tag, value); }

    // Builds a message "from the broker" and feeds it to the session, as the socket reader would.
    static void FromBroker(FixSession s, string msgType, int seq, params KeyValuePair<int, string>[] fields)
    {
        string raw = FixWriter.Build(msgType, "BROKER", "CLIENT1", seq, _clock, fields);
        Console.WriteLine("  <- " + raw.Replace('\x01', '|'));
        byte[] bytes = Encoding.ASCII.GetBytes(raw);
        s.OnMessage(bytes, 0, bytes.Length);
    }

    static void Tick(FixSession s, int seconds)
    {
        for (int i = 0; i < seconds; i++) { _clock = _clock.AddSeconds(1); s.OnTimer(); }
    }

    public static void Main()
    {
        string path = Path.Combine(Path.GetTempPath(), "client1-broker.seq");
        if (File.Exists(path)) File.Delete(path);

        var session = new FixSession("CLIENT1", "BROKER", new FileSeqStore(path),
            raw => Console.WriteLine("  -> " + raw.Replace('\x01', '|')), () => _clock);
        session.ApplicationMessage += (b, o, n) => Console.WriteLine("  ** application message delivered, " + n + " bytes");
        session.Disconnected += reason => Console.WriteLine("  !! disconnected: " + reason);

        Console.WriteLine("1. Logon");
        session.Logon("12345", "secret", 30, true, F(57, "TRADE"), F(50, "COPIER"));
        FromBroker(session, "A", _brokerSeq++, F(98, "0"), F(108, "30"), F(141, "Y"));

        Console.WriteLine("2. Thirty quiet seconds");
        Tick(session, 30);

        Console.WriteLine("3. Broker sends TestRequest");
        FromBroker(session, "1", _brokerSeq++, F(112, "PING-7"));

        Console.WriteLine("4. A fill arrives with MsgSeqNum 5 while we expect 3");
        FromBroker(session, "8", 5, F(11, "ORD-0001"), F(150, "F"), F(39, "2"));
        Console.WriteLine("5. Broker gap-fills 3..4, then resends the fill");
        FromBroker(session, "4", 3, F(43, "Y"), F(122, "20260923-08:00:30.000"), F(123, "Y"), F(36, "5"));
        FromBroker(session, "8", 5, F(43, "Y"), F(122, "20260923-08:00:30.000"), F(11, "ORD-0001"), F(150, "F"), F(39, "2"));

        Console.WriteLine("6. Broker asks us to resend from 2");
        FromBroker(session, "2", 6, F(7, "2"), F(16, "0"));

        Console.WriteLine("7. The line goes silent");
        Tick(session, 36);
        Tick(session, 24);

        Console.WriteLine("8. Restart: sequence numbers survive");
        var store = new FileSeqStore(path);
        Console.WriteLine("  next out = " + store.NextOut + ", next in = " + store.NextIn);
    }
}

And the output, exactly as the program prints it:

1. Logon
  -> 8=FIX.4.4|9=114|35=A|49=CLIENT1|56=BROKER|34=1|52=20260923-08:00:00.000|57=TRADE|50=COPIER|98=0|108=30|141=Y|553=12345|554=secret|10=185|
  <- 8=FIX.4.4|9=74|35=A|49=BROKER|56=CLIENT1|34=1|52=20260923-08:00:00.000|98=0|108=30|141=Y|10=211|
2. Thirty quiet seconds
  -> 8=FIX.4.4|9=56|35=0|49=CLIENT1|56=BROKER|34=2|52=20260923-08:00:30.000|10=128|
3. Broker sends TestRequest
  <- 8=FIX.4.4|9=67|35=1|49=BROKER|56=CLIENT1|34=2|52=20260923-08:00:30.000|112=PING-7|10=231|
  -> 8=FIX.4.4|9=67|35=0|49=CLIENT1|56=BROKER|34=3|52=20260923-08:00:30.000|112=PING-7|10=231|
4. A fill arrives with MsgSeqNum 5 while we expect 3
  <- 8=FIX.4.4|9=79|35=8|49=BROKER|56=CLIENT1|34=5|52=20260923-08:00:30.000|11=ORD-0001|150=F|39=2|10=249|
  -> 8=FIX.4.4|9=65|35=2|49=CLIENT1|56=BROKER|34=4|52=20260923-08:00:30.000|7=3|16=0|10=001|
5. Broker gap-fills 3..4, then resends the fill
  <- 8=FIX.4.4|9=98|35=4|49=BROKER|56=CLIENT1|34=3|52=20260923-08:00:30.000|43=Y|122=20260923-08:00:30.000|123=Y|36=5|10=135|
  <- 8=FIX.4.4|9=110|35=8|49=BROKER|56=CLIENT1|34=5|52=20260923-08:00:30.000|43=Y|122=20260923-08:00:30.000|11=ORD-0001|150=F|39=2|10=014|
  ** application message delivered, 133 bytes
6. Broker asks us to resend from 2
  <- 8=FIX.4.4|9=65|35=2|49=BROKER|56=CLIENT1|34=6|52=20260923-08:00:30.000|7=2|16=0|10=002|
  -> 8=FIX.4.4|9=98|35=4|49=CLIENT1|56=BROKER|34=2|52=20260923-08:00:30.000|43=Y|122=20260923-08:00:30.000|123=Y|36=5|10=134|
7. The line goes silent
  -> 8=FIX.4.4|9=56|35=0|49=CLIENT1|56=BROKER|34=5|52=20260923-08:01:00.000|10=129|
  -> 8=FIX.4.4|9=72|35=1|49=CLIENT1|56=BROKER|34=6|52=20260923-08:01:06.000|112=TEST-080106|10=245|
  !! disconnected: No reply to TestRequest
8. Restart: sequence numbers survive
  next out = 7, next in = 7

Read step 4 twice. The fill with number 5 is received and deliberately not delivered. Only after the broker fills the gap in step 5 does the application see it, once, in order. Step 6 shows our gap fill going out with 34=2, the first number the broker asked for, and 36=5, where we really are.

What this sketch leaves out

It is a teaching session, not a product. A production one also needs a logon timeout, Logout with a reason and a wait for the reply, Reject (35=3) handling, validation of 49, 56 and 52 on inbound messages, a reconnect policy with backoff, and thread safety between the socket reader, the timer and the order sender. QuickFIX/n does all of that, and after writing the 200 lines above you will know exactly what its log is telling you.

If you would rather watch a FIX session than write one, the same lifecycle is visible from the user side in a FIX client: FIX API Terminal has a plain-language walkthrough of how FIX API trading works. For a non-developer colleague, What is FIX API covers the why. And if the question is whether the extra work over a MetaTrader bridge pays off for latency-sensitive strategies, I compared the two routes in FIX API vs MT4 bridge.

Checklist

Persist both sequence numbers, and save before you send.
Never process a message that arrives with a number higher than expected.
Treat a number lower than expected without 43=Y as fatal.
Answer a ResendRequest with a GapFill unless you have a reason to replay, and never replay orders.
Send the GapFill with the first replaced number, 43=Y and 122.
Detect dead lines with TestRequest, do not trust TCP to tell you.
Reconcile orders and positions after every logon and after every gap.
Inject the clock and the transport so all of this can be tested without a broker.

I am Sergiy Lutsak (I also publish as Sergey Luts). I have been building high-frequency trading systems since 2000. More about my work: author page.

This article is about software engineering. It is not investment advice, and trading leveraged products carries a high risk of loss.

FIX 4.4 in C# From Scratch: Build, Checksum and Parse Orders Without a Library

Sergiy Lutsak — Thu, 17 Sep 2026 15:30:08 +0000

Every broker that offers "FIX API access" is offering the same thing underneath: a TCP socket that speaks the Financial Information eXchange protocol. Most .NET developers meet FIX through QuickFIX/n, which is the right choice for a production session layer. It is also a big black box, and when a broker rejects your order with 58=Invalid BodyLength at 3 a.m., a black box is not what you want.

So this post goes the other way. We will build a FIX 4.4 NewOrderSingle by hand, compute the two fields everybody gets wrong, split a TCP stream into messages, and parse an ExecutionReport without allocating. Plain C#, no packages. Everything compiles as C# 7, so it runs on .NET Framework 4.8 as well as on current .NET.

Disclosure, so you know where I am coming from: I build trading infrastructure for a living, including HFT Forex Copier and HFT Arbitrage Platform. Both talk FIX to brokers all day, and this is the layer I end up debugging.

The wire format in one minute

A FIX message is a flat list of tag=value pairs. Each pair ends with the SOH byte (0x01). There are no brackets, no nesting and no whitespace. In logs SOH is usually printed as |, which is what I do below:

8=FIX.4.4|9=130|35=D|49=CLIENT1|56=BROKER|34=42|52=20260917-14:30:05.123|11=ORD-0001|55=EUR/USD|54=1|60=20260917-14:30:05.123|38=100000|40=1|59=3|10=067|

Three rules give the message its shape:

The first three fields are always 8 (BeginString), 9 (BodyLength) and 35 (MsgType), in that order.
The last field is always 10 (CheckSum).
Everything else is header (49 sender, 56 target, 34 sequence number, 52 sending time) followed by the body for that message type.

35=D is a NewOrderSingle. 35=8 is an ExecutionReport. The FIX 4.4 specification lists the rest.

BodyLength and CheckSum

These two fields cause most first-week rejections.

BodyLength (9) is the number of bytes after the SOH that ends the 9= field, up to and including the SOH right before 10=. Bytes, not characters, which matters the moment a text field contains anything outside ASCII.

CheckSum (10) is the sum of every byte from the 8 of 8=FIX.4.4 through the SOH before 10=, modulo 256, printed as exactly three digits. 67 is wrong. 067 is right.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Globalization;
using System.Text;

public static class FixWriter
{
    public const char SOH = '\x01';

    public static string Build(string msgType, string sender, string target,
                               int seqNum, DateTime utcNow,
                               IEnumerable<KeyValuePair<int, string>> fields)
    {
        // 1. Everything between BodyLength(9) and CheckSum(10)
        var body = new StringBuilder(256);
        Add(body, 35, msgType);
        Add(body, 49, sender);
        Add(body, 56, target);
        Add(body, 34, seqNum.ToString(CultureInfo.InvariantCulture));
        Add(body, 52, utcNow.ToString("yyyyMMdd-HH:mm:ss.fff", CultureInfo.InvariantCulture));
        foreach (var f in fields) Add(body, f.Key, f.Value);

        // 2. BeginString(8) + BodyLength(9). Length is counted in BYTES.
        var msg = new StringBuilder(body.Length + 32);
        Add(msg, 8, "FIX.4.4");
        Add(msg, 9, Encoding.ASCII.GetByteCount(body.ToString())
                            .ToString(CultureInfo.InvariantCulture));
        msg.Append(body);

        // 3. CheckSum(10): sum of every byte so far, modulo 256, always 3 digits.
        int sum = 0;
        foreach (byte b in Encoding.ASCII.GetBytes(msg.ToString())) sum += b;
        Add(msg, 10, (sum % 256).ToString("D3", CultureInfo.InvariantCulture));

        return msg.ToString();
    }

    static void Add(StringBuilder sb, int tag, string value)
    {
        sb.Append(tag.ToString(CultureInfo.InvariantCulture)).Append('=').Append(value).Append(SOH);
    }
}

Note the InvariantCulture everywhere. A server with a German or Russian locale will happily format 1.5 as 1,5, and the broker will not be amused.

A market order with IOC

In FIX 4.4 a NewOrderSingle needs a client order id, an instrument, a side, a transaction time, a quantity and an order type. For FX I almost always add a time in force, because that is your slippage control: 59=3 (Immediate or Cancel) fills what it can right now and cancels the rest, 59=4 (Fill or Kill) is all or nothing.

public static class Orders
{
    public static string MarketIoc(string sender, string target, int seqNum, DateTime utcNow,
                                   string clOrdId, string symbol, bool buy, decimal qty)
    {
        string ts = utcNow.ToString("yyyyMMdd-HH:mm:ss.fff", CultureInfo.InvariantCulture);
        var fields = new List<KeyValuePair<int, string>>
        {
            F(11, clOrdId),                                     // ClOrdID: your unique id
            F(55, symbol),                                      // Symbol, e.g. EUR/USD
            F(54, buy ? "1" : "2"),                             // Side: 1=Buy, 2=Sell
            F(60, ts),                                          // TransactTime (UTC)
            F(38, qty.ToString(CultureInfo.InvariantCulture)),  // OrderQty
            F(40, "1"),                                         // OrdType: 1=Market
            F(59, "3"),                                         // TimeInForce: 3=IOC
        };
        return FixWriter.Build("D", sender, target, seqNum, utcNow, fields);
    }

    static KeyValuePair<int, string> F(int tag, string value)
    {
        return new KeyValuePair<int, string>(tag, value);
    }
}

That call produces exactly the message shown at the top of the post. For a limit order, set 40=2 and add 44=<price>.

One warning from experience: every broker has a dialect. Some require 21=1 (HandlInst) even though 4.4 made it optional, some want 1=<account>, some want EURUSD instead of EUR/USD. Read the broker's rules of engagement document before you write a line of code.

FIX over TCP is a stream, not a packet

This is the bug that survives testing and bites in production. One Read() from the socket can return half a message, or two and a half messages. You have to frame the stream yourself, and BodyLength is what makes that possible: once you have read 8=...|9=NNN|, you know the message ends NNN + 7 bytes later, because the trailer 10=xxx| is always seven bytes.

public static class FixFramer
{
    const byte SOH = 1;

    // Returns the full length of the first message in buf[start..start+count),
    // or 0 if more bytes are needed, or -1 if the stream is garbage.
    public static int TryFrame(byte[] buf, int start, int count)
    {
        int end = start + count;
        int p = start;

        // "8=FIX.x.y<SOH>"
        if (count < 2) return 0;
        if (buf[p] != (byte)'8' || buf[p + 1] != (byte)'=') return -1;
        while (p < end && buf[p] != SOH) p++;
        if (p == end) return 0;
        p++;

        // "9=<digits><SOH>"
        if (end - p < 2) return 0;
        if (buf[p] != (byte)'9' || buf[p + 1] != (byte)'=') return -1;
        p += 2;
        int bodyLen = 0, digits = 0;
        while (p < end && buf[p] != SOH)
        {
            int d = buf[p] - '0';
            if (d < 0 || d > 9 || ++digits > 6) return -1;
            bodyLen = bodyLen * 10 + d;
            p++;
        }
        if (p == end) return 0;
        p++;

        // body, then "10=xxx<SOH>" which is always 7 bytes
        int total = (p - start) + bodyLen + 7;
        return total <= count ? total : 0;
    }

    public static bool ChecksumOk(byte[] buf, int start, int length)
    {
        int trailer = start + length - 7;               // position of "10="
        if (length < 7 || buf[trailer] != (byte)'1' || buf[trailer + 1] != (byte)'0'
                       || buf[trailer + 2] != (byte)'=') return false;
        int sum = 0;
        for (int i = start; i < trailer; i++) sum += buf[i];
        int expected = (buf[trailer + 3] - '0') * 100 + (buf[trailer + 4] - '0') * 10
                     + (buf[trailer + 5] - '0');
        return (sum & 0xFF) == expected;
    }
}

Your receive loop appends socket bytes to a buffer, calls TryFrame until it returns 0, and keeps the leftover bytes for the next read.

Parsing an ExecutionReport without allocating

The obvious parser is message.Split('\x01') followed by Split('=') and a Dictionary<int, string>. It works, and it allocates a few dozen objects per message. On a quiet session nobody cares. On a busy market data or execution session that is steady garbage, and garbage collections show up exactly where you least want them: in the tail of your latency distribution.

The alternative is to walk the bytes once and only note where each value lives:

public struct FixField
{
    public int Tag;
    public int Offset;   // where the value starts in the buffer
    public int Length;   // value length in bytes
}

public static class FixReader
{
    const byte SOH = 1;

    public static bool TryRead(byte[] buf, ref int pos, int end, out FixField field)
    {
        field = default(FixField);
        int tag = 0;
        while (pos < end && buf[pos] != (byte)'=')
        {
            int d = buf[pos] - '0';
            if (d < 0 || d > 9) return false;
            tag = tag * 10 + d;
            pos++;
        }
        if (pos >= end) return false;
        pos++;                                   // skip '='
        int valueStart = pos;
        while (pos < end && buf[pos] != SOH) pos++;
        if (pos >= end) return false;
        field.Tag = tag;
        field.Offset = valueStart;
        field.Length = pos - valueStart;
        pos++;                                   // skip SOH
        return true;
    }

    // Parses "1.08452" style numbers straight from ASCII bytes. No strings, no culture.
    public static decimal ToDecimal(byte[] buf, int offset, int length)
    {
        long mantissa = 0;
        int scale = 0;
        bool neg = false, seenDot = false;
        for (int i = offset; i < offset + length; i++)
        {
            byte c = buf[i];
            if (c == (byte)'-') { neg = true; continue; }
            if (c == (byte)'.') { seenDot = true; continue; }
            mantissa = mantissa * 10 + (c - '0');
            if (seenDot) scale++;
        }
        return new decimal((int)(mantissa & 0xFFFFFFFF), (int)(mantissa >> 32), 0, neg, (byte)scale);
    }
}

Prices are decimal on purpose. 1.08452 has no exact double representation, and you do not want to explain a one-pip reconciliation break caused by binary floating point.

On top of the reader, the ExecutionReport parser is a switch:

public struct Fill
{
    public char ExecType;    // 150: '0'=New, 'F'=Trade, '8'=Rejected
    public char OrdStatus;   // 39:  '1'=Partially filled, '2'=Filled, '8'=Rejected
    public decimal LastQty;  // 32
    public decimal LastPx;   // 31
    public decimal LeavesQty;// 151
    public int ClOrdIdOffset, ClOrdIdLength; // 11
}

public static class ExecutionReports
{
    public static bool TryParse(byte[] buf, int start, int length, out Fill fill)
    {
        fill = default(Fill);
        int pos = start, end = start + length;
        bool isExecReport = false;
        FixField f;
        while (FixReader.TryRead(buf, ref pos, end, out f))
        {
            switch (f.Tag)
            {
                case 35: isExecReport = f.Length == 1 && buf[f.Offset] == (byte)'8'; break;
                case 11: fill.ClOrdIdOffset = f.Offset; fill.ClOrdIdLength = f.Length; break;
                case 150: fill.ExecType = (char)buf[f.Offset]; break;
                case 39: fill.OrdStatus = (char)buf[f.Offset]; break;
                case 32: fill.LastQty = FixReader.ToDecimal(buf, f.Offset, f.Length); break;
                case 31: fill.LastPx = FixReader.ToDecimal(buf, f.Offset, f.Length); break;
                case 151: fill.LeavesQty = FixReader.ToDecimal(buf, f.Offset, f.Length); break;
            }
        }
        return isExecReport;
    }
}

A detail that trips people moving from FIX 4.2: in 4.4 a fill arrives as 150=F (Trade), and you tell partial from full by 39 and 151. The old 150=1 and 150=2 values were dropped from the standard, although a few broker dialects still send them, so check what yours does.

What does all of this cost?

Measure it. Warm up first so the JIT is out of the picture, then time a million iterations:

public static class Program
{
    public static void Main()
    {
        var t = DateTime.UtcNow;
        var er = Encoding.ASCII.GetBytes(FixWriter.Build("8", "BROKER", "CLIENT1", 97, t,
            new List<KeyValuePair<int, string>>
            {
                new KeyValuePair<int, string>(37, "B-778812"), new KeyValuePair<int, string>(11, "ORD-0001"),
                new KeyValuePair<int, string>(17, "E-1"),      new KeyValuePair<int, string>(150, "F"),
                new KeyValuePair<int, string>(39, "2"),        new KeyValuePair<int, string>(55, "EUR/USD"),
                new KeyValuePair<int, string>(54, "1"),        new KeyValuePair<int, string>(32, "100000"),
                new KeyValuePair<int, string>(31, "1.08452"),  new KeyValuePair<int, string>(151, "0"),
            }));

        const int N = 1000000;
        Fill fill;
        for (int i = 0; i < 100000; i++)                                   // warm-up
        {
            Orders.MarketIoc("CLIENT1", "BROKER", i, t, "ORD-0001", "EUR/USD", true, 100000m);
            ExecutionReports.TryParse(er, 0, er.Length, out fill);
        }

        var sw = Stopwatch.StartNew();
        for (int i = 0; i < N; i++)
            Orders.MarketIoc("CLIENT1", "BROKER", i, t, "ORD-0001", "EUR/USD", true, 100000m);
        sw.Stop();
        Console.WriteLine("build: {0:F0} ns/op", sw.Elapsed.TotalMilliseconds * 1e6 / N);

        int gen0 = GC.CollectionCount(0);
        sw.Restart();
        for (int i = 0; i < N; i++)
            if (FixFramer.TryFrame(er, 0, er.Length) > 0 && FixFramer.ChecksumOk(er, 0, er.Length))
                ExecutionReports.TryParse(er, 0, er.Length, out fill);
        sw.Stop();
        Console.WriteLine("frame + checksum + parse: {0:F0} ns/op, gen0 collections: {1}",
            sw.Elapsed.TotalMilliseconds * 1e6 / N, GC.CollectionCount(0) - gen0);
    }
}

Expect single-digit microseconds for the string-based builder and well under a microsecond for the frame, checksum and parse path, with zero gen-0 collections on the read side. Your exact numbers depend on runtime and CPU. The orders of magnitude do not.

Now put that next to everything else in the life of an order. A network round trip to a broker from a nearby VPS is on the order of a millisecond, and the broker's own matching and fill takes milliseconds to tens of milliseconds. I published a stage-by-stage table of those ranges in a local vs cloud copier latency breakdown. Message encoding is three orders of magnitude below the network.

So why bother with the allocation-free parser? Because averages are not the problem. A blocking garbage collection at the wrong moment can cost you milliseconds, not microseconds, and it lands in your p99. For most strategies that is noise. For anything that lives on short-lived price discrepancies, such as latency arbitrage, the tail is where the money is lost.

What this post skipped: the session layer

A working FIX connection also needs:

Logon (35=A) with 98=0 and 108=<heartbeat seconds>, usually a username and password in 553 and 554, and often 141=Y to reset sequence numbers.
Heartbeat (35=0) and TestRequest (35=1) handling, or the broker drops you.
Sequence numbers (34) that persist across reconnects, ResendRequest (35=2) and SequenceReset (35=4) for gap recovery.
Logout (35=5) and a reconnect policy.

This is exactly what QuickFIX/n gives you, and unless you have a measured reason to replace it, use it. Understanding the wire format is what lets you read its logs.

Do you need to write any of this yourself?

If your goal is to build trading infrastructure, yes, and the snippets above are a reasonable start. If your goal is just to get orders from a strategy onto a FIX account, retail traders usually take one of two routes. Either the strategy stays in MetaTrader and a copier mirrors its trades onto the FIX account (this is what our FIX API copier does), or the strategy moves to a native FIX client and MetaTrader leaves the path entirely (FIX API Terminal is one example, and it can run MQL robots directly on a FIX session). Either way, what goes over the wire is what you have just read.

Checklist before you hit a live session

BodyLength in bytes, CheckSum as three digits.
All timestamps in UTC, yyyyMMdd-HH:mm:ss.fff.
InvariantCulture for every number you format or parse.
decimal for prices and quantities.
Frame the TCP stream; never assume one read equals one message.
Persist sequence numbers.
Log raw messages with SOH replaced by |. You will need them.
Test against the broker's UAT or demo endpoint first, with their rules of engagement open in another window.

I am Sergiy Lutsak (I also publish as Sergey Luts). I have been building high-frequency trading systems since 2000. More about my work: author page.

This article is about software engineering. It is not investment advice, and trading leveraged products carries a high risk of loss.

    int gen0 = GC.CollectionCount(0);
    sw.Restart();
    for (int i = 0; i < N; i++)
        if (FixFramer.TryFrame(er, 0, er.Length) > 0 && FixFramer.ChecksumOk(er, 0, er.Length))
            ExecutionReports.TryParse(er, 0, er.Length, out fill);
    sw.Stop();
    Console.WriteLine("frame + checksum + parse: {0:F0} ns/op, gen0 collections: {1}",
        sw.Elapsed.TotalMilliseconds * 1e6 / N, GC.CollectionCount(0) - gen0);
}

}
Expect single-digit microseconds for the string-based builder and well under a microsecond for the frame, checksum and parse path, with zero gen-0 collections on the read side. Your exact numbers depend on runtime and CPU. The orders of magnitude do not.

What this post skipped: the session layer
A working FIX connection also needs:

Logon (35=A) with 98=0 and 108=, usually a username and password in 553 and 554, and often 141=Y to reset sequence numbers.
Heartbeat (35=0) and TestRequest (35=1) handling, or the broker drops you.
Sequence numbers (34) that persist across reconnects, ResendRequest (35=2) and SequenceReset (35=4) for gap recovery.
Logout (35=5) and a reconnect policy.
This is exactly what QuickFIX/n gives you, and unless you have a measured reason to replace it, use it. Understanding the wire format is what lets you read its logs.

Do you need to write any of this yourself?
If your goal is to build trading infrastructure, yes, and the snippets above are a reasonable start. If your goal is just to get orders from a strategy onto a FIX account, retail traders usually take one of two routes. Either the strategy stays in MetaTrader and a copier mirrors its trades onto the FIX account (this is what our FIX API copier does), or the strategy moves to a native FIX client and MetaTrader leaves the path entirely (FIX API Terminal is one example, and it can run MQL robots directly on a FIX session). Either way, what goes over the wire is what you have just read.

Checklist before you hit a live session
BodyLength in bytes, CheckSum as three digits.
All timestamps in UTC, yyyyMMdd-HH:mm:ss.fff.
InvariantCulture for every number you format or parse.
decimal for prices and quantities.
Frame the TCP stream; never assume one read equals one message.
Persist sequence numbers.
Log raw messages with SOH replaced by |. You will need them.
Test against the broker's UAT or demo endpoint first, with their rules of engagement open in another window.
I am Sergiy Lutsak (I also publish as Sergey Luts). I have been building high-frequency trading systems since 2000. More about my work: author page.

This article is about software engineering. It is not investment advice, and trading leveraged products carries a high risk of loss.