Developer-facing institutional infrastructure. A misconfigured FIX message doesn't throw a user-facing error — it produces a million-dollar position sizing error, silently, while the market moves. Designed the documentation system, credential management, and onboarding flows that made integration unambiguous.
ACY Connect Platform. Global Institutional Connectivity Infrastructure
The design problem: make a technically unforgiving API accessible to institutional developers without sacrificing depth. This is structurally identical to Stripe's API docs, Bloomberg's B-PIPE SDK, or Plaid's developer portal — different protocol, same constraint: reduce time from credential receipt to first successful transaction, without ambiguity.
ACY CONNECT — SHIPPED 2025
FIX session state machine — annotated sequence diagrams
Tag 150/39 conflict docs — one wrong value = fill error
Reject scenario matrix across 4 error types
Anti-pattern warnings preventing gateway overload
67% support ticket reduction · 3→1 week integration time
STRUCTURALLY IDENTICAL TO
Stripe — payment intent state machine, error taxonomy
Bloomberg B-PIPE — field precision, corrupted risk if wrong
Twilio — voice/SMS state flows, anti-pattern guidance
✅ Live production infrastructure since 2025. 12+ institutional clients — hedge funds, prime brokers, prop desks. Documentation live at fix-api-docs.acyconnect.com. I served as Visual & Information Architect alongside Tech Lead and QA — they owned protocol logic, I owned developer experience: documentation architecture, credential flows, and systematizing engineering specs into navigable institutional documentation.
Platform Design: Institutional User Flows
Beyond the FIX API documentation, ACY Connect is a full institutional platform — covering the public marketing site, client onboarding, compliance review, and an internal operations portal for Relationship Managers. My role was to map these workflows, define the information architecture, and design the screens. The technical specifications behind each form field came from the Tech Lead and QA team; my job was to make complex institutional processes navigable.
Digital · Client-Facing
Institutional Onboarding Journey
① Landing Page
Institutional positioning with partner social proof — oneZero, Goldman Sachs, J.P. Morgan. Designed to build trust before the first click.
② Create Account
Modal overlay keeping the user in context. Low-friction entry — only essential fields at this stage to avoid drop-off before commitment.
③ KYC Registration
Multi-step form with visible progress stepper. Regulatory requirements translated into a structured, non-intimidating flow — each step scoped to one context (company, shareholders, approvals).
④ Confirmation
Clear end state — application submitted, next steps set expectations. Reduces support enquiries by answering "what happens now?" before the user asks.
Operations · RM-Facing
KYC Review Dashboard + API Credential Setup
KYC Review — RM Dashboard
The RM reviews incoming institutional applications and makes an approval decision. Two clear outcomes — Activate or Reject — each triggering an automated email to the client. The design challenge was giving RMs enough information to decide confidently without overwhelming the interface with compliance detail.
Create API Connection — Self-Service
Previously, setting up API access required an email chain with the ops team. I designed a self-service flow: accounts list → empty state with a clear first-action CTA → configuration form. The empty state is intentional — it removes anxiety for first-time setup and guides the RM step by step.
Operations · RM-Facing
Quote API Setup + IP Whitelist Management
Design decision — consistent patterns across connection types: Quote API, Trade API, and IP Whitelist are three distinct technical functions — but the RM managing them isn't a developer. I unified all three under the same 3-step pattern (list → empty state → form) so that once an RM learns one flow, the others feel immediately familiar. Reducing the cognitive overhead of tool-switching was the primary UX goal here.
Operations · RM-Facing
Credential Retrieval + Account Configuration
Credential Retrieval
When a client's developer needs connection details, the RM retrieves them directly from the portal — no IT ticket, no waiting. All relevant credentials grouped on one screen with copy actions. The design reduces a task that previously took days to under a minute.
Trading Mode Configuration
Account-level trading settings that affect how client positions are managed. The challenge was that the difference between modes is highly technical — my approach was a before/after comparison layout so the RM can see the effect of each choice without needing to understand the underlying mechanics.
System Design
The Documentation System
The answer to the integration problem wasn't a document — it was a documentation system. A structured information architecture with explicit design rules governing how five distinct user types, each entering the integration journey at a different stage of technical depth, find exactly what they need without filtering through content that doesn't apply to them.
User Type
Enters At
Information They Need
Success State
PM / BD
Introduction
Capability overview — what ACY Connect does, who it's for
Evaluation decision made
DevOps / Infra
Credentials & Verification
IP, Port, SenderCompID, TargetCompID — no protocol depth required
Network connection verified via Telnet
FIX Engine Dev
Session Messages
State machine, Logon 35=A / Heartbeat 35=0 / TestRequest flows
FIX session established and stable
Quant Developer
Trading Messages
Tag 39/150 state mapping, partial fill lifecycle, cancel/reject flows
Live price feed streaming without gateway overload
Visual Grammar — Diagram Design Rules Applied Consistently Across All 7 Pages
Yellow box = stable system state. Developers track connection lifecycle progression at a glance.
→ ←Arrow direction = message sender. Wrong direction = wrong implementation. Non-negotiable in FIX.
loop [ ]Loop annotation = recurring sequence. Prevents treating heartbeat as a one-time event.
alt [ ]Alt conditional = error-handling path. Shows what happens when the happy path fails.
Figma workspace — all 7 documentation pages in one file. Shared layout rules, consistent visual grammar, designed as a single coherent system. Structural decisions made once, applied across every page.
1. The Design Constraint: Why FIX Documentation Can't Afford Ambiguity
There's no error message. There's just a wrong trade.
FIX Protocol is machine-to-machine. When a hedge fund's algorithm sends a $50M order, there's no UI, no validation toast, no undo. A misread Tag 39 OrdStatus — one field in one message — and the system double-counts a fill, or assumes an order is open when it's been cancelled. The position is wrong before anyone notices.
That constraint defined every design decision in this documentation system. There is no tolerance for "probably fine." The user isn't browsing — they're implementing production infrastructure. The documentation either gives them exactly what they need, or they ship a bug into a live trading system.
My job wasn't to explain FIX. It was to make a technically unforgiving protocol legible to five different user types — each entering the integration journey with a completely different mental model and a completely different definition of "done."
Who Was I Designing For?
Prime Brokers
Aggregating liquidity from multiple providers simultaneously. They care about routing logic, not onboarding — they need the credential and session pages to be frictionless so their ops team can get off the phone.
Hedge Funds
Quant developers implementing algorithmic strategies. They read Tag 39/150 state tables like source code. My job was to make those tables scannable, not explain what they mean.
Proprietary Trading Firms
Infrastructure engineers setting up low-latency connections. They need the verification section — Telnet command, port, SenderCompID — and nothing else. Every extra paragraph costs them attention they don't have.
2. Information Architecture: How the System Is Structured
Each of the seven pages is designed around a specific user at a specific moment in their integration journey — not a reading sequence, but an entry-point system. A DevOps engineer setting up network access never needs to open Trading Messages. A quant developer implementing order execution skips Credentials entirely. The architecture is designed so that every user lands in the right layer, at the right depth, without filtering.
FIX API Documentation. Credentials & Verification System Flow
Documentation Architecture: 4-Layer Information Hierarchy
I designed the FIX API documentation as a progressive disclosure system that balances exhaustive technical detail with scannable navigation:
Layer 1: Getting Started (Credentials & Verification)
Decision: Used sequence diagrams with "loop" and "alt" annotations (borrowed from UML standards) to show iterative heartbeat exchanges and conditional flows (e.g., "If no response → send TestRequest"). Institutional developers expect this notation.
Layer 3: Trading Messages (Order Execution)
Target User: Quantitative developers implementing trading algorithms Content: NewOrderSingle (35=D), ExecutionReport (35=8) with partial fills, OrderCancelRequest (35=F), message field specifications
Decision: Provided exhaustive field tables for each message type (e.g., ExecutionReport includes OrdStatus, ExecType, CumQty, LeavesQty). Institutional developers need exact field mappings. Ambiguity causes integration failures.
Layer 4: Market Data & Quoting (Streaming Quotes)
Target User: Market data engineers implementing real-time pricing feeds Content: MarketDataRequest (35=V), subscription types, snapshot vs. incremental refresh, unsubscribe flows
Decision: Emphasized "Single Symbol Recommendation" to prevent overloading ACY's FIX gateway. Institutional clients often request hundreds of symbols simultaneously, causing performance degradation. Documentation explicitly warns against this anti-pattern.
3. Session Flow Diagrams
Administrative Messages. Session Flow State Machine
The Core Design Problem: A State Machine Has No Natural Reading Order
FIX sessions are stateful — the system moves through Disconnected → TCP Connect → Logon → Active → Heartbeat as a sequence, not a menu. Traditional documentation presents this as prose and tag tables. A developer reads left to right and has to reconstruct the sequence in their head. I designed sequence diagrams so the state progression is visible before a single word is read.
Every Design Element Encodes a Rule
Yellow boxes = stable states. When a developer is debugging a failed connection at 2am, they need to know exactly which state they're stuck in. Color makes that instant — no reading required.
Arrow direction = sender. In FIX, which party sends which message is non-negotiable. A reversed arrow in an implementation causes a session rejection. The diagram makes the direction unambiguous so it can't be misread.
Loop annotations prevent the single most common FIX implementation mistake: treating heartbeat as a one-time event. The bracket makes it clear it repeats, indefinitely, for the life of the session.
Alt conditional flows document what happens when the happy path fails — TestRequest, no response, disconnect. Most FIX documentation omits failure paths. This one doesn't, because 30% of integration support tickets came from developers who didn't know what to do after a missed heartbeat.
4. Trading Messages: Order Execution Flow Documentation
Trading Messages. Order Execution Lifecycle with Partial Fill Handling
Order Flow Sequence: Why Partial Fills Matter
A critical institutional requirement: orders don't always fill instantly. A hedge fund submitting a $50M equity order might receive:
ExecutionReport (OrdStatus=A. Pending): Order accepted, waiting for liquidity
The trading messages diagram explicitly shows three ExecutionReport responses for a single order, documenting the partial fill lifecycle that retail platforms never encounter (retail orders are typically small enough to fill instantly).
Principal Signal: Precise FIX Tag Mapping (35=8)
A major institutional integration hurdle is the conflict between Tag 150 (ExecType) and Tag 39 (OrdStatus). I designed the documentation to explicitly map these state transitions:
Partial Fill State Tag 150=1 (Trade), Tag 39=1 (Partially Filled). Triggers UI update for CumQty while keeping the order active.
Cancel/Replace State Tag 150=E (Pending Replace), Tag 39=1 (Partially Filled). Ensures trader sees the modification in-flight without assuming the old order is dead.
Why this matters institutionally: Poorly documented tag conflicts cause algorithmic trading systems to double-count fills or miss "Pending" transitions. This precision is what distinguishes a "Design Document" from an "Institutional Implementation Specification."
Order Cancellation & Rejection Handling
The diagram also documents cancel reject flows. What happens when a client tries to cancel an order that's already filled. This is an edge case in retail platforms but a daily occurrence in institutional trading (algorithms cancel 60%+ of submitted orders based on market microstructure changes).
5. Market Data Subscription: Real-Time Quote Streaming
Market Data Messages. Subscription Management & Quote Streaming
Subscription Lifecycle Documentation
Market data subscriptions in FIX are stateful connections. Once subscribed to EUR/USD quotes, the client receives continuous price updates until explicitly unsubscribing. This differs from REST APIs (request/response) and requires careful documentation of subscription management.
Key Documentation Elements
MarketDataRequest (35=V): Initial subscription message with SubscriptionRequestType=1 (Subscribe to request market data)
MarketDataSnapshotFullRefresh (35=W): Server response with current bid/ask prices. Includes MDUpdateType=265 (full refresh) vs. incremental updates
Subscription Reject Handling: Documents what happens if client requests invalid symbols. Returns MarketDataRequestReject with reason codes
Unsubscribe Flow: Explicit documentation of SubscriptionRequestType=2 (Unsubscribe). Prevents memory leaks in client applications that forget to clean up subscriptions
Usage Guidelines: Single Symbol Recommendation
A critical design decision: prominently displaying the "Single Symbol Recommendation" warning. Institutional clients often request 500+ symbols in a single MarketDataRequest. Overwhelming ACY's FIX gateway and causing quote delays for all clients.
Why: This isn't a technical specification. It's operational guidance preventing platform abuse. The documentation proactively educates clients on best practices, reducing support load (previously, 40% of integration support tickets were related to excessive symbol subscriptions).
The Output: Live Documentation System
7 documentation pages, shipped and live. Each designed around a specific user entering the integration journey at a different stage of technical depth.
Design Process: Translating Engineering Logic into Visual Architecture
The Tech Lead and QA Engineer owned protocol correctness. I owned developer experience. In practice that meant sitting in hours of technical deep-dives and emerging with one question: what does a developer need to see, at exactly which moment, to make the right decision without asking anyone?
The breakthrough was treating the FIX state machine as a design problem, not a documentation problem. A state machine has entry points, transitions, and failure modes — the same structure as a user flow. Once I mapped the protocol's logic onto that frame, the visual grammar became obvious: stable states need to be instantly recognizable, transition paths need to be unambiguous, and every error state needs to answer "what do I do now?" before the developer has to ask.
How the Design Actually Got Built
Discovery: Finding the Friction Before It Became a Bug
Every session with the Tech Lead and QA started with a protocol spec and ended with me asking "what goes wrong when a developer misreads this?" That question surfaced the real documentation gaps — not the parts that were hard to understand, but the parts that were easy to misunderstand. Those are different problems with different design solutions.
Architecture: Five Users, Five Entry Points
The PM evaluating ACY Connect needs a connectivity overview. The DevOps engineer needs the Telnet command and port number. The quant developer needs the partial fill state table. None of them benefit from reading each other's section. I designed the IA so users land at the right depth — not via navigation, but via the structure of the content itself.
Visual Grammar: Making State Visible at a Glance
Color signals state, not category. Yellow marks stable states — TCP established, FIX session active — so developers always know where they are in the lifecycle. Arrow direction shows sender. Loop annotations prevent the most common mistake: treating a recurring sequence as a one-time event. Every diagram decision was tested against a single question: can an engineer read this in 10 seconds and know exactly what to implement?
Validation: Engineering Catches What Design Misses
I cycled diagrams through the Tech Lead and QA 3–4 times per section. One correction that changed the design: my initial heartbeat diagram showed TestRequest sent immediately after a missed heartbeat — wrong. The correct behavior is to wait 2× the heartbeat interval first. That's not a copy edit. That's a design error that would cause a developer to implement incorrect timeout logic. Technical accuracy isn't a QA step — it's a design requirement.
7. The Knowledge Loop: Protocol → Terminal Design
Documenting FIX protocol isn't a passive exercise. You cannot produce a reject scenario matrix or a Tag 39/150 state mapping without internalizing the rules deeply enough to reason about them independently. That internalization didn't stay inside the documentation — it became the design foundation for TradeX Institutional Terminal and TradeX Hedge Fund.
Neither TradeX project has shipped to production. But the design logic and interaction rules in both are derived directly from FIX constraints — not invented, not borrowed from Bloomberg screenshots. The protocol defines what's possible; the terminal design explores how a human trader interacts with it.
FIX Protocol Constraint→TradeX Design Decision
Tag 39 OrdStatus partial fill lifecycle
Pending (A) → Partially Filled (1) → Filled (2). Each state is a distinct moment with different trader actions required.
Active Positions panel — real-time P&L
Position panel tracks CumQty vs. LeavesQty live. A partial fill changes the P&L before the order is complete — the UI had to reflect an in-flight state, not a binary open/closed.
Session state machine (Disconnected → Active)
A FIX session isn't binary. TCP connect, Logon, Heartbeat, and Active are four distinct states — each with different failure modes.
SOR Routing bar + connection status
TradeX shows venue connectivity state per-exchange, not a single "connected/disconnected" toggle. Modeled on the session lifecycle: partial venue failure is a real operational state, not an edge case.
Anti-pattern: bulk MarketDataRequest overload
Institutions requesting 500+ symbols simultaneously degrades the gateway for all clients. Single-symbol rule is a governance constraint, not a preference.
L3 Order Book — single-symbol, depth-first
TradeX shows one instrument's full depth (L3) rather than a multi-symbol dashboard. This isn't a UX preference — it's a protocol constraint translated into product scope.
Cancel reject: 60%+ of institutional orders are cancelled
Algorithms cancel most of their submitted orders based on microstructure changes. Cancel/replace handling is a primary workflow, not an error state.
F9 Execute + keyboard-first interaction model
Keyboard shortcuts for execution (F9), sort (Ctrl+R), and order ladder (Alt+O) reflect a workflow where speed of cancel/modify matters as much as speed of submit.
TradeX — Protocol Knowledge Applied to Terminal UI
Tag 39Positions table tracks Status, P&L, Stop/Take — reflecting partial fill lifecycle. A position can be open, partially filled, or pending cancel simultaneously.
SessionPortfolio Risk Matrix aggregating 80+ positions — the management layer that sits above FIX execution. Each position row represents completed Tag 39 fill cycles.
MarketDataLive Markets view — instrument list with real-time price feed. The single-symbol anti-pattern constraint from FIX documentation shapes this into a watchlist model rather than a bulk-subscription dashboard. Users select one instrument at a time for deep data.
Good documentation isn't the absence of complexity — it's complexity organized around how a specific person thinks at a specific moment. The five user types in this system don't share a mental model. A DevOps engineer and a quant developer are reading the same product with completely different questions. The design that serves both is the one that never forces either of them to filter out content that isn't theirs.
The visual grammar did the enforcement
Arrow direction, color coding, loop annotations, anti-pattern warnings — these aren't decorative. They carry technical meaning that used to exist only in engineering discussions. Encoding them into the diagrams meant developers could implement correctly without asking clarifying questions. That's what dropped integration time from 3 weeks to 1.
The knowledge didn't stay in the docs
Designing the FIX state machine taught me how institutional order flow actually works — partial fills, cancel/replace in-flight, session heartbeat lifecycle. That knowledge became the design foundation for TradeX. The terminal interaction rules, the keyboard-first execution model, the L3 order book scope — all derived from FIX constraints, not Bloomberg screenshots.
Data Source: Internal ticketing system exports (Jira-type platform). Full ticket logs available for verification under NDA.
Attribution: This metric reflects documentation quality improving developer self-service, validated through ticket category analysis showing 85% of reduced tickets were "How to implement FIX connection" queries—directly addressed by new documentation structure.
Integration Time Reduction (3 weeks → 1 week): Based on client feedback surveys sent to first 8 institutional clients post-documentation launch. Clients reported "time from credential receipt to first live trade" averaged 21 days (pre-docs) vs. 7 days (post-docs).
Institutional Client Count (12+): Publicly verifiable via ACY Connect partnerships with oneZero, Centroid Solutions, and PrimeXM (visible on acyconnect.com homepage). Specific client names confidential under NDA.
Project Details
Timeline2025 (Production Launch)
CollaborationTech Lead & QA Led-Specs
CompanyACY Securities
Target UsersInstitutional Developers, Prime Brokers
Institutional Client Intelligence: Live SEC EDGAR Data
ACY Connect’s institutional clients — hedge funds, prime brokers, prop desks — don’t trade in isolation. They operate against a backdrop of fundamental data: earnings filings, ownership changes, 8-K material events. This panel pulls real, live filing data directly from SEC EDGAR’s public API. The kind of context an institutional onboarding PM would reference when assessing a new client’s trading strategy.
Live SEC Filing DataCACHED
fetching…
⇧ Select a company to load real SEC EDGAR filing data
Form TypeFiledDescriptionSource
Live Demo · FIX 4.4 Protocol
The full order lifecycle in nine messages
A FIX session isn't a UI pattern — it's a state machine. Every institutional order travels through a sequence of messages governed by field-level rules. A misconfigured tag doesn't throw a readable error — it silently misprices a position. This animator shows the exact message sequence from Logon through Fill, with real FIX 4.4 tag/value pairs at each step.
Animates automatically · Click any message to inspect full tag list · All data simulated
FIX 4.4 Session · Order Lifecycle
Client System
49=CLIENT_OMS
ACY Connect Gateway
56=ACYCONNECT_GW
Liquidity Pool
56=LP_PRIME_01
Message Log
Tag Inspector —
Portfolio threads
Where this case study sits in the larger web
Every problem we solve for clients has multiple valid approaches — different costs, different ROI, different risk profiles. These threads show how the approach on this page compares to others in the portfolio.
Thread
Regulatory Routing & Disclosure
How upstream regulation and macro prints become downstream product defaults and Legal-safe disclosure.
