Five Weeks to Migrate, Three Years to Compound: How a Regional ECN/STP Brokerage Took an Existing Book onto Kenmore — and Stayed Put

There is a kind of forex brokerage case study that’s all about transformation: the platform-swap, the regulatory pivot, the hockey-stick growth chart. This is not that case study. This one is about steadiness. About a client who walked through the door with an existing trader book, asked for a “ready for market” platform, got it live in five weeks, migrated the bulk of that book onto it inside the first month, and then kept compounding on the same stack for the next two and a half years. No platform migrations. No re-architecting. Just a steady accretion of PSPs, account types, IB tooling, and operational features as the business matured.

It is, in a word, the resilient brokerage story. And it’s our favorite kind.

About the Client

The client is a regional ECN/STP forex broker operating across the MENA region with a substantial trader base extending into emerging Asia. Roughly forty percent of registered clients connect from MENA countries; another quarter come from South and Southeast Asia. The platform supports both English and Arabic UIs end-to-end, with right-to-left layout, localized email templates, and Arabic-speaking support routing — though the lingua franca for the trader base is English, with Arabic the secondary localization for native-language onboarding.

Their product line is unambiguously traditional retail forex, executed through MetaTrader 5: tight-spread ECN accounts for active traders, Standard accounts for new entrants, plus a long tail of specialized account configurations for institutional clients, PAMM/MAM money managers, rebate-driven IB sub-accounts, and a US Stocks line. There are no challenge phases, no funding programs, no synthetic instruments — just a live trading room, a real broker behind it, and the operational machinery to onboard, KYC, fund, support, and pay traders who use the platform.

Their go-to-market is heavily IB-driven. Roughly forty-five percent of all registered traders were referred by an Introducing Broker through the in-platform multi-tier IB program. The active IB roster is in the low hundreds; the long tail of sub-IBs is wider still. A multi-tier rebate engine routes commissions across as many levels as the broker chooses to compensate.

The Launch

The proposal was signed at the end of Q3 of Year 1. The scope was, by Kenmore standards, conventional: Trader’s Room for MT5, embedded CRM, Multi-Tier IB module, Tools4Brokers PAMM expansion, integration with one PSP for deposits, manual bank-transfer and crypto deposit forms, live chat, multi-language support, and a new design for the Trader’s Room.

The build proceeded through the standard four phases — Discovery, Development, Testing, Deployment — and the platform went live within roughly five weeks of contract signing. Within the first two weeks of go-live we had set up the MT5 service connection, configured the email infrastructure, deployed the live chat, and migrated the first cohort of traders. The first PSP integration (a regional crypto-friendly processor) was delivered in parallel with the launch milestone itself.

The defining event of the launch wasn’t the cutover — it was the migration that followed. By the end of the second month post-launch, the existing trader book had been imported in full into the new platform, along with account histories, KYC documents, and the IB hierarchy. That single migration month accounts for roughly two-thirds of every trader the platform has ever held; the remaining third has been built up organically through the IB network and direct registrations across the thirty months that followed.

Modules Delivered

Trader’s Room and Forex CRM (MT5)

The client approached us needing a Trader’s Room that would absorb their existing book on day one, route every operational event through a single CRM workflow, and give their staff a coherent admin surface from which to run the brokerage. We delivered the Trader’s Room with the embedded CRM. By the operational peak in the second year, the system was processing more than a thousand internal tasks in a single peak month — registration approvals, KYC reviews, deposit confirmations, withdrawal approvals, IB account openings, transfer requests, and trader updates — all routed through a single queue with role-based permissions and language-based assignment.

Across the engagement to date, the platform has logged a high-volume stream of completed deposit and withdrawal tasks, with completion rates above ninety-nine percent on both sides of the ledger. That reliability metric is the one we tend to highlight when prospects ask whether a Kenmore Trader’s Room can handle a real trading operation: a deposit-and-withdrawal completion rate at parity with the major card networks, sustained across thirty months.

MetaTrader 5 Integration

The client trades exclusively on MT5. We provisioned a single MT5 service connection at launch, configured account groups for each of the broker’s trading product lines, and have left that infrastructure stable ever since. There has been no platform migration, no MT4-to-MT5 transition, no white-label-to-direct-server move. The MT5 stack the client launched on in Year 1 is the same MT5 stack they are running today. That stability is intentional, and it’s one of the things we think a Kenmore engagement should make boring. Trading platforms are not where a successful brokerage wants to spend its operational attention.

Multi-Tier IB Management

The IB program is the client’s primary acquisition channel and the most-customized module in the engagement. We migrated the existing multi-tier IB hierarchy onto the new platform on day one — referral URLs, sub-IB tiers, commission rules — and then iteratively extended the system over the following two years.

The current configuration supports an unbounded number of IB tiers, with rebate logic that can be configured per-IB and per-product as a function of pips, percentage of commission, fixed cash, or profit-sharing — or as a custom formula across multiple of those at once. A multi-tier rebate engine generates commission events on a continuous basis; rebate-change events are logged for transparency, and IBs can pull their full sub-tree as a downloadable CSV with a single click.

Around forty-five percent of the registered trader base today is attributed to an IB — meaning nearly half of every client the broker holds came through the IB network rather than through paid acquisition or direct sign-up. The IB program is, for this client, what paid traffic is for other brokers: the dominant channel, the one that scales with effort, and the one that the platform is engineered to serve.

PAMM/MAM Money Manager Module (Tools4Brokers)

We integrated the Tools4Brokers PAMM at launch and ran it in production from week one. The client uses it as their money-manager offering: experienced traders apply through the Trader’s Room to register as a PAMM manager, set their performance terms, and accept investor allocations through the trader-facing portal; the broker’s admin team approves both manager and investor accounts through the CRM. Hundreds of MAM/PAMM accounts have been opened over the engagement. Mid-engagement we shipped a custom terms-and-conditions popup for the PAMM signup flow, with explicit acceptance tracking and timestamped agreement records — the kind of compliance-driven detail that’s painful to retrofit if it’s not designed in.

Multiple Language Support

The client launched bilingual on day one. Both the Trader’s Room and the broker-facing CRM are localized into English and Arabic, with full right-to-left layout for Arabic, localized email templates per language, and language-routed support assignment so that Arabic-language client requests reach Arabic-speaking operators. Across the registered trader base, English is dominant — roughly nineteen out of every twenty traders use the English UI — but the Arabic configuration is what makes the broker recognizable as a serious operator in their primary market.

Live Chat

Live chat is wired directly into both the Trader’s Room and the public-facing site, with the same chat system powering both. Chat operators are scoped by region and language. Traders’ chat history is tied to their CRM record, so when a trader opens a conversation the operator already has the trader’s account, KYC status, and recent transaction history in the same view.

Payment Solutions

The client started with one PSP at launch — that was the original scope, and it kept the launch on its five-week timeline. Over the next eighteen months, we layered in four additional payment integrations:

• A regional fiat PSP (SticPay), integrated in Month 1 as the launch deposit channel.
• A second regional fiat PSP (Praxis), with both deposit and withdrawal integration, delivered in Month 4.
• A crypto-PSP (Cregis) supporting USDT on TRC20, ERC20, and BEP20 networks, delivered in Month 13. Crypto became one of the client’s largest deposit channels by volume.
• A third fiat PSP (Unipayments), delivered in Month 21, when the client wanted broader rail diversity for emerging-market payments.

Behind those PSPs sits Kenmore’s payment aggregator (Ninjacharge), which serves as the routing layer that decides which PSP processes any given deposit based on geography, currency, and PSP availability. Ninjacharge is a smart-routing layer that fans transactions out to whichever underlying PSP is best for the trader’s region, with automated fallback when one channel hits a limit.

Alongside those automated rails, the broker runs manual bank-transfer and direct crypto-wallet deposit/withdrawal flows for clients who prefer or require off-rail settlement. Across the full engagement, those manual channels — bank wires routed through CRM-managed approval queues, and crypto wallet transfers with QR-code receipt upload — have together accounted for the majority of total deposit volume. The PSP-routed flows handle the high-frequency long tail.

The full deposit-channel composition today includes more than sixty merchant configurations across regions and currencies. By share of total deposit volume, manual crypto wallet and manual bank transfer are roughly tied as the largest channels, with the PSP-routed crypto and fiat channels filling in the rest.

Bonus / Credit System

Bonus and credit operations sit on the same task-and-approval workflow as regular deposits. The client uses them for IB commission credits, occasional promotional campaigns, and balance adjustments — all routed through the CRM with role-based approval permissions and journaled audit trails.

Web Design

The Trader’s Room visual identity, including color palette, header, footer, branded icons, and CSS-level theme overrides, was delivered as part of the launch and refined across the engagement as the client iterated on their public brand. The trader-facing portal carries the broker’s own visual identity end-to-end; nothing in the UI flags it as a third-party platform.

Custom Development

A continuous custom-development thread has run alongside the standard module roadmap from Month 1 onward. Across the engagement, we have shipped well over one hundred discrete custom enhancements — most of them small, targeted, and turned around within days of being requested. The pattern is the one we think makes long-term Kenmore engagements work: small, specific, fast, and on-going. The client doesn’t have to choose between “we want this small thing changed” and “we don’t want to wait two months for it.” A few of the more substantive development threads:

• Multi-tier IB rebate engine. The standard multi-tier IB module shipped at launch. Over Year 2 we built out a richer rebate-logic layer — multi-currency support, per-IB rate overrides, profit-sharing alongside pip-based and percentage-based commissions, an IB tree, and full audit logging of rebate-rate changes. The IB program is the most-extended module in the engagement.
• Telegram and Slack notification integrations. We wired the broker’s internal Telegram and Slack channels for real-time deposit, withdrawal, registration, and commission events. The notifications are configurable per channel, per event type, and per region; we have iterated on what fields appear in each notification multiple times based on operator feedback.
• WhatsApp / messenger OTP verification. Mid-engagement the client wanted a second-factor verification channel that worked for clients who preferred messaging over email. We delivered a messenger-OTP integration that works through WhatsApp and supports per-trader opt-in, with verification timestamps stored on the trader record.
• Sales Module. Kenmore’s Advanced Sales Teams module went live for this client in Year 2. It powers their lead-routing rules, sales-agent assignment by language and time-zone, and pipeline tracking from registration through to first deposit.
• Crypto deposit and withdrawal forms with QR-code receipt upload. For the manual crypto channel, traders can attach a QR code or screenshot of the on-chain transaction; deposits are auto-correlated with the corresponding wallet address, and the operator approves them through the CRM with one click.
• Custom withdrawal forms with broker-defined fields. For each fiat withdrawal rail (bank wire, regional payouts), we built per-rail field configurations — payee name format, reference fields, and validation rules — so that withdrawal data leaving the platform always conforms to the receiving rail’s requirements.
• PAMM service-agreement workflow. The PAMM signup flow now includes an explicit terms-and-conditions popup with two acceptance checkboxes and a timestamped acceptance record stored on the trader profile.
• Account-limit policy enforcement. Client-side and admin-side enforcement of per-trader account-count limits, raised over the engagement from five to ten as the client’s product mix expanded.
• Email-template variable expansion. The client has dozens of customized email templates across confirmation, deposit/withdrawal status, KYC reminders, and IB rebate payouts. Across the engagement we have added new substitution variables (account-type names, payment-method specifics, IB-tier names) on demand whenever a new template needed them.
• Custom IB referral-URL handling. Beyond the standard IB referral URL, the client has multiple custom URL formats and parameter conventions for different IB campaigns. We delivered support for those formats and the corresponding tracking pipeline through the CRM.

The cadence on these is steady. Across the thirty months post-launch — excluding the launch month and the migration month, both of which had higher volume — the development log shows an average of three to five enhancements completed per month, with surges in the second half of Year 2 (when the Sales Module, WhatsApp OTP, and Cregis crypto-PSP integrations all landed) and again in Year 3 as IB-tooling matured and PAMM gained the agreement workflow.

What the Data Says

The platform has been live for more than thirty months. The numbers below are taken from the operational data and expressed as ratios, multipliers, and percentages — never as absolute values.

A migrated book that compounded for thirty months

The launch-and-migration sequence is visible in the data as one enormous spike followed by thirty months of steady accretion. Roughly two-thirds of the trader base appeared in the first two months post-launch as the existing book was imported. The remaining third was built up organically and through the IB program over the years that followed — meaning that for every two existing traders the broker brought over at launch, they signed up roughly one more through the platform’s organic and IB-driven channels.

By the end of Year 3, the registered trader base had grown to roughly 1.55× the post-migration baseline.

The post-launch monthly cadence shows two organic registration surges — one in Q4 of Year 2 (driven by an IB-marketing push that quadrupled the previous quarter’s average) and one in Q1 of Year 3 — interspersed with steady-state months in the thirty-to-eighty range.

Deposit volume scaled an order of magnitude

The clearer growth story sits on the deposit-volume side. Quarterly deposit volume in Q1 of Year 1 (the first full quarter post-launch) was the baseline for the engagement. By Q1 of Year 3, quarterly deposit volume had grown to more than 11× that baseline.

Withdrawal volume tracked deposit volume at roughly the 0.7-to-0.9 ratio that’s typical of an active retail broker — not a one-shot deposit-and-leave pattern, but a continuous trading operation where clients deposit, trade, and withdraw on an ongoing basis. The peak monthly deposit volume seen over the engagement is more than 130× the early-launch baseline, driven in part by occasional institutional deposits flowing through the broker’s higher-tier account types.

A traditional product running on a single platform

The broker’s account-type catalog is one of the richest we have on the platform. More than 110 account configurations are defined, spanning the broker’s product line:

• Standard accounts (commission-free, wider spreads) — the majority of new sign-ups.
• ECN accounts (raw spreads with per-lot commission) — the active-trader product.
• Pro and Institutional accounts for higher-deposit clients.
• PAMM Manager and PAMM Investor accounts for money-manager flows.
• Wallet, Rebate, Reward, Demo, US Stocks, and bonus-eligible accounts filling out the long tail.

These configurations all run against a single MT5 service.

Client engagement is consistent

The headline engagement numbers across the registered trader base:

• Roughly nine in ten registered traders have confirmed their email address — high enough to suggest the registration funnel is genuine traffic, not bot signups.
• Seven in ten have completed KYC approval — a robust compliance ratio for a regional broker.
• Three in four registered accounts are in an active state (have not been deleted, suspended, or archived).
• Forty-five percent of registered traders are attributed to an IB — meaning the IB program is, by share, the largest single acquisition channel.
• Ten percent of the trader base has reached funded-account status — the typical retail forex conversion rate for an established broker.

Operational reliability at industry-grade rates

Across the full body of processed deposit and withdrawal task records (excluding the migration import), deposit-completion runs at 98.9% and withdrawal-completion runs at 99.4%. The operational team is small enough to be measured in dozens of admins; the role configuration includes multiple MENA-region operations roles, plus dedicated sales-and-marketing, IT, IB-VIP, and viewer roles, all permissioned through Kenmore’s role-based access control.

Source distribution: MENA-led, with significant Asian footprint

The IP-derived geographic distribution of the trader base shows a strong MENA concentration with a meaningful South-and-Southeast-Asia presence, plus a tail of European and other-region traders that the multilingual platform serves through the same back office.

Account-type composition

Real trading accounts dominate the account ledger, with IB and MAM accounts together accounting for nearly thirty percent of total accounts — a mix that’s distinctive to this broker’s product strategy. The Money Manager share, in particular, is unusually high for a brokerage of this size and reflects the client’s investment in the money-manager line as a parallel revenue stream.

Payment-channel mix

The two largest deposit channels by volume — manual bank transfer and manual crypto wallet — together account for roughly eighty-five percent of all recorded deposit volume. The PSP-routed long tail (Cregis crypto, regional fiat PSPs through Ninjacharge) handles the remaining fifteen percent at much higher transaction frequency. That distribution is characteristic of a broker whose larger clients prefer high-touch settlement rails while their retail base uses automated PSP routing.

What This Proves

The takeaway from this engagement is not a hockey-stick story. It’s a steady-state story.

Speed to live, with an existing book. Five weeks from contract to live system, with the broker’s full existing trader book migrated inside the second month. That’s not a green-field launch where the broker has the luxury of building toward day one — that’s an existing book of clients moving onto a new platform without dropping accounts, KYC documents, or IB hierarchies along the way. The migration tooling and the day-one Trader’s Room scope worked as advertised.

Resilience without re-platforming. Thirty months of continuous operation on a single MT5 stack. No platform migrations, no rip-and-replace events, no major architectural changes. The platform that went live in Year 1 is the platform running today, with a much richer module configuration layered on top of it. For a brokerage operator, this is the boring outcome that’s actually hardest to deliver — a platform that absorbs growth without becoming the bottleneck.

Custom development as a continuous capability. Three or four small custom enhancements per month, every month, for thirty months — that’s the cadence of a working partnership, not a one-shot delivery. The standard module roadmap covers most of what a brokerage needs; the custom layer handles the broker-specific edges. Both ride the same platform.

An IB-driven growth engine, scaled. Forty-five percent of the trader base attributed to an in-platform IB program. An active IB roster in the low hundreds, with a wider sub-IB tail beneath them. A multi-tier rebate engine that pays out commissions on a continuous basis with full audit logging. The IB module is the most-extended module in this engagement, and it’s the module that’s most directly correlated with the broker’s growth.

Multi-PSP redundancy without lock-in. The broker started with one PSP at launch and now operates four payment integrations plus manual rails, with smart routing across them. When a single processor hits a daily limit or a regional rail goes down, deposits route through alternative channels without operator intervention.

Reliability at scale. Ninety-nine-percent-plus completion rates on both deposits and withdrawals across the full transaction history processed through the platform. That’s the metric brokerage operators actually feel — not the headline AUM number, but whether deposits clear and withdrawals process without escalation.

This is what a Kenmore engagement looks like when it works the way we want it to work: a fast launch, a clean migration, a stable platform, and a custom-development cadence that compounds with the business rather than being consumed by it.

Key Metrics at a Glance

Metric	Value
Time from contract to live system	≈ 5 weeks
Months of continuous operation	30+
Trader base growth — post-migration baseline to current	1.55×
Quarterly deposit volume — Year 3 vs. Year 1 (same calendar quarter)	11×
Peak monthly deposit volume vs. early-launch baseline	130×+
Withdrawal-to-deposit volume ratio (steady state)	≈ 0.7–0.9
IB attribution share of registered trader base	45%
Active Introducing Brokers in the network	low hundreds
Account-type configurations defined on the platform	110+
Distinct account-type product names	35
Languages supported in Trader’s Room and CRM	2 (English, Arabic — with RTL)
PSP integrations live in production	4 (plus manual bank & crypto rails)
Trading platform	MT5 only — no platform migrations
Email-confirmation rate across registered traders	≈ 90%
KYC-approved share of registered traders	≈ 71%
Active-account share of registered traders	≈ 74%
Deposit-completion rate (status: completed)	98.9%
Withdrawal-completion rate (status: completed)	99.4%
Custom enhancements shipped post-launch	130+ over 30 months
Operational team size on the admin side	dozens of admins

---