m-FINANCE and mF Technologies: Trading Platform, Trader Pro and Gateway
m-FINANCE's brokerage technology offering connects trading terminals, dealing controls, BackOffice administration, pricing and client engagement. The website linked from its Fazzaco company profile now leads to mF Technologies, whose current product portfolio includes the mF Trading Platform, Trader Pro, a branded web frontend, CRM and a hedging gateway. The portfolio gives brokers two distinct project paths: operate a complete trading stack, or improve the client experience around infrastructure they already use.
Fazzaco's m-FINANCE company profile places the business in white label, trading software, liquidity and MT4/5 plugin categories. The current official company page describes mF Technologies as headquartered in Hong Kong and focused on proprietary systems for forex, bullion and commodities. Its product proposition is especially relevant to firms that need to coordinate trading operations and brand ownership across several connected systems.
Two deployment paths: a full platform or a new frontend
The mF Trading Platform combines trader terminals across web, desktop and mobile with a Dealer Terminal, Back Office and Price Engine. The vendor positions this as a brokerage platform solution for forex, gold and other CFD products, with risk management and liquidity connections forming part of the wider system.
The separate Frontend and Loyalty solution is aimed at businesses retaining their existing trading infrastructure. It adds branded mobile and web access, alongside CRM-related engagement and partner functions. The official homepage specifically presents this route for MT brokers. That makes it a different procurement exercise from replacing the trading engine itself.
A broker should identify which layer it wants to change before comparing proposals. A full-stack project involves account configuration, pricing, dealing and operational migration. A frontend project concentrates on authentication, account synchronization, order access, content and branding while maintaining connections to an existing backend. Both require integration, but the ownership and cutover decisions differ.
How the mF platform components map to brokerage work
Source: mF Technologies, mF Trading Platform solution architecture (excerpt).
The platform architecture brings several users around the same account and trade lifecycle. Its component structure helps distinguish what clients see from what dealing and operations teams control.
| Layer | Published functions | Business role |
|---|---|---|
| Trader terminals | Web, desktop and mobile account access | Client charts, order entry and account activity |
| Dealer Terminal | Manual dealing, trade audit trail, LP management and A/B Book reporting | Trade supervision and execution oversight |
| Back Office / FTS | Account groups, agent structures, fees, settlements and reports | Operating the account and partner network |
| Price Engine | Multiple feeds, quote filters, backup switching and discrepancy alerts | Managing the prices distributed to trading clients |
| Gateway and APIs | Cross-platform routing and external application connections | Connecting trading infrastructure with other counterparties and systems |
This structure makes a complete business-event demonstration valuable. A test order should be visible through its client record, dealing treatment and operational reporting, rather than demonstrated only as a click on a chart. The project can then identify where information is created, transformed and reconciled.
Trader Pro and web trading as a branded client layer
Trader Pro is presented as a mobile application that connects with mF4 and other mainstream trading systems. The product material lists brand customization, modular content, financial news, sentiment tools, education sections and a content management backend. It also describes targeted push notifications and support for 15 languages.
For a broker, this combines account access with content distribution. An operations team may manage the trading environment, while marketing staff publish updates or arrange application modules. The proposal should specify the exact backend integrations, supported account types and approval process for client-facing content. An integration category does not establish compatibility with every version of another platform.
The web frontend is described as browser-based, responsive and PWA-enabled, with chart trading and one-click trading tools. The official FAQ says the mobile and web products can be purchased separately or together, but the frontend requires a backend trading engine to execute trades. Buying an interface therefore does not create an independent execution system.
Dealer controls and BackOffice administration
The Dealer Terminal description includes manual approval, trade and system-action tracking, liquidity-provider management, A/B Book order reports and IP monitoring. It also describes defining churning behavior and suspending transactions involving abnormal data. These are distinct operational controls, with different users and intervention points.
A dealing demonstration can follow a flagged transaction from detection through review and the resulting account record. The broker needs to define which rules operate automatically, which require approval and who may change them. The important outcome is a traceable operating procedure, not an assumption that a control label eliminates every execution or conduct risk.
Back Office, described as FTS, supports multi-tier introducing-broker and agent structures. Published settings include fees, margins and spreads at system, group or client level, user-defined contract sizes, deposit and withdrawal administration, settlements, interest and commissions. Authorized agent trading is also described. That function requires clear client authority and staff permissions within the broker's chosen operating model.
Price Engine: feed selection, filtering and continuity
The Price Engine description separates feed aggregation from the rules governing distributed prices. It lists multiple liquidity sources, configurable bad-tick filters, backup-feed switching, preset pricing profiles and cross-feed discrepancy alerts. These features are relevant to both normal operation and the response to an interrupted or inconsistent source.
For example, a broker can specify a primary feed, a backup and a discrepancy threshold, then observe how a controlled interruption affects the output quote and alert record. An error filter should be tested against agreed sample data so that the dealing team understands both the rejected quote and the price clients continue to receive.
Pricing templates also need change control. A configuration used during a major economic release may differ from a quieter session, but the applicable instruments, timing and approvals should be explicit. Backup switching is a technical capability; its effectiveness depends on the available feeds, settings and recovery procedure in the actual installation.
mF Hedging Gateway and cross-platform order flow
The mF Hedging Gateway is presented as a way to accept order flow from other MT brokers through STP routing. The vendor describes multiple gateway accounts with independent quote settings, order monitoring through the mF Dealer Terminal, and flexible A-Book or B-Book treatment.
This places the gateway at an inter-business connection point. The receiving organization needs an agreed relationship with the sending broker, an instrument mapping and a clear record of order states. The commercial arrangement for spreads, exposure and settlement is separate from the software's ability to connect the systems.
Acceptance should include a normal order, a rejection, a partial or interrupted workflow where supported, and subsequent reconciliation. The parties should identify how duplicate messages, connection recovery and unmatched records are handled in the proposed setup. These are deployment questions to resolve with the supplier, rather than evidence of a particular fill rate or latency.
CRM, partner rebates and client engagement
The frontend solution combines trading access with CRM-supported campaigns, client and partner onboarding, funding visibility and multi-level rebates. It describes configurable deposit campaigns in which eligible deposits receive non-withdrawable trading credit. This distinction matters for account displays and the rules used by finance and customer-service teams.
A broker using such tools should define campaign eligibility, the balance type created, expiry or cancellation conditions and the effect of a withdrawal. Any promotion must fit the broker's client terms and applicable market restrictions. Software availability does not establish permission to run the same campaign in every jurisdiction.
Partner management needs equally precise definitions. A multi-tier hierarchy connects accounts and commissions, but the business must still decide which activity earns a rebate and how corrections affect an agent statement. Demonstrating a funding event, a trade and the corresponding partner record helps connect campaign activity to the accounts the teams actually reconcile.
Python automation and external integrations
The platform page describes Python-based algorithmic trading and sample code for clients to test. It also names FIX protocol and open APIs, with connections for external CRM, PAMM, payment services and automated trading applications. These provide several routes for extending a platform without treating every customization as a new trading frontend.
Integration planning should distinguish trade execution from administrative synchronization. An algorithm may submit an order, while a CRM updates account or rebate information and a payment connection tracks a funding request. Each has different authorization, error-handling and reconciliation needs. The buyer should obtain the documentation and test environment for the selected interfaces.
A Python strategy should be evaluated first as a software workflow: connection state, order submission, rejection handling and restart behavior. API support alone does not establish strategy profitability or compatibility with code written for another platform. The operating team also needs a clear owner for deploying and maintaining custom integrations.
Choosing a project scope and implementation plan
mF Technologies offers a connected set of choices for brokers: an independent trading platform, white label deployment, a client frontend around existing infrastructure, or selected supporting components. A useful first step is to map the required changes across client access, trading engine, pricing, dealing, BackOffice and partner operations.
The written proposal should identify the contracting entity, product versions, included modules, hosting responsibilities and support escalation path. Implementation charges, recurring fees and third-party costs should be itemized. A branded application, full platform and gateway project should not be compared as though they include the same operational scope.
A controlled pilot can then test the chosen account model from registration through trading and reporting, including an exception and a recovery scenario. That gives product, dealing, finance and service teams a shared basis for deciding whether the configured system fits their work. The portfolio's central B2B value lies in coordinating those functions while allowing the broker to choose how much of its existing infrastructure to retain.
Sources: mF Technologies company information; mF Trading Platform, Frontend and Loyalty, and mF Hedging Gateway product pages; Fazzaco's m-FINANCE company profile.
Subscribe Now
