← → keys to navigate
APAC Exchange Connectivity · Deep Dive

You press BUY.

What happens in the next 50 microseconds?

A half-day journey through five of the world's most sophisticated financial markets — the technology, protocols, standards, and engineering decisions that move trillions of dollars of options contracts across Australia, India, Japan, Korea, and Taiwan every day.

5
APAC venues
~50 µs
Typical OE round-trip inside a colo
14+
Distinct native binary protocols
>100 ms
Tokyo → Sydney speed-of-light floor
Agenda

Markets → Order journey → Protocols → Encoding → Matching → Latency → Risk → APAC deep-dive → Career

Markets 101

What is an options market? And why does this one care about microseconds?

You know what a share is — partial ownership of a company. An option is a contract that gives you the right but not the obligation to buy or sell that share at a fixed price before a fixed date.

That sounds abstract. Here is why it matters technically: options expire. Every contract has a clock ticking. That clock creates urgency, and urgency demands speed.

💡 The key insight Unlike equities (buy and hold for years), options decay in value every day they remain open. A 1-millisecond edge in pricing or execution can mean the difference between profit and loss on a position that expires in 4 hours.
🎟️
Analogy: concert ticket insurance. You buy a "right to purchase" a concert ticket at £50 any time in the next month. If tickets sell out and resell for £200, you exercise your right. If the concert is cancelled, you let the right expire. The right itself has a price — that's the option premium.
⚡
Why microseconds? Hundreds of firms simultaneously watch the same market data and compute the same "fair price" for an option. The first to send a correctly-priced order wins. Second place wins nothing. This is the arms race that built the infrastructure we're studying.
Ask yourself

If options decay in value over time, who is on the other side of every trade — and why would they willingly sell you something that's losing value?

Geography

Five markets. Five regulatory regimes. Five completely different protocols.

🇦🇺 Australia

ASX Trade — equities + Exchange Traded Options (ETOs)
ASX 24 — futures + options on futures
Cboe AU — alternative equities venue

ITCHOUCHSoupBinTCPBOEv3PITCH

CoLo: Equinix SY3 (ASX), Global Switch (Cboe)

🇮🇳 India

NSE — world's largest options exchange by volume
BSE BOLT+ — Eurex T7 technology platform

NNFMTBTETIIML/OMBFAST/FIX

NSE NNF spec: "trimmed" — NDA for full details

🇯🇵 Japan

TSE Arrowhead 4.0 — cash equities
OSE J-GATE 3.0 — derivatives + index options

FLEX Std/FullJ-GATE ITCHOMnetAPI

Mandatory pre-trade risk via TradeGuard system

🇰🇷 Korea

KRX EXTURE+ — unified platform, equities + derivatives

Proprietary binaryMDSFIX 4.4 +tags

Full spec NDA-gated via member portal. FIX tags 6000–9999 are KRX custom.

🇹🇼 Taiwan

TAIFEX — futures + options, government-owned

TMP v2.15.0FIX 4.2/4.4File Transfer

TMP spec is public PDF — rare for APAC. Big-endian, sequence-numbered.

Ask yourself

NSE is the world's largest options market by volume — yet it's harder to connect to than CME. Why would an exchange make connectivity harder, and who does that benefit?

Architecture

The order journey — from trader's brain to exchange's book

Strategy Engine Signal fires → "BUY 10 lots" ① SIGNAL order intent Pre-Trade Risk fat-finger check position limits ② RISK GATE approved OE Gateway encode to binary OUCH / TMP / NNF ③ ENCODE TCP · cross-connect or WAN fibre Exch. Gateway session auth validate, queue ④ RECEIVE internal bus Matching Engine order book price-time priority ⑤ MATCH execution rpt Fill + MD out trade report market data blast ⑥ PUBLISH Market Data (UDP multicast) — received by ALL subscribers simultaneously ITCH / FLEX / TMP / MTBT / MDS — asynchronous, no TCP handshake Inside CoLo (colocation datacenter): strategy → exchange gateway ~10 – 200 µs depending on venue, kernel-bypass, FPGA acceleration From WAN (remote office → venue) 1 – 150 ms depending on geography
🔑 The critical asymmetry Order entry (blue path) is always TCP — reliable, ordered, acknowledged. Market data (green path) is always UDP multicast — fast, fan-out, no acknowledgement, no guaranteed delivery. These are not accidents. They are deliberate engineering tradeoffs that every venue in APAC has independently converged on.
Ask yourself

The strategy engine receives market data before it sends an order. That means it has to process incoming data faster than competitors to act first. What limits how fast you can process incoming data?

Encoding

Binary vs FIX: the SMS vs letter analogy

⚡ Native Binary (OUCH, TMP, NNF…)

A fixed-width record. Every field is at a known byte offset. No parsing needed — you read position 0–3 for price, position 4–7 for quantity, done.

// OUCH Enter Order — 49 bytes total
// Offset  Size  Field
//    0       1  PacketType = 'O'
//    1       4  OrderToken (binary int)
//    5       1  BuySellIndicator 'B'/'S'
//    6       4  Shares (big-endian uint32)
//   10       8  Stock (8 ASCII chars)
//   18       4  Price (uint32, scaled 10^-4)
//   22       4  TimeInForce
//   ...    ...

Parse time: nanoseconds. One memcpy into a struct. FPGA can do it in hardware.

Analogy: 4-digit PIN You know it's always exactly 4 digits. You don't read "PIN=1234" — you just read 4 digits. No label needed.
📝 FIX (Financial Information eXchange)

A tag=value ASCII protocol. Every field is labelled with a tag number. Human-readable, but verbose. Designed in 1992 for reliability over speed.

8=FIX.4.4|9=178|35=D|   ← BeginStr|Length|MsgType
49=FIRM1|56=EXCHANGE|        ← SenderID|TargetID
34=291|52=20240506-09:30:01| ← SeqNum|SendTime
11=ORD-001|55=NIFTY25MAY|    ← ClOrdID|Symbol
54=1|38=10|44=21500.00|      ← Side|Qty|Price
10=247|                       ← Checksum

Parse time: microseconds. Must scan for pipe delimiters. Cannot FPGA-accelerate easily.

Analogy: formal letter "Dear Sir, re: Order number 001, I hereby instruct you to BUY…" Unambiguous and auditable. But you'd never telegram this way.
🔑 Why both exist Binary wins on latency-critical paths (market data, HFT order entry). FIX wins for broker integration, DMA clients, give-up orders, and regulatory reporting — because every system in the world speaks FIX. KRX even extends FIX with custom tags 6000–9999 for their own fields.
Ask yourself

FIX is text, so you can read a packet capture in Wireshark and immediately understand it. Binary requires a spec to decode. From a security and debugging perspective, which property is more valuable?

Session Layer

The session layer: the envelope around your message

Binary message formats (OUCH, ITCH, TMP) define what the data is. Session protocols define how messages are packaged, sequenced, and recovered when something goes wrong.

SoupBinTCP — for Order Entry (TCP)
📦
Analogy: registered post. Every parcel gets a tracking number. If it doesn't arrive, the sender retransmits. Slow but guaranteed.
// SoupBinTCP frame header (3 bytes)
uint16_t length;    // payload size
char     type;      // 'S'=Sequenced, 'U'=Unsequenced
// Then the OUCH/binary payload follows

// Login handshake:
'L' → Login Request (username, password, session, seqnum)
'A' ← Login Accepted (session ID, seq start)
'J' ← Login Rejected (reason code)

Used by: ASX Trade OUCH, ASX 24, J-GATE OUCH

MoldUDP64 — for Market Data (UDP)
📻
Analogy: live radio broadcast. Everyone gets the signal simultaneously. If you miss a word, you missed it — but you can call a special "replay" phone line to catch up.
// MoldUDP64 packet header (20 bytes)
char     session[10];   // identifies the stream
uint64_t seqNum;        // first msg seq in this pkt
uint16_t msgCount;      // msgs in this packet
// Then: [uint16_t len][ITCH message] * msgCount

// Gap detection: if seqNum jumps, you missed msgs
// → Send retransmit request to TCP recovery port

Used by: ASX ITCH, J-GATE ITCH. NSE MTBT uses own framing; TAIFEX TMP uses own sequence header.

🔑 The sequence number is the heartbeat of the system Every message on every APAC venue carries a sequence number. If yours arrives and skips 47, 48, 49 — jumping from 46 to 50 — you have a gap. You cannot build an accurate order book until you recover those missing messages. Speed of gap detection = competitive edge.
Ask yourself

If UDP doesn't guarantee delivery, why not just use TCP for market data and be done with it? Think about what happens when 500 subscribers each need the same data simultaneously.

Market Data

UDP multicast: the radio broadcast that runs financial markets

Matching Engine trade executes → publish ITCH pkt one UDP send() multicast group 239.x.x.x L2 switch fans out in hardware Firm A FPGA feed handler recv in ~200 ns Firm B software feed handler recv in ~2 µs Firm C 500+ more subscribers Why NOT TCP unicast for market data? If 500 firms each need a TCP connection to the exchange for market data: • 500 × TCP connections = 500 × OS threads / sockets on exchange side • Each trade execution → 500 × send() calls • Slow firms cause TCP backpressure → exchange slows for everyone ✓ Multicast: ONE send() → hardware switch fans to all — O(1) overhead ⚠ Missed packet? → TCP gap fill (separate port)
🇦🇺 ASX ITCH on MoldUDP64. A/B redundant feeds. Gap fill via SoupBinTCP on separate port. Multicast groups per instrument class.
🇮🇳 NSE MTBT feed: dual A/B UDP groups. MBP-5 (top 5 levels) and MBP-20 (20 levels). TCP recovery port for gaps. Highest throughput in APAC.
🇯🇵 TSE FLEX Standard (top of book) and FLEX Full (full depth). Same dual A/B pattern. ~700k messages/sec peak. FPGA mandatory for latency-sensitive use.
Ask yourself

A/B feeds mean two identical streams. Why? Hint: think about what happens if a single UDP packet is lost by a faulty switch port.

Protocol Stack

Every message is an onion: the encapsulation stack

When a matching engine publishes one Add-Order ITCH message, the application payload is a ~36-byte record. By the time it leaves the NIC, it is wrapped in four more layers.

🧅
Analogy: a letter in an envelope in a courier bag in a shipping container. Each layer is stripped off at the appropriate destination. Your application only sees the letter — but every layer added overhead and metadata.
LayerWhat it doesOverhead
L7 ITCHAdd Order message fields36 bytes
L6 EncodingBig-endian binary, length prefix+2 bytes
L5 MoldUDP64Session ID, sequence number+20 bytes
L4 UDPPort numbers, checksum+8 bytes
L3 IPv4Source/dest IP, multicast group+20 bytes
L2 EthernetMAC addresses, EtherType+18 bytes
Total on wire~104 bytes

The three universal truths across all APAC venues:

1. TCP/UDP is universal Order entry always TCP. Market data always UDP multicast. Same on ASX, NSE, KRX, TAIFEX, JPX. The transport choice is invariant.
2. L7+L6 is what each venue brands and gates ITCH, OUCH, TMP, NNF, ETI, EXTURE+, FLEX — all of these are "just" different L7+L6 definitions running on the same standard IP stack below. The competition happens at the application layer.
3. L5 framing is where reliability lives SoupBinTCP, MoldUDP64, TMP session header — these handle sequence numbers and gap recovery. A bug here silently corrupts your order book. Always integrate L5 before testing L7.
🔑 Key insight on serialisation latency Sending 104 bytes at 10 GbE = 104 × 8 ÷ 10,000,000,000 = 83 nanoseconds just to put the bits on the wire. This is why firms pay for 100 GbE links.
Ask yourself

The OSI model was designed in the 1970s, before financial markets used computers. It was designed for robustness, not nanosecond latency. What would you redesign if you built a protocol stack specifically for high-frequency trading?

Exchange Internals

Inside the matching engine: a sorted list with a very strict personality

🍽️
Analogy: a restaurant queue. Best price gets served first. If two people offer the same price, first to arrive wins. No exceptions. No negotiation. This is price-time priority.
NIFTY 50 JUN 22000 CALL · Order Book SELL (Ask) side Price BUY (Bid) side 50 lots ₹ 245.50 — 120 lots ₹ 245.00 — 80 lots ₹ 244.75 — ← SPREAD: ₹0.25 (best ask − best bid) → — ₹ 244.50 200 lots — ₹ 244.25 75 lots — ₹ 244.00 310 lots New: BUY 30 lots @ ₹244.75 LIMIT Price crosses best ask → MATCH → Fills 30 lots vs asks @ 244.75. Execution report sent. ITCH 'E' published.

The order book is a data structure — a sorted map of price levels, each containing a queue of orders. At each venue the algorithm is identical:

Price-time priority Best price wins. Among same-price orders: earliest timestamp wins. No exceptions. This fairness guarantee is what makes markets trustworthy.
What triggers after a match: 1. Execution report → to both counterparties (TCP, their OE session)
2. Trade message → broadcast via market data (ITCH 'P' or equivalent)
3. Book update → published (ITCH 'D' delete + 'A' add for partial fills)
4. Trade report → sent to clearing/CCP for settlement
⚡ Latency inside the engine Arrowhead 4.0 (TSE): ~200 µs gateway-to-gateway
J-GATE 3.0 (OSE): ~100–300 µs depending on path
ASX Trade: ~40–80 µs in CoLo
NSE: claimed <10 µs for co-located clients
KRX EXTURE+: ~200–400 µs
TAIFEX: ~1–5 ms (less latency-sensitive venue)
Ask yourself

If two orders arrive at the matching engine in the same microsecond, who wins? How does the exchange decide? And what happens if two physically separated gateways each receive an order at "the same time" by different clocks?

Latency

Latency: the speed of light is non-negotiable

Inter-venue one-way latency (fibre, ~speed of light ÷ 1.5) SYD ASX Australia BOM NSE/BSE India TYO TSE/OSE Japan SEL KRX Korea TPE TAIFEX Taiwan ~85 ms ~60 ms ~100 ms ~1 ms ~2 ms ~110 ms

Light travels ~200,000 km per second in fibre (c ÷ 1.5 refractive index). You cannot change this. You can only choose:

1. Where you colocate A server inside ASX's SY3 datacenter has ~40 µs round-trip to the matching engine. From a Sydney office, ~5 ms. From London: ~300 ms. "Colo" is renting a server cage physically adjacent to the exchange's hardware.
2. Your transmission medium Standard fibre: 200,000 km/s. Hollow-core fibre: ~220,000 km/s. Microwave: ~290,000 km/s. Tokyo ↔ Seoul microwave shaves ~0.5 ms vs fibre. For arbitrage strategies that need both venues, this matters.
3. Your software stack Linux kernel: ~3–10 µs to process a packet. Kernel-bypass (DPDK, OpenOnload): ~300 ns. FPGA: ~50–200 ns. Each layer you eliminate saves latency — but adds engineering complexity and cost.
🌏
Why APAC is different from US/EU: In the US, CME (Chicago) and NYSE (New Jersey) are ~1,200 km apart — 6 ms one-way. In APAC, Tokyo–Sydney is 7,800 km — 110 ms one-way. Cross-venue arbitrage strategies that work in the US don't work across APAC without very different risk models.
Ask yourself

If microwave is faster than fibre, why doesn't every firm use it between every venue? What are the engineering and regulatory constraints?

Risk & Regulation

Pre-trade risk: the airbag you hope never fires

Every order must pass through a risk gate before it reaches the exchange. This is both a regulatory requirement and a self-preservation mechanism.

🚨
Analogy: the airbag. You never want it to fire. If it does, something went very wrong. But you will not drive a car without one — and regulators won't let you trade without the equivalent.
CheckCatches
Fat-finger filterOrder price > X% from last trade — e.g. BUY at 10× market price
Max order sizeSingle order exceeds configured lot limit
Max notionalOrder value in currency exceeds daily/session cap
Position limitsNet delta/gamma would exceed risk mandate
Msg rate limitOrders/second exceeds exchange-set throttle
Kill switchOperator manually halts all activity instantly
🇯🇵 Japan: TradeGuard (mandatory) OSE requires ALL order entry to pass through TradeGuard, their in-house pre-trade risk engine, before reaching J-GATE. This is implemented at the gateway level — you cannot bypass it. Firms must certify TradeGuard integration before going live.
🇮🇳 India: SEBI mandates SEBI (Securities and Exchange Board of India) requires algorithmic trading systems to have regulator-approved risk controls. NSE provides a "Tera Order Processing System" check. BSE has similar exchange-side controls via BOLT+/ETI.
🔑 The latency cost of safety An FPGA-based inline risk gate adds ~200 ns to the order path. A software gate adds ~2–5 µs. This is the latency cost of not losing millions in a runaway algorithm. Most serious firms accept it gladly.
💥
What happens without it: Knight Capital, 2012. A software bug caused their system to send 4 million unintended orders in 45 minutes. Lost $440 million. The firm collapsed in days. Pre-trade risk exists because this really happened.
Ask yourself

The risk gate sits between your strategy and the exchange. It adds latency. Competitors who remove risk controls trade faster. How do you design a system that is maximally fast AND maximally safe?

APAC vs US/EU

Why APAC is harder: the NDA problem and the ISV ecosystem

In the US, Nasdaq publishes its ITCH and OUCH specs publicly as free PDFs. CME publishes MDP 3.0. Any developer in the world can download and implement them.

In APAC, several venues gate their specs behind Non-Disclosure Agreements or member-only portals. This is deliberate.

NDA-gated specs in APAC 🇰🇷 KRX EXTURE+ — full binary spec: member portal only
🇯🇵 OSE J-GATE ITCH — gated (Genium INET lineage)
🇮🇳 NSE NNF — "trimmed" public spec; full protocol via ISV/vendor
🇮🇳 NSE MTBT — multicast spec partially gated
🇯🇵 TSE FLEX Full — gated; Standard version more accessible
Publicly available 🇦🇺 ASX ITCH/OUCH — full public PDFs ✓
🇦🇺 Cboe AU BOEv3 / PITCH — public ✓
🇹🇼 TAIFEX TMP v2.15.0 — public PDF ✓
🇮🇳 BSE ETI — FIX TC heritage; accessible ✓
🔐
Why exchanges gate specs: Revenue. An ISV pays the exchange for access, builds the connector, and sells it to 50 firms. The exchange earns from ISV certification fees and member data fees. Open specs would let firms build direct, cutting out this revenue.
The APAC ISV Ecosystem

Independent Software Vendors hold exchange certifications and sell pre-built connectors:

ISVRegion focusKnown for
Omnesys / TCSINNSE/BSE certified; widely used
ODIN (FT)INNSE OMS/DMA standard
KOSCOMKRKRX certified; only realistic path for foreign firms
Trading TechnologiesGlobalJP/AU certified; used by prop desks
Fidessa / IONGlobalFull APAC stack; buy-side focus
Ask yourself

If you were building a trading system to connect to KRX and the full spec is NDA-gated, what is your options path: (a) sign the NDA, (b) use an ISV, (c) reverse-engineer from packet captures? What are the legal and practical implications of each?

Reference

APAC side-by-side: the comparison matrix

Venue Native MD protocol MD transport Order Entry OE transport FIX version Spec access CoLo / DC
🇦🇺 ASX Trade ITCH UDP mcast + SoupBinTCP recov OUCH (binary) TCP · SoupBinTCP 5.0 SP2 EP196 ✓ Public PDF Equinix SY3
🇦🇺 ASX 24 MDP (ITCH-like) UDP multicast FIX only TCP · FIX session 5.0 SP2 ✓ Public Equinix SY3
🇦🇺 Cboe AU Multicast PITCH UDP + Spin/Gap Proxy BOEv3 (binary) TCP Cboe AU FIX ✓ Public PDF Global Switch SY
🇮🇳 NSE MTBT / MBP UDP mcast A/B + TCP recov NNF (binary) TCP via ISV bridge ⚠ Trimmed public NSE CoLo (BKC)
🇮🇳 BSE BOLT+ FAST/FIX UDP multicast ETI + IML/OMB TCP (Eurex T7) 5.0 SP2 native ✓ ETI spec public BSE CoLo (Fort)
🇯🇵 TSE Arrowhead 4 FLEX Std/Full UDP multicast (dual feed) Arrowhead native TCP (member API) 4.4 / 5.0 gated 🔒 Gated (member) TSE DC (Osaka)
🇯🇵 OSE J-GATE 3 J-GATE ITCH UDP mcast (gated) OUCH + OMnetAPI TCP · SoupBinTCP 4.4 / 5.0 🔒 Gated + TradeGuard OSE DC (Osaka)
🇰🇷 KRX EXTURE+ MDS · High-Speed UDP multicast (NDA) Proprietary binary TCP (NDA) 4.4 + tags 6000-9999 🔒 NDA member portal KRX CoLo (Busan)
🇹🇼 TAIFEX TMP MD UDP multicast TMP v2.15.0 TCP (seq-numbered) 4.2 / 4.4 hybrid ✓ Public PDF TAIFEX DC (Taipei)
Pattern recognition across the matrix Every venue: OE = TCP, MD = UDP multicast. FIX always exists but is slower. Binary OE protocols are venue-specific. Public spec = easier to connect; gated spec = need ISV or expensive NDA process.
Ask yourself

KRX's FIX dialect uses custom tags 6000–9999. The FIX standard reserves tags above 5000 for custom use. What problems arise when two different venues both invent their own custom tags and start at 6000?

Time & Synchronisation

Time is hard: nanoseconds, atomic clocks, and the Osaka problem

In a system where two orders arrive "at the same time," the matching engine must decide who was first. Its answer is only as good as its clock.

⏱️
Analogy: a race with bad stopwatches. If two runners cross the line within 0.001 seconds, the result depends entirely on how accurate and synchronised your timing equipment is. Financial exchanges face the same problem — at nanosecond scale.
PTP — Precision Time Protocol (IEEE 1588v2) Synchronises clocks across a network to <100 nanosecond accuracy using a GNSS (GPS/Galileo)-locked grandmaster clock that fans out timing via dedicated PTP-aware switches. Every server in the trading firm's colo cage syncs to this.
Hardware timestamping Instead of letting the OS timestamp a received packet (which adds µs of jitter), the NIC itself timestamps the moment the first bit arrives — in hardware, before the CPU knows the packet exists. This is how firms measure true "wire-to-wire" latency.
Timestamp formats across APAC venues
VenueTimestamp fieldEpoch
ASX ITCH6-byte ns since midnightSydney local
NSE MTBT8-byte ns epochIST (UTC+5:30)
TSE FLEX4-byte ms since midnightJST (UTC+9)
KRX8-byte µs epochKST (UTC+9)
TAIFEX TMP4-byte ms since midnightCST (UTC+8)

⚠ Every timezone and epoch is different. A system that correlates trades across APAC must convert all to UTC with nanosecond precision before comparison.

The Osaka problem When OSE moved its matching engine from Tokyo to Osaka in 2023, every firm that had fibre between Osaka and Tokyo for latency-sensitive strategies had to reroute. The move added ~0.7 ms one-way for cross-venue strategies. Infrastructure decisions at the exchange level cascade through every connected firm.
Ask yourself

NSE timestamps in IST (UTC+5:30) — a half-hour offset. Why is a half-hour timezone unusual globally? And what edge case does this create in a naive UTC conversion that adds exactly 5 hours?

Career

Where you come in: the engineering problems that remain unsolved

🔌 Connectivity Engineering

Build and maintain exchange connectors. Implement binary protocol parsers. Handle session reconnection, gap recovery, heartbeat timeouts. Test against exchange-provided simulation environments (CAST, UAT).

Skills: C++, Python, Wireshark, understanding of TCP/UDP, bit manipulation, big-endian parsing

📊 Market Data Systems

Build feed handlers that process millions of messages per second and maintain accurate order books. Detect and recover from gaps in µs. Distribute normalised data to dozens of downstream consumers.

Skills: C++, FPGA awareness, shared memory IPC, lock-free data structures, performance profiling

⚙️ Infrastructure & Latency

Measure tick-to-trade latency with nanosecond precision. Configure kernel-bypass networking. Tune CPU affinity and NUMA locality. Monitor PTP synchronisation. Benchmark hardware options.

Skills: Linux internals, networking, DPDK/OpenOnload, perf tools, hardware knowledge

🛡️ Risk Systems

Design and implement pre-trade risk controls. Write kill-switch logic. Build audit trails. Verify compliance with SEBI/FSA/ASIC/FSC regulations. Certify against exchange risk requirements (TradeGuard etc).

Skills: C++, understanding of financial regulation, testing under adversarial conditions

🔍 Market Microstructure

Analyse order book behaviour. Model spread dynamics. Study how APAC venues differ in maker-taker fees, tick sizes, position limits. Understand why the same strategy behaves differently on NSE vs TAIFEX.

Skills: Python, statistics, options pricing, data analysis, curiosity about market mechanics

📋 Certification & Compliance

Navigate exchange onboarding: member agreements, spec NDAs, UAT certification, production approval, ongoing audit requirements. Liaise with exchanges in JP, KR, IN. Translate bilingual specs.

Skills: project management, attention to detail, language skills (Japanese, Korean helpful), stakeholder communication

Final thought

Every protocol you learned today was invented by an engineer who faced a problem and designed a solution. ITCH replaced a text-based protocol in 2002. TMP is still being iterated. This field is not settled — it is actively being built by people your age in 10 years.

Discussion

Questions worth asking — and ones with no easy answers

Technical questions
If TCP guarantees delivery, why can a TCP order go missing? Think: what happens to an order if the TCP session drops mid-transmission?
Why is big-endian used in almost all APAC protocols? ITCH, OUCH, TMP, NNF — all big-endian. x86 CPUs are little-endian. What is the cost of this mismatch?
What is a "sequence number gap" and why is it so dangerous? Hint: an order book is built by replaying every event in order. What happens if you miss event #47?
How does an FPGA parse a binary protocol faster than a CPU? Think about what a CPU must do to execute code vs what an FPGA does in silicon.
Harder questions
Is it fair that co-located firms have a 100 µs advantage over retail traders? Should exchanges be allowed to sell proximity? Who should regulators protect?
KRX gatekeeps its spec. Does this harm the market? Or does it protect local firms from better-resourced foreign competitors?
If an algorithm loses $400M in 45 minutes (Knight Capital), who pays? Counterparties, the firm, market makers, regulators — and why should software engineers care?
AI is being applied to order book prediction. Is that legal? Front-running is illegal. Predicting from public market data is legal. Where is the line?
You pressed BUY.
50 microseconds later, you own an option. Every layer of this stack had to work — or you'd be staring at a rejected order and wondering which byte was wrong.