Back to works Case Study
Broker TechFlutter AppLaravel CRM

MeeFX

Multi-tier financial brokerage ecosystem. Integrates a custom Laravel CRM backend with a Flutter trader mobile app, MetaTrader API managers, and multi-tier affiliate tracking.

Visit Live Website
MeeFX Interface Showcase

01 — Overview

Overview

a. Brokerage Ecosystem Concept

MeeFX is a modern retail forex and contracts-for-difference (CFD) broker platform. To facilitate trading, retail clients require a secure portal (Trader Cabinet) to open trading accounts, configure leverage, deposit funds, request withdrawals, and track affiliate rebates. Administrators require an audit CRM to verify user IDs, monitor balances, check logs, and manage payment methods.

We built the ecosystem around two decoupled components: meefx-crm, the core Laravel CRM hosting the central relational database, REST APIs, and admin interfaces; and meefx-app, the Flutter mobile app providing traders with instant access to their cabinet, wallet balances, and trading accounts.

b. CRM & Client App Architecture

Our developers designed the communication flow between the mobile application and the CRM backend via secure REST API controllers. When a client performs actions on the Flutter app (e.g. creating a new account), the app issues a request via the Dio client. The CRM validates the request session token and contacts the MetaTrader server API.

The MetaTrader connection utilizes token-based auth headers. To create an account, TradingAccountController first calls the MT manager API on /auth/token using the server's username and password. It retrieves the access token and posts the user's details (name, group, leverage, currency, and generated password hashes) to /api/accounts with the Authorization: Token [token] header, dynamically returning the login credentials to the client.

Timeline Aug 2020 – Mar 2024
Role Full-Stack Architecture & Mobile Development
Technologies
Laravel 9FlutterGetXDioMetaTrader REST APIPostgreSQLTailwind CSSRedisSentryOneSignal
Tools
FigmaVS CodeDBeaverPostmanGit
Responsibilities
  • Developed central Laravel CRM administrative panels and custom API modules
  • Designed multi-tier partner tree models and automated commission calculations
  • Built cross-platform Flutter mobile client using GetX state management
  • Integrated payment routing and gateways (PayPal, Neteller, Local Exchanger, Crypto)
  • Implemented Know Your Customer (KYC) document upload and validation pipelines
  • Coded MetaTrader 4/5 account manager client utilizing REST token auth headers
  • Set up Sentry error monitoring and push notifications via OneSignal

02 — Problems & Challenges

Problems & Challenges

a. Real-Time Balance Synchronization

Traders frequently deposit and transfer funds between their CRM cabinet wallets and their active MT4/MT5 trading accounts. Keeping account balances and free margins updated across platforms without delaying page loads poses a massive challenge.

We solved this by implementing real-time transfer handlers in the CRM (updateFund). When a user requests a wallet-to-MT4 deposit, the backend checks local wallet balances, and then posts a credit or deposit transaction to the MT manager API endpoint (/api/accounts/{number}/deposit). For MT4-to-wallet transfers, the system queries the manager API to check the free margin (/api/accounts/{number}) to verify that the free margin covers the requested amount before writing balance mutations.

b. Multi-Tier IB Commission Calculation

Calculating affiliate commission splits up to 5 levels (Introducing Broker trees) for thousands of closed trades can easily exhaust PHP server memory and trigger database timeouts.

We resolved this by writing an optimized scheduler service (SchedulerController). The job queries the MT server daily via /api/accounts/{number}/orders to retrieve closed trade tickets. It validates anti-fraud metrics—calculating hold durations to filter out immediate opening and closing cycles (scalping/churning). For validated trades, the system fetches all parent ancestors using nested set models (IbTree::whereAncestorOf) and calculates level-specific commissions based on configured level percentages, writing ledger lines to the transaction_items table.

c. KYC & Security Compliance

To prevent multi-account fraud and comply with financial regulations, the platform must detect duplicate profiles and fake identity uploads. Manual verification is slow and prone to errors.

We engineered a multi-factor KYC review pipeline inside the CRM (ClientDocumentController). During document evaluations, the controller checks for duplicate user profiles using the UserRegisterMeta table. It flags user documents if the registration IP address matches another client or if the user shares a duplicate name. This provides staff with immediate visibility into possible fraud clusters before they approve verified statuses.

03 — Project Goals

Project Goals

a. Seamless Trader Onboarding

We aimed to simplify the registration and account setup process on mobile, targeting a signup and security PIN configuration flow of under 3 minutes.

By designing step-by-step onboarding interfaces in Flutter and automating verification email dispatches, we lowered entry friction and improved active user conversion rates.

b. Robust Admin Operations

Our objective was to build a secure administrative panel to automate daily operations. Admin staff require unified dashboards to manage support tickets, review KYC uploads, audit balance mutations, and configure currency conversion markups.

By writing detailed data tables and moderation resource controllers, we eliminated spreadsheets and automated the approval workflow.

04 — Design Process

Design Process

a. Financial Database Schema

We designed a normalized relational database schema in PostgreSQL. The schema maps: users (storing registration sources, balance levels, and verification flags), user_documents (holding KYC files, status markers like VERIFIED/DECLINE, and decline reasons), accounts (storing MetaTrader server configurations, logins, and passwords), deposits/withdrawals (storing payment methods, conversions, and transaction statuses), and ib_trees/transaction_items to track partner commissions.

This architecture preserves absolute ledger integrity, using foreign key cascades and balance mutation records to prevent balance discrepancies.

b. Trader Cabinet UI/UX Flow

We built the mobile trader cabinet using Flutter and Dart, styling a dark UI theme. The app navigation is managed via GetX for rapid state transitions and route management. We structured the API layer using the Dio library, configuring interceptors to handle auth tokens, request timeouts, and error retries.

The dashboard displays active trading accounts, wallet balances, and promotion banners. It features forms for deposits and withdrawals, letting users upload payment confirmations or request bank transfers easily.

c. Wallet Management & Transactions

The wallet interface details transactional histories, grouping records into Deposits, Withdrawals, and Internal Transfers. The interface guides traders through deposit options, showing payment details and upload attachments based on their selected method.

05 — Usability Testing

Usability Testing

a. Deposit/Withdrawal State Validation

We tested transaction state transitions under different payment scenarios (PayPal, Neteller, Exchanger, and Crypto). We verified that updating a deposit to verified automatically triggers the DepositStatusUpdated event, updates the client's cabinet balance, and sends success notifications.

For bank and manual exchanger transactions, we validated form request fields, checking that payment details and date formats conform strictly to database structures.

b. API Rate Limiting

To protect the API gateway from automated brute-force attacks and script exploits, we configured strict API rate limits. We implemented a custom validation rule (App/Rules/Throttle) to rate-limit sensitive routes.

For example, PIN resets are restricted using new Throttle('reset-pin', 1, 15), allowing only one attempt per 15 minutes. General API endpoints are protected using standard Laravel middleware (throttle:60,1) to block excessive traffic.

06 — Prototyping & Handoff

Prototyping & Handoff

a. Secure Deployment

We deployed the Laravel CRM backend using containerized Docker environments behind an Nginx SSL proxy. The database is hosted on a secure PostgreSQL instance with scheduled automated backups.

To secure connection parameters, MetaTrader API credentials and payment secrets are stored inside encrypted environment files, restricting manager API calls to whitelisted backend servers.

b. Platform Integration

We documented the API endpoints using Postman to support mobile client integration. The schema defines request headers, JSON parameters, and return payloads for login, account creation, and financial actions.

This comprehensive documentation streamlined handoff, enabling mobile developers to integrate new features without backend modification.

07 — Key Takeaways

Key Takeaways

a. Building Scalable Brokerage Software

Developing a multi-user broker platform requires strict data governance. Implementing double-entry book ledger systems and locking transaction databases prevents balance discrepancies during high transaction volumes.

b. Handling Complex Financial Workflows

Designing a multi-tier affiliate rebate program requires early performance planning. Relying on background queue processing (Laravel Horizon and Redis) and optimized database indices ensures calculations run without blocking administrative interfaces.