Regulated Finance
Design Practice
Five years designing financial products in regulated environments — compliance UI architecture, enterprise design systems, and institutional-grade data visualization across ASIC, FCA, FINRA, and ESMA jurisdictions. This is my domain.
Regulated finance isn't a domain you learn in a workshop. It's a set of hard constraints — disclosure hierarchy, audit trail requirements, risk prominence rules — that only become legible after you've designed something that almost violated them. Five years of that builds a different kind of judgment.
Finance Design Competencies
Five practice areas — what I've shipped, what I own, and why each matters at institutional scale.
| What I've Done | Why It Matters at Institutional Scale | Evidence / Project |
|---|---|---|
|
Designed for 100K+ retail traders Global trading platform serving 40+ countries, handling thousands of concurrent users during market hours |
Large-scale system design (1K+ concurrent users) Institutional platforms (Bloomberg Terminal, FactSet) serve fewer users but with higher data density. My experience scaling to 100K users demonstrates I can handle institutional 1K-user workloads with more complex data requirements. |
ACY Securities Ecosystem |
|
ASIC, FINRA, FCA, GDPR compliance design Built 150+ pre-tested compliance UI components. No design-related regulatory violations over 2+ years across multiple jurisdictions. |
Compliance-First Design & Audit Records Institutional firms face serious regulatory risks. I design clear audit records where every UI interaction generates a compliant event log. My framework treats regulations as design specs, ensuring reliable compliance across all products. |
Compliance Architecture |
|
40+ countries, multi-language platform Designed for cross-timezone operations, multi-currency support, region-specific compliance variations |
Global institutional platform design Global financial institutions face the same challenges (regional compliance, timezone-aware UX, multi-currency risk reporting). My experience designing for 40+ countries demonstrates readiness for global institutional products. |
Global Expansion |
|
Copy Trading product (TradingCup) Algorithmic strategy distribution platform. Risk visualization (Sharpe Ratio, Max Drawdown, Win Rate) for retail investors. |
Investment advisory products (Robo-Advisors, Wrap Platforms) Institutional wealth management platforms face the same challenge — translate quantitative strategies into investor-friendly UX. TradingCup demonstrates my ability to design progressive disclosure for complex financial products. |
TradingCup |
|
Real-time market data platform (Finlogix) Designed for traders processing 1,000+ data points daily. 40% faster market analysis through information architecture redesign. |
Multi-Monitor Trading Terminals Professional terminals require synchronized multi-monitor displays. I architect systems using BroadcastChannel/SharedWorkers to ensure instant data sync across trader desks. I design for dense information layouts (1,200+ data points) while keeping them manageable for traders. |
TradeX / LogixTrader |
|
Design system for 5 product lines 150+ components, unified visual language across web, mobile, trading terminals. 30–40% faster engineering implementation. |
Design system for multiple products Major financial institutions have dozens of products requiring unified design language. My experience scaling a design system across 5 products demonstrates I can manage multi-product design systems with engineering and product teams. |
ACY Design System |
|
C-Suite collaboration (CFO, CEO, COO, CRO) Strategic partner for SPAC/IPO materials, investor presentations. Translated design metrics into CFO-friendly ROI language ($500K cost savings, $350K productivity gains). |
Market Workflow Integration (B2B API) Institutional roles require understanding of order flow. I've designed B2B API systems that translate market protocol details into clear UI states, ensuring traders see order execution and status changes accurately. |
ACY Connect B2B |
Key Insights: What Transfers, What Doesn't
Core Design Capabilities
- Regulatory Design Architecture: ASIC, FCA, FINRA, ESMA — built 150+ compliance components that absorbed 8+ regulatory updates without structural rework.
- Information Architecture for Dense Data: Designed for traders processing 1,000+ data points per session. Complex financial data requires thoughtful organization, not simplification.
- Multi-Product Design System: One design language across 5 product lines, 3 engineering teams, zero redesign cycles for shared components.
- C-Suite Stakeholder Alignment: SPAC/IPO materials for CFO/CEO audiences. Translating design rationale into ROI language is a core skill, not a bonus.
- Cross-Functional Influence: Legal said "no" to my first KYC flow redesign. I came back with a compliance-annotated spec that Legal signed off and Engineering shipped in one sprint.
2022 → 2026: How the Practice Was Built
Navigated ASIC compliance from day one. Multi-asset trading mechanics, KYC/AML flows, leverage disclosure architecture across 40+ countries. Not onboarding — immediate deep water.
Built the compliance component architecture that absorbed every subsequent regulatory change without rework. Unified 5 disconnected product codebases under one design language.
SPAC/IPO investor materials, C-suite product strategy input, design system governance across 3 independent engineering teams. Role expanded without a title change.
The questions that define regulated finance design don't change based on whether the user is a retail trader or an institutional portfolio manager:
- How do you display real-time risk data without creating cognitive overload?
- How do you design disclosure hierarchy that satisfies regulators without breaking the user flow?
- How do you scale a design system across products with divergent requirements and no centralized governance?
- How do you tell a PM their feature idea would violate a disclosure rule — and make them agree with you?
These are the questions I've been answering in production, at scale, for five years.
Private Banking UX: My Domain Research
Honest disclosure: I have no prior private banking experience. The content below represents my own research into the domain — not firsthand work. I want to be transparent about that while demonstrating that I've done the work to understand where my production experience directly maps to private banking constraints.
The goal of this section: show that I understand what makes private banking UX distinct from what I've built — so the relevant capabilities transfer on day one, not month six.
🏦 Relationship Managers
From research: power users managing 30–100 UHNW client relationships simultaneously — needing advisor dashboards, client activity feeds, compliance task queues, and portfolio snapshots in one authenticated workspace.
Closest thing I've built: LogixPanel CRM — advisor-facing internal tool for managing 100K+ trading accounts across regions. Structurally similar: role-based access, audit trails, workflow prioritization.
💎 UHNW Clients ($10M+ AUM)
From research: financially sophisticated but time-constrained — they don't want simplification, they want precision, trust signals, and digital experiences that honor the relationship they have with their advisor.
Closest thing I've built: Christie's luxury real estate platform for $50M+ property buyers — same principle: digital tools enhance the broker relationship, they do not commoditize it.
📊 Portfolio & Investment Counselors
From research: specialists translating multi-asset portfolios into client-facing reporting — performance attribution, risk decomposition, alternatives exposure — in formats accessible to wealthy but non-expert clients.
Closest thing I've built: TradingCup's investor-facing dashboard — translating algorithmic data (Sharpe Ratio, Max Drawdown) into plain-language risk summaries via progressive disclosure.
Design Principles I Believe Would Apply
Hypotheses based on research — I expect to challenge and refine these once I'm inside the actual domain.
Digital tools should make advisors more effective, not reduce their role. Every feature should ask: does this strengthen or weaken the human relationship?
UHNW clients don't need dumbed-down UI — they need confidence in data accuracy. Every number shown must be sourced and timestamped. Ambiguity destroys trust at this level.
Role-based data access is the foundation, not a feature. The same RBAC principle I applied to LogixPanel scales directly to private banking confidentiality requirements.
My ASIC disclosure design system (pre-tested, modular components) would adapt to SEC/FINRA private banking requirements — though I'd need to learn the specific private banking regulatory nuances.
What I Haven't Built Yet — Specifically
These are gaps in firsthand production experience, not in domain understanding. I've researched each area — but research is not the same as having shipped it.
- Wealth reporting UI (performance attribution, risk decomposition across asset classes)
- Multi-asset portfolio visualization (equities, fixed income, alternatives, derivatives in one view)
- UHNW client self-service portals (document vault, proposal review, e-signature flows)
- Advisor CRM designed specifically for private banking relationship cadence
- Private banking product structure: separately managed accounts, alternatives, trust overlays
- How UHNW clients actually distinguish between self-service and advisor-mediated actions
- SEC/FINRA private banking disclosure requirements vs. the ASIC retail framework I know
- Internal culture, workflow terminology, and team structures at institutional firms
I joined my previous employer with no FinTech background. Within 18 months I was leading compliance-architecture design decisions across 40+ jurisdictions. That trajectory wasn't about learning speed — it was about applying systems thinking to an unfamiliar domain. These gaps are real and specific; the foundational systems work is already done.
How I'm Already Bridging These Gaps
Studied public UX patterns from wealth management platforms and private banking documentation. Analyzed entity-switching UI, consolidated reporting layouts, and advisor dashboard patterns from publicly available sources.
LogixPanel CRM (role-based access, audit trails, multi-account management), TradingCup investor dashboard (risk data translated for non-expert audiences), Christie's luxury platform (relationship-enhancing digital tools for high-value clients) — all map directly to private banking design constraints.
Shadow 2–3 Relationship Manager sessions before touching design. Map the gap between how advisors describe their workflow and how the current digital tools support it. That's the fastest path to informed design decisions.
💎 B2C Private Banking: Portfolio Evidence Map
Private banking digital roles are explicitly B2C — designing for UHNW clients, not just internal advisors. Across five production and concept projects, I've built and documented specific private banking client-facing design capabilities:
Portfolio down 15% scenario — show attribution with context, not just the loss. First client login architecture — establish institutional trust before account numbers. Progressive disclosure for quarterly reports — headline verdict, then attribution, then holding detail on demand.
Confidence ≠ data volume: more metrics made allocation decisions worse, not better. The first loss design problem: pre-allocation screens showing historical drawdown patterns. Same design challenges at retail scale ($1K–$50K) transfer directly to UHNW portfolio selection ($1M–$50M+).
Designed the AI Explainability Trail to meet SEC Predictive Analytics rules. Confidence intervals over false precision. Counterfactual interrogation to justify trade suggestions. The exact human-AI boundary design that institutional discretionary management requires.
87% Face ID adoption within 90 days (platform analytics) — authentication as trust signal, not friction. Context-specific feature hierarchy: UHNW client at 7am wants net performance vs benchmark, not full dashboard. Push notifications that carry relationship framing, not just raw data alerts.
The opportunity cost problem at $5M+: visceral visualization shifts the mental model from savings to portfolio thinking. Progressive disclosure without anxiety: impact first, then mechanism. Onboarding as belief transformation, not product tour.
The throughline: I design for the emotional state of a UHNW client, not just the information state of the system. The distinction between a portal that displays wealth and one that reinforces the advisory relationship — that is what private banking B2C digital design is. These projects demonstrate I understand it before I've shipped it in the institutional context.
Institutional Terminal Landscape: What I Know, What I've Analyzed, What I'd Build Differently
This isn't brand recognition ("I've heard of Bloomberg"). It's a pattern-level analysis of how the dominant institutional platforms make specific design trade-offs — and what those trade-offs reveal about their user models.
Command-line first (AMBER input bar) with panel-based layout. Typography-driven density — 8–10px mono font at native resolution. Colour used only for semantic purpose: amber for navigation, cyan for live data, red/green for direction. Zero decorative elements.
Learnability was sacrificed entirely for power-user density. Onboarding requires Bloomberg-specific training. The HELP HELP command (calls a Bloomberg human rep) is the UX fallback. This only works if you can assume users have 40+ hours of training. Bloomberg can; most other platforms can't.
The command syntax is opaque by design — institutional knowledge moat. But this also creates accessibility problems for analysts with visual impairments and creates cognitive overhead for multi-lingual teams. A well-structured command palette (⌘K pattern) could preserve power-user speed while surfacing commands discoverably.
Workstation model with customisable widget layout. More navigational affordances than Bloomberg; searchable component catalogue. Lighter visual density by default, with power-user modes available. Active pivot toward web-based delivery (FactSet Digital Solutions).
Better UX than Bloomberg = easier for new analysts, worse for power desk traders who've trained to Bloomberg's patterns. FactSet wins in research-heavy buy-side firms (asset managers, hedge funds doing fundamental work). Bloomberg wins in sell-side and trading desks where speed and market data depth matter more than usability.
The customisable widget model creates a "blank canvas" problem — every installation looks different, which means institutional onboarding defaults to whatever the last person configured. A "role-based default layout" system (Portfolio Manager / Risk Officer / Research Analyst presets) would reduce first-time setup friction without sacrificing customisability.
Post-Eikon rebrand emphasises web-native, lighter visual language. Workspace uses a card/panel model more familiar to modern SaaS users. Stronger at fixed income screeners, news integration, and FX overlay — weaker in equities order execution depth compared to Bloomberg.
The web-first rebrand solved the legacy desktop client problem but created a transitional identity crisis — Workspace looks modern but lost Bloomberg's information density and Eikon's deep FI data reputation. Currently occupying an awkward middle ground: less powerful than Bloomberg, less focused than FactSet, but cheaper and more accessible.
The card-based layout model introduced for accessibility is creating cross-asset correlation blindness — when equities and FI data live on separate cards without cross-referencing, multi-asset portfolio managers lose the contextual link. A shared data canvas (not cards) with semantic linking between instruments across asset classes would restore the contextual awareness that Bloomberg's dense multi-panel layout achieves differently.
The Pattern Across All Three
Every institutional terminal is in a slow-moving design war between expert density (Bloomberg's bet) and modern usability (FactSet and LSEG's bet). No platform has resolved this tension yet — they've all chosen a side.
The generational transition is accelerating this: analysts who grew up with Figma, Notion, and Linear are joining desks that run Bloomberg. The mismatch between their ambient UX expectations and terminal interfaces is creating real friction — and a real design opportunity.
The answer isn't "make Bloomberg prettier." It's building a system where density is always available but never required — where novice analysts can operate at 40% density and power traders can operate at 100% density using the same data architecture. TradeX explores this with its 4-layer typography hierarchy and role-configurable panel layouts.
This is a hypothesis, not a proven solution. I'd validate it through structured observation of how analysts with 0–2 years of terminal experience actually navigate vs. how 10+ year veterans navigate.