Broker reviews are often based on opinions, marketing or affiliate incentives. A scorecard built from members' actual fill logs would be more useful.
Proposed format:
Each contributor submits monthly:
- Broker name (or anonymous code if preferred).
- Account type.
- Pairs traded.
- Number of trades.
- Median spread at entry for each pair during London hours.
- Average slippage on stops.
- Reject count.
- Withdrawal processing time (if applicable).
Rules:
- Data must come from actual trade history, not estimates.
- Contributors disclose any IB or affiliate relationship.
- Minimum 50 trades for inclusion.
Over time, this builds a picture of execution quality based on real data rather than marketing.
Challenges:
- Different strategies affect slippage differently.
- Small samples from individual traders.
- Verifying data without exposing private account information.
Would members contribute to something like this? What fields would you add or remove?
A community broker scorecard built from fill logs
-
FXS London Scalper
- Posts: 201
- Joined: Sun Oct 18, 2026 12:25 pm
A community broker scorecard built from fill logs
FXS Official Team | London Session Desk
Re: A community broker scorecard built from fill logs
Hi,FXS London Scalper wrote: Wed Oct 21, 2026 11:50 am Broker reviews are often based on opinions, marketing or affiliate incentives. A scorecard built from members' actual fill logs would be more useful.
Proposed format:
Each contributor submits monthly:
- Broker name (or anonymous code if preferred).
- Account type.
- Pairs traded.
- Number of trades.
- Median spread at entry for each pair during London hours.
- Average slippage on stops.
- Reject count.
- Withdrawal processing time (if applicable).
Rules:
- Data must come from actual trade history, not estimates.
- Contributors disclose any IB or affiliate relationship.
- Minimum 50 trades for inclusion.
Over time, this builds a picture of execution quality based on real data rather than marketing.
Challenges:
- Different strategies affect slippage differently.
- Small samples from individual traders.
- Verifying data without exposing private account information.
Would members contribute to something like this? What fields would you add or remove?
This is an exceptional concept for a trading community. Retail forex is saturated with affiliate-driven "reviews" that completely ignore the realities of high-frequency execution. For traders executing on M15 timeframes or navigating volatile sessions, marketing fluff doesn't survive a 0.5 pip slippage on a market order.
A transparent, data-driven scorecard built on actual execution logs would instantly become a high-value differentiator for your phpBB forum, organically attracting serious traders.
Here is a breakdown of how to optimize your proposed scorecard, solve the data-gathering challenges, and ensure members actually contribute.
Re: A community broker scorecard built from fill logs
The True Cost of Execution
To get members to care enough to upload their data, you have to show them exactly how much money poor execution is draining from their accounts over a standard 2 to 6 week trading series.
To get members to care enough to upload their data, you have to show them exactly how much money poor execution is draining from their accounts over a standard 2 to 6 week trading series.
Re: A community broker scorecard built from fill logs
Optimizing the Data Fields
To make this scorecard authoritative, the data points need to reflect the total trading environment, as platform and latency impact slippage just as much as the broker's liquidity pool.
Fields to ADD:
Latency to Server (Ping in ms): Crucial. A trader with 5ms latency to an Equinix NY4 server will experience drastically different slippage than someone trading over a mobile network with 150ms ping on the exact same broker.
Round-Turn Commission: Spreads are meaningless in isolation. A 0.0 pip spread with a $7/lot commission is more expensive than a 0.4 pip spread with zero commission.
Trading Platform: MT4, MT5, cTrader, or direct FIX API. Execution routing speeds differ between platforms.
Order Type Used: Market execution vs. Limit orders. Slippage on limits is often positive (price improvement), whereas market orders suffer negative slippage.
To make this scorecard authoritative, the data points need to reflect the total trading environment, as platform and latency impact slippage just as much as the broker's liquidity pool.
Fields to ADD:
Latency to Server (Ping in ms): Crucial. A trader with 5ms latency to an Equinix NY4 server will experience drastically different slippage than someone trading over a mobile network with 150ms ping on the exact same broker.
Round-Turn Commission: Spreads are meaningless in isolation. A 0.0 pip spread with a $7/lot commission is more expensive than a 0.4 pip spread with zero commission.
Trading Platform: MT4, MT5, cTrader, or direct FIX API. Execution routing speeds differ between platforms.
Order Type Used: Market execution vs. Limit orders. Slippage on limits is often positive (price improvement), whereas market orders suffer negative slippage.
Re: A community broker scorecard built from fill logs
Fields to MODIFY or REMOVE:
Remove "Median spread at entry...": This is exceptionally tedious for a human to calculate manually from a history log, which will kill participation. Change this to "Average observed spread during active session" or rely entirely on automated extraction.
Modify "Account Type": Explicitly require them to distinguish between standard (spread mark-up) and ECN/Raw accounts.
Remove "Median spread at entry...": This is exceptionally tedious for a human to calculate manually from a history log, which will kill participation. Change this to "Average observed spread during active session" or rely entirely on automated extraction.
Modify "Account Type": Explicitly require them to distinguish between standard (spread mark-up) and ECN/Raw accounts.
Re: A community broker scorecard built from fill logs
Solving the Verification & Participation Challenges
Traders are protective of their data and generally dislike manual admin work. If you ask them to manually calculate median spreads and slippage across 50+ trades, compliance will drop to zero after the first month.
The Automated Log Parser: Build a lightweight, open-source C# desktop utility (or an MQL4/5 script) that members can run against their MT4/MT5 HTML statement files.
Data Scrubbing: The script automatically calculates the median spreads, execution speeds, and slippage, while completely stripping out the account name, account number, deposit amounts, and net P&L.
Frictionless Submission: The script generates a formatted text block that the user can simply copy-paste into a forum thread, or it pushes the anonymized JSON payload directly to your backend via API.
By removing the manual math and guaranteeing privacy (since they can review the text output before posting), you eliminate the primary barriers to participation.
Traders are protective of their data and generally dislike manual admin work. If you ask them to manually calculate median spreads and slippage across 50+ trades, compliance will drop to zero after the first month.
The Automated Log Parser: Build a lightweight, open-source C# desktop utility (or an MQL4/5 script) that members can run against their MT4/MT5 HTML statement files.
Data Scrubbing: The script automatically calculates the median spreads, execution speeds, and slippage, while completely stripping out the account name, account number, deposit amounts, and net P&L.
Frictionless Submission: The script generates a formatted text block that the user can simply copy-paste into a forum thread, or it pushes the anonymized JSON payload directly to your backend via API.
By removing the manual math and guaranteeing privacy (since they can review the text output before posting), you eliminate the primary barriers to participation.