Exchange members
Manage their firms, connectivity, users, risk settings, and trading information.
Menu
Case study
Exchange portal tools
At MEMX, I work on the portal used by market operations teams and exchange members. I started on the frontend and now build across interfaces, backend services, databases, architecture, and production delivery.
The portal
Who uses it and why
Market operations teams, trading firms, and exchange members use the portal to manage connectivity, firm and risk settings, trading queries, and user access.
Adding another market couldn’t mean copying the application again. Each one had different fields, rules, and features.
Portal tools
What I built in the portal
Over time, I built and maintained tools for onboarding, connectivity, firms, MPIDs, risk settings, trade queries, symbols, user access, and institution switching.
Market operations
Support member firms, switch between institutions, review configuration, and work across different markets.
Connectivity and onboarding
- Ports
- MPIDs
- Firms
- Member setup
Trading and risk
- Risk settings
- Trade queries
- Symbol tools
Access and support
- Users
- Roles
- Institution switching
Role progression
Frontend first then the rest of the stack
Build the frontend foundation
I started with onboarding and connectivity tools for ports, MPIDs, firms, risk settings, trade queries, symbols, and role-based access. I also built institution switching so market operations could support members without leaving the portal.
Make it reusable
When the first market-technology customer arrived, my manager scaffolded a database-driven market architecture. I built the corresponding frontend configuration system: reusable fields, feature flags, market visibility, validation, and request sanitization.
Work across the full stack
My role expanded into database, server, and UI work, along with production support and issues found by customers or QA. Depending on the feature, I now contribute at one layer or own the path from data and validation through the interface and release.
Frontend configuration
How the shared frontend worked
The active market selected database configuration and any rules that genuinely could not be shared. Those inputs became one platform context that reusable UI could turn into the correct fields, behavior, validation, and sanitized request.
The active market selects database configuration and market-specific classes. Both feed shared platform context, then a reusable frontend, and finally a sanitized request.