From FIX Sessions to SIEM Alerts: A Pre-SOC Career on the Trading Desk
Why four years on a Korean securities trading desk maps to Tier 1 SOC work
I'm not a SOC analyst yet. I'm a Master of Cybersecurity student at RMIT, transitioning from a four-year career on a Korean securities trading desk where I owned the FIX-protocol connections to overseas brokers and exchanges.
This post is about why those four years are closer to Tier 1 SOC work than most people would guess, and which specific skills carry over.
What the Trading-Desk Job Actually Was
For cybersecurity readers without finance background:
- Role: Global Equity / Global Stock at Korean securities firms (Hanwha, IBK)
- Stack: Bloomberg EMSX for execution, Bloomberg Terminal for market data, FIX protocol for broker connectivity
- Markets: Primarily NYSE and NASDAQ, via US broker partners
- What I owned: The system connections between our firm and overseas brokers. Every cross-border order traveled over FIX sessions to broker engines and onto exchanges.
When those connections broke, the impact was immediate. Minutes of trading downtime in a real-time market.
A typical incident loop:
- Trader reports an order rejection or stuck trade
- Pull the FIX session log on our side
- Identify the failing message: what tag, what value, what response
- Match against the broker's session log (different format, different timestamps)
- Form a hypothesis: sequence number mismatch, malformed tag, broker-side rejection, exchange-side rejection
- Brief internal IT, the broker's tech support, and the affected trader simultaneously
- Drive resolution until the trade flows again
Some days quiet. Some days five sessions down.
What the SOC Job Is
For trading-desk readers without security background:
- Role: Tier 1 SOC analyst, first responder to alerts in a SIEM (Splunk, Sentinel, Elastic)
- Stack: SIEM dashboard, EDR console, threat intel platforms, ticketing system
- What you own: The investigation pipeline for incoming alerts. Triage, escalate, document.
A typical incident loop:
- Alert fires, say, anomalous PowerShell execution from a finance laptop
- Pull the alert raw event in SIEM
- Identify the trigger: what process, what command, what destination
- Pivot to related logs: endpoint, network, identity
- Form a hypothesis: false positive, expected admin activity, suspicious but unconfirmed, confirmed compromise
- Brief endpoint team, IR lead, business owner if escalating
- Drive resolution: contain, remediate, document
Same loop, different domain.
Anatomy of a FIX Message vs. a SIEM Event
Concrete comparison.
A FIX New Order Single:
8=FIX.4.4 9=178 35=D 49=BUYSIDE 56=BROKER 11=ORDER123 55=AAPL 54=1 38=1000 40=2 44=150.00 10=128
Tag-by-tag:
35=D: message type (D = New Order Single)49/56: sender/target firm IDs11=ORDER123: client order ID, the unique reference55=AAPL: instrument symbol54=1: side (1 = buy)38=1000: quantity44=150.00: limit price
When something breaks, you read the broker's response, usually 35=8 (Execution Report), and check 39 (order status) and 58 (free-text reason). A typical rejection: 35=8 39=8 58="Order quantity exceeds daily limit". You read it, you know what to fix.
Now a Windows authentication failure event in SIEM:
EventID=4625 Account=svc-backup LogonType=3 Source=10.20.30.40 FailureReason=Bad Password Time=2025-12-01T09:30:00Z
Field-by-field:
EventID=4625: event type (failed logon)Account: what identity triedLogonType=3: authentication context (3 = network)Source: where it came fromFailureReason: why it failed
Different vocabulary. Different domain. Same task: scan structured machine output, extract the meaningful fragment, hold context while pivoting.
The Six Carryovers
1. Reading Logs Under Pressure
Both jobs are about parsing structured output, fast. The FIX message above and the SIEM event above demand the same skill: identify the relevant fields, ignore the noise, form a hypothesis from limited information.
2. Multi-Party Coordination
- FIX side: Broker session down. Brief internal IT, the broker's NOC, and the affected trader. Three audiences, three vocabularies, all need updates.
- SIEM side: Suspected compromise. Brief endpoint team, IR lead, business owner.
The skill isn't writing emails. It's holding parallel investigation threads while keeping each stakeholder appropriately informed without leaking unconfirmed conclusions.
3. Time-Sensitive Triage
- FIX side: Each minute of session downtime is lost trades and reputational damage with brokers.
- SIEM side: Each minute an attacker has unchecked is expanded blast radius.
In both jobs, you don't have time to do everything. You triage. You pick the highest-signal next step.
4. Pattern Recognition Across Time
- FIX side: "This rejection looks like the one last Tuesday, same MsgSeqNum gap pattern, same broker."
- SIEM side: "This alert looks like the campaign from last month, same beacon interval, same C2 IP range."
Memory of past incidents is a SOC analyst superpower. Trading desks build the same muscle.
5. Escalation Hygiene
- FIX side: Critical session down with regulatory implications, escalate immediately to ops manager and compliance.
- SIEM side: Critical alert with confirmed indicators, escalate to IR lead and comms lead.
Junior analysts often hesitate to escalate. Trading-desk experience burns that hesitation out. The cost of waiting on a real incident is too obvious.
6. Documentation as a Default
- FIX side: Every session outage gets a postmortem: root cause, timeline, action items.
- SIEM side: Every confirmed incident gets a report: root cause, IOCs, recommendations.
Both jobs reward the same writing discipline: dispassionate facts first, opinions clearly labeled, recommendations actionable.
Translating Trading-Desk Vocabulary to Security
Recruiter keyword searches don't match finance-side phrasing. The work is identical; the language doesn't map naturally. Four years of trading-desk vocabulary, translated:
| Trading-desk phrasing | Security translation |
|---|---|
| Reconciled trades across systems | Detected and investigated transaction anomalies across 3 systems |
| AML / KYC flagging on suspicious counterparties | Triaged compliance alerts using established detection criteria, escalated confirmed cases |
| Audit trail review during quarter-close | Performed log analysis across financial systems to verify integrity controls |
| Tracked broker connectivity issues | Monitored cross-system communication for anomalous patterns, identified root cause for service-impacting events |
| Resolved order rejection with broker | Investigated rejected transactions by parsing FIX session logs, identified root cause via tag-level analysis, coordinated remediation across multiple parties |
The right column is what recruiter searches and ATS filters look for. The left column is what I would have written without thinking.
This is one of the unspoken parts of career transitions. You're not learning a new job. You're learning a new vocabulary to describe work you already did.
A Walk Through a Real FIX Incident
The shape of a typical incident on the desk:
08:32 KST: A trader on the equity desk pings. An order to buy 5,000 shares of a US stock just rejected. He needs it filled before the US open at 22:30 KST.
Step 1: Pull the FIX log on our side. Search by client order ID (11=ORDER789432). The session log shows:
Out: 35=D 11=ORDER789432 49=BUYSIDE 56=GOLDMAN 55=AAPL 54=1 38=5000 40=2 44=178.50 ...
In: 35=8 11=ORDER789432 39=8 58="Order quantity exceeds firm DEA limit" ...
The broker rejected with 39=8 (Rejected) and free-text 58="Order quantity exceeds firm DEA limit". DEA = Direct Electronic Access. Some brokers cap single-order quantity for risk reasons.
Step 2: Confirm against the broker side. Their FIX session log shows the same exchange sequence, same timestamp window. Not a connectivity gap, an actual broker-side risk reject.
Step 3: Brief the trader. Two options: split the order into smaller chunks (3 × 1,667 shares), or escalate to the broker's prime services team to lift the cap for this trade. Trader picks split because it's faster.
Step 4: Brief our IT. Document the reject pattern. If this is a new limit, trading desk needs to know going forward. Internal IT logs it as a new operational rule for the broker.
Step 5: Fill the order. Three smaller orders execute cleanly. Total time from initial complaint to last fill: 11 minutes.
That's a clean case. The messy ones involve sequence number gaps, broker session restarts mid-trade, or exchange-side clock drift causing rejections during pre-market. Those take longer and pull in more parties.
The cognitive task throughout: read structured machine output, isolate the failing field, decide between a software fix, a process fix, or an escalation. The same task SOC analysts perform when an EDR alert fires, a Sysmon event chain looks suspicious, or an authentication log shows a gap.
What an Operational Day Looked Like
For context, the rhythm of the role:
- 07:00–07:30 KST: Pre-open checks. Confirm all FIX sessions to overseas brokers are up. Run a heartbeat scan against the venue list. Review any overnight tickets from US/EMEA market hours.
- 07:30–09:30: Korean market open coverage. Domestic trading systems plus any overnight-positioned international orders.
- 09:30–17:00: Day-shift mix. Trader requests, ad-hoc connectivity issues, vendor calls about upgrades, contract paperwork for new broker integrations.
- 17:00–21:00: Asia close, EMEA open. Different broker pool, different session profiles, partial overlap.
- 21:00–01:00 KST: US pre-market and open coverage when market events warranted it.
The constant: at any point, a session could go down and the response window was minutes, not hours. That's where the operational instincts come from. Reading logs fast, briefing internally and externally in parallel, knowing when to escalate.
What Doesn't Carry Over
Honest gaps:
- Adversarial mindset: FIX issues are accidents (broker bug, sequence mismatch, network blip). SOC issues can be deliberate humans actively evading detection. Different cognitive frame.
- Network protocol depth: I knew FIX. I didn't know TCP retransmits, DNS tunneling, TLS internals, the foundational network stack a SOC analyst leans on daily.
- Cryptography: Didn't need it on the desk. Need it in security.
- Tool fluency: Splunk, Sentinel, KQL, Volatility, Wireshark. Vocabulary I had to learn from zero.
The carryover is the cognitive shape of the work. The vocabulary, tooling, and threat model. Those need real study.
How I'm Closing the Gaps
The lab work that fills in the missing pieces:
- CCD (Certified CyberDefender): Golden Badge, score 90. Full DFIR loop with realistic enterprise scenarios.
- BTL1 (Blue Team Level 1): phishing, threat intel, digital forensics, SIEM, IR.
- BTLO labs: practical hours across forensics and SIEM.
- Master of Cybersecurity at RMIT.
- This blog. Every walkthrough I publish forces me to re-derive the lab without notes. That's the test of whether I really understood it.
The plan: combine the operational instincts I built in finance with the technical depth I'm building now. Land Tier 1 SOC. Then move up.
The One-Liner
If you can read a FIX session log under pressure, brief three stakeholders simultaneously, and write a clean postmortem the next morning, you can do Tier 1 SOC analyst work. The lab tools you can learn. The instincts take years.
Some career transitions are clean breaks. This one is mostly just renaming the protocol.
