ACY Securities
Design System Architecture in a High-Regulation Retail Finance Environment
Five product lines. One design system. 150+ components governed to the strictest jurisdictional standard, eight regulatory updates absorbed without structural rework, 100,000+ traders served across 40+ regulated markets. This page is the project itself — the problem, the architectural decisions, the artefacts, the outcomes.
Looking for the story behind the work — the four-year arc, the chapters, the team changes, the lessons? That lives on a separate page: Career Journey: Four Years at ACY →
5 product teams. 0 shared design language.
Every regulatory update was a full redesign.
ACY.com, Finlogix, LogixTrader, ACY Connect, LogixPanel each had independent UI patterns — zero shared components
Each jurisdiction update (ASIC leverage caps, ESMA inducement bans) required individual redesigns across every platform
No systematic approach to ASIC/FCA/FINRA/ESMA disclosure hierarchy — risk warnings were placed inconsistently, prominence rules violated
A compliance directive arrived requiring platform-wide UI changes in 14 days. With fragmented systems, this was architecturally impossible.
Single token hierarchy and component governance system — Engineering teams could implement autonomously without design bottleneck
Compliance components are modular primitives — a new ASIC leverage cap slots into the Risk Warning component, propagates across all 5 platforms simultaneously
ASIC 12px minimum font size, SEC prominence rules, ESMA disclosure hierarchy — all encoded as component constraints, not reviewer checklists
Modular architecture meant the change touched 1 component, propagated to all affected surfaces across 5 platforms
Regulatory requirements aren't legal hurdles — they're design specifications. The architecture question wasn't "how do we handle compliance?" but "how do we make compliance components so modular that new regulations cost one component update, not a platform redesign?"
Three decisions that defined the architecture
These aren't the decisions that were obvious in hindsight. They're the ones where the alternative was equally valid — until the constraints forced a choice.
Encode compliance at the token level — not per product
What I tried first: Product-level overrides. Each platform maintained its own compliance variant of each component. ASIC version of a button for ACY.com, FCA version for the EU-facing product.
The ASIC leverage cap update in early 2022 required updating the same disclosure component in 5 separate places. What should have been one change took 3 days and still produced inconsistencies.
The fix: compliance requirements become constraints on the primitive, not variants of a component. The Risk Warning component doesn't have an ASIC variant — it is the ASIC requirement. When the regulation changes, one component updates. It propagates everywhere that component is used.
Decouple compliance components from visual components entirely
Alternative I considered: Fold compliance into visual components. Every button, every input field carries its own compliance variant logic baked in.
Visual language and regulatory language evolve at completely different rates. In 4 years at ACY, the brand refreshed twice. Regulations updated 8+ times. If compliance logic is embedded in visual components, every brand refresh becomes a compliance audit risk — you're touching regulatory-sensitive code for aesthetic reasons.
Separating them means: redesign the button, never touch the Risk Warning. Regulatory components form their own class. Legal signs off once; visual evolves independently.
Treat a regulatory directive as an architecture stress test, not a sprint
What my first instinct was: Scope the affected screens. I listed 40+ screens across 5 platforms that displayed leverage information.
Mapping 40 screens was the wrong unit. The real question was: how many components carry leverage display logic? The answer was one — the Leverage Indicator primitive. Everything else was rendering that primitive.
Updating one component propagated the change to all 40 screens simultaneously. We shipped within the deadline with zero downstream inconsistencies. The 14-day order became the proof that the architecture worked — but only because the decision to build it that way happened two years earlier.
The Complete Ecosystem: 5 Platforms, 1 Design Vision
Over 4 years, I've designed and shipped a complete trading ecosystem serving 100K+ traders across 40+ regulated jurisdictions. This goes beyond UI work. I collaborate directly with the CEO, CFO, CRO, and COO — from working with Legal on ASIC/SEC/FINRA requirements to designing SPAC investor materials. One underappreciated layer: roughly 90% of the logos on the group organisation chart — ACY Group, ACY Securities, ACY Capital, ACY Wealth, ACY Advisory, ACY Connect, Zerologix, Zerologix Taiwan, Logixel, and ACYLogix itself — are marks I designed as the group expanded across jurisdictions.
ACY.com
Design system foundation serving 5 platforms. Led design system architecture and component library (150+ components) that scaled across Marketing, Product, and Engineering teams.
ACY Connect →
FIX 4.4 API platform for prime brokerage clients (hedge funds, prop desks). Designed developer-facing documentation covering Tag 150/39 state machine, order lifecycle, and execution reporting for quantitative developers.
TradeX Terminal →
TradeX Hedge Fund →
Institutional UX research: Bloomberg Terminal analysis, portfolio manager interviews, extreme data density solutions. Not production, but shows terminal UX understanding.
Finlogix → / LogixTrader →
Real-time market tools (Finlogix) + proprietary trading terminal (LogixTrader). 1,000+ daily data points, modular widget system.
TradingCup → / ACYVerse →
Copy trading platform + gamified social features. 187K+ organic clicks (Source: GSC), 80% mobile usage.
iOS + Android
Consumer trading app for 100K+ users across 12 countries (2023–2025). Multilingual (AR/EN/VN/TH), 80% mobile-first user base, 5.0★ App Store rating.
Design System: 150+ Components — What That Actually Means
"150+ components" is a number that appears on my resumé and in several case studies. A finance-sector reviewer should ask: what governance backed it? Here is what the design system actually consisted of and how it was maintained:
- Foundations: color tokens, typography scale, spacing system (18 tokens)
- Core UI: buttons, inputs, dropdowns, modals, tables (42 components)
- Financial primitives: price tickers, P&L badges, leverage indicators, compliance status chips (31 components)
- Data visualization: chart containers, sparklines, heatmap cells (24 components)
- Layout: navigation, sidebars, grid containers, card shells (35 components)
- Figma master file (single source of truth) with published component library
- Naming convention: BEM-aligned (Block/Element/Modifier) for engineering handoff
- Monthly component audit — deprecated components flagged, usage tracked across files
- New component approval: documented use case + 3-product minimum reuse threshold
- Engineering sync: Storybook-adjacent documentation for the 42 most-used components
- 30–40% faster component implementation (Jira sprint velocity, n=30 sprints, Q3 2022–Q4 2023)
- Design-to-dev handoff: ~3 days/screen → ~1.5 days/screen (tracked across ~40 screens, Oct 2022–Oct 2023)
- Compliance component reuse: legal-approved UI patterns propagated to all 5 products from single Figma master — reducing compliance re-review from 5× to 1× per regulatory change
- New designer onboarding: 2-week ramp to first independent design contribution
Figma workspace with live component library available for review during interviews.
Measurable Outcomes
Impact Metrics
Measured Outcomes
Design System Evolution & Key Interfaces
Visual evidence of the design system foundation and platform interfaces built over 4 years.
Concept exploration range (2023–2024): how design direction evolved as the system matured — from exploratory layouts to locked, reusable patterns
Fixed layout: all data elements at equal visual priority. Day traders and swing traders see identical screens regardless of workflow differences.
Modular widget system: traders build their own workspace. Card sorting data (n=15) showed 5 distinct archetypes — each layout serves the mental model that card sorting revealed.
Time-to-insight: 4.2s → 2.5s (−40%). Critical task errors: 40% → under 5% (n=15 usability sessions, paired within-subjects. Remaining errors were non-blocking label misreads, not workflow failures.)
Buy trade order flow: compliance controls embedded at every decision point
Limit order placement: precision trading controls
Advanced charting interface: data visualization excellence
First-time user onboarding: compliance education without friction
Real-Time Data API: From Error State to Production
When the WebSocket price-feed API integration produced incorrect data states during high-volatility market events, I documented each iteration of the fix — not just the solution. These 4 screens show how I diagnosed, proposed, tested, and validated the corrected API response handling, collaborating with the backend team across a 2-day sprint.
I document the iteration process — not just the final state — because the reasoning behind each fix matters more than the pixel-perfect end result.
Technical Implementation: Code Prototypes
Beyond Figma mockups, I built interactive HTML/CSS/JavaScript prototypes to validate technical feasibility and accelerate engineering handoff. CodePen portfolio showcases button systems, 3D visualizations, and financial simulators that demonstrate design-to-code fluency.
What Didn't Work
The first attempt to push a design system update failed because I didn't align with engineering's sprint cycle. Read the full failure analysis.
User Research & Behavioral Analysis
I used Hotjar behavioral analytics (170+ sessions) to validate design decisions with quantitative evidence, convincing Legal and Engineering that choices were data-driven.
Key Behavioral Insight
Hotjar Session Analysis: Compliance Warnings
170+ sessions across AU/SG/UK markets showing user interaction with ASIC leverage warnings
Finding: Users spent 15–90 seconds reading warnings (3/5 engagement, 0/5 frustration). High-regulation market users (UAE, Kuwait) spent 32% more time on disclosures than low-regulation markets.
Design Decision: Made disclosures progressive rather than hidden. Layered content hierarchy with summary visible and details expandable. Users wanted clarity, not brevity.
Stakeholder Impact: When Legal questioned visual indicators vs. written disclosures, Hotjar heatmap analysis (170+ sessions) showed visual warnings achieved 85% interaction rate vs. 12% for text-only. Having that data made the conversation with Legal much easier than defending an opinion.
Privacy Note: All Hotjar sessions collected with explicit user consent. Data anonymized per GDPR and ASIC standards.
Hotjar Heatmap: CTA Performance Analysis
Primary CTA ("Start Trading") achieved 85/100 visibility score vs. competing elements at 50/100
Cross-Device Consistency: Desktop (515 sessions) vs Mobile (571 sessions) showed similar interaction patterns, validating responsive design system approach.
Beyond The Metrics: Real Traders, Real Stories
Meet the personas behind my design decisions — qualitative research methodology, user journey maps, and the human stories driving 40% workflow improvements.
ASIC KYC & Compliance Onboarding Architecture
Designing the live account registration flow required navigating ASIC's AFSL obligations directly — PDS, FSG, TMD, and suitability assessment aren't optional checkboxes, they're legal requirements with specific disclosure rules. Every screen in this flow was reviewed against ASIC RG 244 and coordinated with the compliance team before development.
Two-track ID verification: Fast-Track (few business hours, manual document review) vs Regular Process (24 hours, liveness check). Reducing friction while satisfying ASIC ID verification requirements.
Step 1: ASIC suitability profiling — trading platform selection, leverage, employment status, annual income, account type (Standard / Prozero / ISLAMIC). Required under ASIC's client suitability obligations.
Terms & Conditions step — explicit consent checkboxes for PDS, FSG, Account Opening Terms, Privacy Policy, and TMD. Each disclosure document is individually acknowledged per AFSL requirements.
Account type gate — Individual vs Corporate, with ASIC risk disclosure footer present on every registration screen.
Email OTP verification — split layout integrating the Tim Cahill brand ambassador campaign to reduce drop-off anxiety at the identity confirmation step.
Payment method architecture across jurisdictions — Australian BSB/Account, EU IBAN, and SWIFT flows mapped as a system. Designed to handle upload status states and jurisdiction-specific validation rules.
ACY Mobile App: Making Trading Accessible From First Download to First Trade
Project Timeline: June 2023 — December 2025
Led the full design of a consumer trading app serving 100K+ users across 12 countries. 80% of ACY's user base is mobile-first — many are first-time traders who've never used a desktop terminal. The goal wasn't to shrink a professional tool onto a phone. It was to design an experience where someone downloading a trading app for the first time could go from sign-up to their first trade in under 10 minutes — in their own language.
5.0★ on the App Store (2,000+ reviews) — consumer satisfaction, not just a metric. Users call out ease of use and multilingual support in top reviews.
Cross-platform launch: iOS and Android, serving users from Sydney to Dubai to Ho Chi Minh City.
The Consumer Challenge: Who Is the Mobile User?
ACY's desktop platform serves professional traders who want 6+ charts and 50+ instruments on screen. The mobile user is different: a 28-year-old in Dubai opening a trading app for the first time, a Vietnamese student exploring forex during a lunch break, an Australian retiree checking gold prices. The question wasn't "how do we fit the desktop on a phone?" — it was "how do we make someone who's never traded feel confident enough to place their first order?"
Progressive Disclosure
New users see 3 core actions: check a price, place an order, review their position. Advanced features (multi-chart layouts, custom indicators, order types) reveal as users grow. No one sees a 50-field screen on day one.
Multilingual-First Design
Full RTL Arabic support, Vietnamese, Thai, English — not just translated strings, but layouts that adapt: text expansion, culturally appropriate iconography, locale-specific number formatting (1,234.56 vs 1.234,56).
Trust Before Transaction
First-time traders are nervous about money. Face ID/Touch ID positioned as security (87% adoption in 90 days, per platform analytics). Every destructive action has a confirmation step. The emotional state of the user — not just the technical state of the system — drives the interaction design.
Consumer-Focused Features
- First-Time User Onboarding: Guided walkthrough from account creation through KYC verification to first deposit — designed to reduce the "I don't know what to do next" drop-off that kills most fintech funnels
- Biometric Login: Face ID/Touch ID as the default fast path — 87% adoption within 90 days (per platform analytics), reducing login friction for daily active users
- Contextual Notifications: Price alerts show where the price is relative to the user's position — informative without being anxiety-inducing. A "gold dropped 2%" notification without context is a relationship risk; with context ("still 4% above your entry") it's reassurance
- Offline Portfolio: Cached portfolio and trade history available without connectivity — critical for users on inconsistent mobile networks across APAC/MENA markets
- Gesture Navigation: Swipe between charts, pull-to-refresh, long-press for order modification — patterns users already know from consumer apps
The Consumer Onboarding Flow
Financial onboarding is where most consumer fintech apps lose users. ACY's mobile KYC needed to satisfy regulators in 5+ jurisdictions (ASIC, FCA, CySEC) while keeping a first-time user engaged through a multi-step identity verification. I designed the flow to feel like a conversation, not a compliance form.
Step 1: Personal Info — Clear progress indicator at top. One section at a time. Users always know how far they are and how much is left.
Step 2: Financial Background — Smart defaults and plain-language labels. "Annual Income" not "Declared Gross Revenue." Designed for someone filling this out on a bus, not at a desk.
Step 3: Experience Assessment — Regulatory requirement turned into a helpful moment. Honest answers route users to appropriate risk levels and educational content.
Step 4: ID Verification — Camera guidance overlay ensures document captures are clean on the first attempt. Reduces re-submission rates and support tickets.
Step 5: Review & Submit — Full summary before submission. Editable sections so users don't have to restart. Confirmation screen with clear next-step expectations.
Design Evolution: From Exploration to Production
V1 exploration (June 2023) — Early layout directions for Dashboard, Favourites, and Chart views. Testing which information hierarchy felt right for first-time users vs. experienced traders.
Full user journey map — Every screen and transition from app download through KYC, first deposit, and first trade. This became the single source of truth for engineering handoff and QA testing across 3 platforms.
Payment IA — The user sees "Add funds." Behind that button: branching logic across AU BSB, Malaysian bank transfer, UnionPay, EU IBAN, and SWIFT — each with jurisdiction-specific document requirements. Complexity hidden from the consumer, visible to the system.
Wireframe → Production across 6 consumer flows: Account List, Deposit, Payment Methods, Withdrawal, Internal Transfer, Transaction History. Every screen tested against the question: "would a first-time user know what to do next?"
Engineering handoff — Redline annotations for Journal Summary (Trades), covering Market Order execution variants. Precise specs reduce engineering interpretation and keep the consumer experience consistent across builds.
Compliance iteration — Red box marks a date/time picker design rejected by Legal for regulatory reasons. Consumer fintech means every UI decision passes through legal review. Documenting rejections is part of the process, not a failure.
ACY Mobile is a consumer product built under institutional constraints. 100K+ users across 12 countries, 5+ regulatory jurisdictions, 4 languages including full RTL Arabic — and a 5.0★ rating that says the complexity stays invisible to the person using it.
Want the story behind the work?
This page is the project — architecture, artefacts, outcomes. The four-year narrative — chapters, mistakes, team changes, lessons learned — lives on a separate page so the case study stays focused.
Zero Design-Related Compliance Violations — 2+ Years
Every public-facing design had Legal sign-off before shipping. Every ASIC, FCA, and ESMA requirement was encoded into the design system, not retrofitted after the fact. Over 2+ years (Q1 2023 – Q1 2025): zero design-related regulatory violations. Verifiable via ASIC Connect Public Register (asic.gov.au) and available to confirm during interview.
What I did to get there
What the design system did
- Risk warnings and disclosure UI patterns designed with Legal sign-off before production
- Consent flow architecture validated against ASIC RG227 requirements
- Multi-jurisdiction disclosure templates covering FCA, CySEC, FSCA simultaneously — built to the strictest standard, compliant everywhere
- 8+ regulatory updates (ASIC leverage caps, ESMA inducement bans, FCA SCA) shipped in 3–5 days each through component variants, not redesigns
Compliance as a Design Discipline
In regulated financial environments, a single disclosure error can result in material regulatory penalties. Working within ASIC/FCA frameworks over 2+ years — with compliance team sign-off on every public-facing design — builds the discipline of treating legal constraints as design inputs, not post-launch revisions.