Exchange members
Managed firm details, connectivity, users, risk settings, and trading information.
Menu
Case study
Exchange portal tools
At MEMX, I built portal tools used by market operations teams and exchange members. My role grew from frontend development into backend services, databases, architecture, and production delivery.
The portal
One portal, different markets
Market operations teams, trading firms, and exchange members used the portal to manage connectivity, firm and risk settings, trading queries, and user access.
Each market brought its own fields, rules, and features. Copying the application for every new market was never going to scale.
Portal tools
What I built
I built and maintained tools for onboarding, connectivity, firms, MPIDs, risk settings, trade queries, symbols, user access, and institution switching.
Market operations
Supported member firms, moved between institutions, reviewed configuration, and worked 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
From frontend ownership to full-stack delivery
Built the frontend foundation
I started by building 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.
Turned it into a reusable platform
When the first market technology customer came on board, my manager established the database-driven market architecture. I built the frontend system around it, including reusable fields, feature flags, market visibility, validation, and request sanitization.
Expanded across the stack
My role grew to include database, server, and UI work, along with production support and fixes surfaced by customers and QA. Depending on the feature, I either contributed at a specific layer or carried the work from data and validation through the interface and release.
Frontend configuration
How one frontend supported multiple markets
The selected market loaded its database configuration along with the few rules that could not be shared. Together, those inputs gave the frontend everything it needed to render the right fields, apply the right behavior, validate the data, and build a clean 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.