ACY Connect
Institutional FIX API Platform
Enterprise-grade B2B trading infrastructure serving institutional clients, prime brokers, and liquidity providers via FIX 4.4 Protocol. Designed comprehensive FIX API documentation, credential management systems, and developer onboarding flows for institutional connectivity at global scale.
ACY Connect Platform. Global Institutional Connectivity Infrastructure
✅ Production Work: Real Institutional Infrastructure
Unlike my TradeX concept project, ACY Connect is live production infrastructure serving institutional clients globally since 2025. This case study demonstrates real-world institutional design experience. not speculative concepts, but deployed systems managing millions in daily transaction volume via FIX Protocol connectivity.
Executive Summary
In 2025, ACY Securities launched ACY Connect. an institutional B2B trading platform targeting prime brokers, institutional clients, and liquidity providers requiring FIX Protocol connectivity. Unlike retail platforms (LogixTrader, TradingCup), ACY Connect serves professional counterparties executing $10M–$500M+ daily order flow.
I served as the Visual & Information Architect in a high-stakes partnership with our Tech Lead and QA Engineer. While they defined the core technical protocol logic and "drawings," I was responsible for the end-to-end design of the platform's developer experience: FIX 4.4 API documentation architecture, credential management workflows, and systematizing complex engineering specs into a professional-grade documentation platform for institutional engineering teams.
Why ACY Connect Demonstrates Private Bank Readiness
While ACY Securities serves 100K+ retail traders ($1K–$100K accounts via LogixTrader), ACY Connect targets institutional clients with fundamentally different expectations:
ACY Connect Clients
- Hedge funds executing $10M–$500M daily order flow via FIX Protocol
- Prime brokers requiring multi-prime setups with 99.99% uptime SLAs
- Prop trading firms running HFT algorithms with sub-100ms latency requirements
- Zero tolerance for errors. one misconfigured FIX message = $1M+ position sizing error
Private Bank / UHNW Clients
- Ultra-high-net-worth individuals with $10M+ AUM portfolios
- Family offices managing $50M–$1B+ multi-generational wealth
- Institutional-grade expectations for portfolio analytics, compliance reporting, and risk management
- Bloomberg/Aladdin-quality UX. anything less signals lack of seriousness
The Parallel: Institutional-Grade Reliability Standards
While Private Bank clients aren't executing $500M/day trades, they share the same expectation as ACY Connect's hedge fund clients:
- Zero-error compliance. One SEC/FINRA violation destroys trust permanently
- Exhaustive documentation. "It just works" isn't enough; clients need to understand why it works
- Professional-grade UX. Consumer fintech patterns (confetti animations, gamification) signal unseriousness
- Institutional collaboration. Designers must speak the language of quant developers, compliance officers, and risk managers
Bottom line: ACY Connect proves I've already designed for users with $10M+ AUM-equivalent expectations — the same institutional rigor demanded by UHNW wealth management clients. This isn't theoretical; it's production infrastructure serving real institutional counterparties.
1. What is FIX Protocol (and Why It Matters Institutionally)
The Industry Standard for Institutional Trading
FIX (Financial Information eXchange) Protocol is the global standard for electronic trading communication between institutions. Think of it as the "language" that trading systems speak to each other. when a hedge fund's trading algorithm sends a $50M equity order to Goldman Sachs' execution system, they're communicating via FIX messages.
Why retail platforms don't use FIX: Retail traders interact via web/mobile UIs (my LogixTrader work). Institutional clients bypass UIs entirely. their algorithms connect machine-to-machine via FIX Protocol, executing thousands of trades per second without human intervention.
ACY Connect's role: Provides FIX 4.4 connectivity for institutional clients who want to route orders through ACY's liquidity pools (oneZero, Centroid Solutions, PrimeXM). These clients are hedge funds, proprietary trading firms, and multi-asset brokers. not retail investors.
Institutional Client Profile
Prime Brokers
Multi-prime setups aggregating liquidity from ACY + other providers. Need FIX connectivity for seamless order routing across multiple liquidity sources.
Hedge Funds
Algorithmic trading strategies requiring low-latency FIX execution. Typical order flow: $5M–$100M daily across forex, commodities, and indices.
Proprietary Trading Firms
High-frequency trading operations needing sub-100ms execution latency. FIX connectivity enables direct market access without manual intervention.
2. FIX API Documentation
The core design challenge: How do you enable institutional engineering teams to integrate ACY's FIX API without requiring extensive support calls? This is different from retail product design. the "users" are quantitative developers and trading system architects who need exhaustive technical specifications, not simplified consumer UX.
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)
Target User: Institutional project managers evaluating ACY Connect
Content: System overview diagram, credential parameters (IP Address, Port, SenderCompID, TargetCompID, Password), network verification via Telnet
Decision: Included a visual "System Overview Diagram" showing Client FIX Engine → ACY Connect connection flow with state transitions (Disconnected → TCP Connect → TCP Connection Established → Logon → FIX Session Established → Heartbeat Exchange → Session Active). This diagram reduces cognitive load for developers unfamiliar with FIX session lifecycle.
Layer 2: Session Messages (Administrative Flow)
Target User: FIX engine developers implementing connection logic
Content: Session flow diagram (Logon 35=A, Heartbeat 35=0, Test Request 35=1), message sequence details, disconnect handling
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
Challenge: Making State Machines Scannable
FIX Protocol is fundamentally a state machine. the system transitions between states (Disconnected → Connected → Logged In → Active) based on message exchanges. Traditional FIX documentation presents this as text tables, but I designed visual sequence diagrams to make state transitions instantly parseable.
Visual Design Decisions
- Yellow State Boxes: Highlight stable states (TCP Connection Established, FIX Session Established, Session Active). developers can visually track progression
- Directional Arrows: Show message direction (Client → ACY Connect vs. ACY Connect → Client). needed for debugging connectivity issues
- Loop Annotations: "loop [Heartbeat Exchange]" clearly indicates recurring sequences. prevents developers from thinking heartbeat is a one-time event
- Alt Conditional Flows: "alt [Test Request Flow]" shows error-handling paths. documents what happens if heartbeat fails (send TestRequest, wait for response, disconnect if no reply)
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
- ExecutionReport (OrdStatus=1. Partially Filled): $20M filled, $30M remaining
- ExecutionReport (OrdStatus=2. Filled): Entire $50M filled
Solution: Exhaustive Order Status Mapping
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).
Why this matters institutionally: A poorly documented partial fill flow causes algorithmic trading systems to double-count fills (thinking each ExecutionReport is a new order). potentially causing $10M+ position sizing errors. Exhaustive documentation prevents this failure mode.
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).
6. Design Process: From Engineering Specification to Visual Architecture
A unique challenge: institutional FIX APIs are defined by technical-logic-first engineering. I initially approached the FIX 4.4 protocol as a learner, not an expert. Through intensive discovery sessions, our Tech Lead and QA Engineer provided the core "drawings" — the deep technical logic and boundary conditions.
Their engineering "brain power" defined the rules, but the breakthrough happened when I realized I needed to map their mental models into visual flows. I deconstructed their explanations into a service-level state machine, ensuring every session heartbeat and execution report (35=8) was visually intuitive. This rigorous logic-mapping process didn't just build a better document; it fundamentally shaped my understanding of institutional market microstructure — knowledge I later applied to the TradeX terminal design.
Design Workflow: From Engineering Specs to Documentation
Step 1: Technical Partnership & Spec Review
Collaborated directly with the Tech Lead and QA to digest FIX message schemas (field IDs, data types, required vs. optional fields) and server behavior documentation. My focus was identifying the "user friction" hidden within the technical density.
Step 2: User Journey Mapping
I mapped the typical institutional developer journey: 1) Evaluate ACY Connect (needs overview), 2) Set up credentials (needs verification steps), 3) Implement FIX session (needs flow diagrams), 4) Test trading (needs message examples), 5) Go live (needs troubleshooting guide). This became the documentation's information architecture.
Step 3: Visual Diagram Design (My Core Contribution)
Translated text specifications into sequence diagrams using Mermaid/PlantUML syntax (later rendered as images). Added state annotations (yellow boxes for stable states), loop indicators, and alt conditional flows. This visual layer reduced integration time from avg. 3 weeks → 1 week (based on client feedback surveys).
Step 4: Iterative Review with Engineering & QA
Submitted draft diagrams and UI specs to the Tech Lead and QA for technical accuracy review. Iterated 3-4 times per section. e.g., Engineering corrected my initial heartbeat diagram which showed TestRequest sent immediately after missed heartbeat (actually should wait 2x heartbeat interval). Final documentation merged technical correctness with visual clarity and QA-validated edge cases.
Scaling the Blueprint: Transforming Tech Lead & QA Drawings into a Systematic Design Ecosystem
7. What ACY Connect Demonstrates for Institutional Finance Roles
ACY Connect is the missing piece in my portfolio's institutional positioning. While TradeX proves I understand institutional UX concepts, ACY Connect proves I've shipped institutional infrastructure to production.
🎨 TradeX (Concept)
- Portfolio Risk Matrix (80+ funds)
- Level 2 Order Book visualization
- Multi-chart orchestration
- Proves: I understand institutional UX requirements
✅ ACY Connect (Production)
- FIX 4.4 Protocol implementation
- Live institutional connectivity
- Developer documentation architecture
- Proves: I've shipped institutional infrastructure
Core Transferable Skills for Institutional Finance Roles
1. Technical Documentation for Developers
Institutional platforms like Goldman's Marquee and BlackRock's Aladdin require extensive API documentation for internal quantitative developers. ACY Connect FIX documentation demonstrates that I've designed technical communication systems for professional engineers — not just consumer UX.
2. B2B Platform Design
ACY Connect serves institutional counterparties (prime brokers, hedge funds) — the same user profile as institutional trading platforms. This B2B experience differs fundamentally from retail product design (where users tolerate ambiguity; institutional clients demand exhaustive specifications).
3. Cross-Functional Collaboration with Engineering
Institutional finance designers don't work in isolation. they collaborate with quantitative developers, infrastructure engineers, and compliance teams. ACY Connect demonstrates my ability to translate engineering specifications into usable documentation while maintaining technical accuracy through iterative review cycles.
8. Business Impact & Institutional Adoption
📐 Measurement Methodology
Integration Support Ticket Reduction (67%): Tracked via internal ticketing system over 6-month measurement period.
Measurement Period & Formula:
• Baseline (Oct-Dec 2024): avg. 40 FIX integration support tickets/month (3-month baseline, n=120 tickets total)
• Post-Documentation (Jan-Mar 2025): avg. 13 tickets/month (3-month observation, n=39 tickets total)
• Calculation: Reduction% = ((Baseline - Post) / Baseline) × 100 = ((40-13)/40) × 100 = 67.5%
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.
Data Verification Commitment
All quantitative metrics (67% support ticket reduction, 3 weeks → 1 week integration time, 12+ clients) follow a three-tier verification framework: publicly verifiable evidence, analytics screenshots (available upon request), or NDA-protected data with disclosed methodology.