The client is an established Southeast Asian retail forex broker serving a regional trader base that’s overwhelmingly concentrated in a single country — close to ninety-seven percent of registered clients come from one home market — with a long tail of expat traders elsewhere in the region. Their acquisition model is heavily IB-driven: roughly seven in ten clients are signed up through an Introducing Broker partnership, and a single top IB has driven approximately one-third of all completed deposit transactions on the platform.
When this client first engaged Kenmore years earlier, they were already operating a forex business and were looking for a platform that could keep up with how quickly they wanted to test new market-facing brands. They didn’t want a one-shot deployment. They wanted infrastructure that would let them spin up, rename, sunset, and re-launch trading brands as their go-to-market thesis evolved — without re-platforming the back office every time.
The first Trader’s Room and CRM deployment for this client landed in approximately three weeks from contract to live system. That delivery included a Trader’s Room connected to MetaTrader, a multi-tier IB module, NinjaCharge integration as the payment aggregator, a CRM with custom workflows for sales and support routing, multi-language support, and a live chat layer.
The first regional brand that runs through the dataset for this case study went live in early Month 1 of the analysis window. By Month 2, monthly deposit volume had cleared the threshold we use as a baseline for indexed growth measurement. By Month 3, that volume had multiplied to nearly twenty times the baseline. By Month 8, it had reached sixty-eight times — the operational peak.
Kenmore’s CRM is built around a concept the client used as the central lever of their entire growth strategy: Regions. A Region is a fully isolated, fully branded slice of the platform that sits on top of the same back office. Each Region has:
What stays unified is the operational core: one admin team, one reporting layer, one ticketing system, one IB hierarchy, one KYC pipeline. The client never had to choose between “we want a new brand” and “we want to keep our operations team productive on day one.”
For this brokerage, that meant they could test brand identities the way most firms test landing pages — and they did. Across the wider relationship, the client has run six distinct regional brands through Kenmore’s platform. Two of those brands are the subject of the data in this case study: a primary brand that powered the launch, and a successor brand that the client commissioned roughly ten months in to test a different positioning.
The client approached us needing a Trader’s Room that would handle live and demo account opening, KYC document upload, deposit and withdrawal requests, and trader self-service for personal info and account history — all wired to a CRM that would route incoming activity to the right staff. We delivered the New Edition Trader’s Room with the embedded CRM in roughly three weeks. By the operational peak, the system was processing more than 1,100 internal tasks per month — registration approvals, KYC reviews, deposit confirmations, withdrawal approvals, and IB account openings — without a separate ticket tool.
The client’s traders execute on MT. Each Region in this engagement runs against its own MT trading server, configured independently. When the client wanted to add the second Region, we provisioned a separate MT service connection so that the two brands wouldn’t share trading infrastructure even though they share the back office. Account types, leverage tiers, and group naming conventions are scoped per Region.
The IB program is the client’s primary acquisition channel. Almost seven in ten of their active traders are attributed to an IB or sub-IB. Kenmore migrated their existing multi-tier IB hierarchy into the new platform on day one, with referral-URL tracking, tiered commission rules, profit-sharing options, and an “My IBs / My Traders” analytics view inside the Trader’s Room. The system was configured so that a single IB lineage spans both Regions — the client didn’t want to fragment commission tracking across brands.
NinjaCharge is the client’s payment aggregator (a routing layer that sits above PSPs, not a PSP itself). We integrated more than thirty PSP endpoints behind NinjaCharge across local-currency rails — primarily VND for the home market, plus configurations for MYR, THB, IDR, and BTC for clients elsewhere in the region. PSP visibility is controlled per Region: the second Region went live with its own curated PSP set, distinct from the first Region’s. Of the thirty-plus integrated endpoints, roughly two-thirds are publicly exposed in the Trader’s Room at any given time, with the rest held in reserve.
Deposits flow through NinjaCharge with automated callback handling — the trader sees real-time status in the Trader’s Room. Withdrawals run through a task-driven manual approval workflow in the CRM, with custom validation rules the client requested (balance checks, currency conversion guards, payee-name verification per PSP). All deposit and withdrawal events generate CRM tasks, get routed to the right operator team, and feed back into the trader’s account history.
The CRM is configured with six supported languages, with verbiage maintained per language for both the Trader’s Room and email templates. Geo-based language detection switches the trader-facing site to the right language at first visit.
The client uses bonus and credit operations as part of their IB commission flow and for promotional campaigns. The platform supports balance adjustments routed through the same task-and-approval pipeline as deposits.
Each Region carries its own brand graphics — logo, color palette, header, footer, fonts, and custom theme CSS. The two Regions in this dataset have visibly different identities; a trader landing on one would have no way to know they’re on the same underlying CRM.
A continuous custom-development thread ran alongside the standard module delivery throughout the engagement. The client had specific requirements that the standard product didn’t cover, and Kenmore turned around fixes and enhancements on a typical cadence of days, not weeks. Examples from the development log:
The custom-development cadence is part of why the client has stayed on the platform across multiple years and multiple brand iterations: when their go-to-market evolves, the platform adapts in days, not quarters.
Around Month 10 of the analysis window — when the first Region was still posting near-peak deposit volumes — the client commissioned a second Region. The brief was straightforward: separate brand, separate domain, separate MT server, separate PSP set, but managed by the same team in the same CRM. They wanted six weeks; they got six weeks. The breakdown:
By the start of Month 12, the second Region was registering its first traders. By Month 14, it had reached parity with the first Region in monthly new registrations. By Month 18, the second Region was processing more deposit volume than the first. By Month 20, the first Region had been wound down and the second Region was carrying 100% of all new business — registrations, deposits, and accounts. The transition happened with no platform changeover, no data migration, no operator retraining: the same CRM, the same admin team, just a different Region toggled on.
This is the textbook case for what the Regions architecture exists to enable. The client’s brand thesis evolved; their operations didn’t have to.
Using Month 2 of the analysis window — the first month with non-trivial deposit activity — as an index baseline of 1×:
| Period | Deposit volume index | Notes |
|---|---|---|
| Month 1 | 0.04× | Soft launch |
| Month 2 | 1.00× | Baseline |
| Month 3 | 19.67× | First IB cohort comes online |
| Month 4 | 31.09× | |
| Month 5 | 32.51× | |
| Month 6 | 33.63× | |
| Month 8 | 68.36× | Operational peak (first Region) |
| Month 10 | 33.39× | Peak by deposit count (227 in one month) |
| Month 11 | 13.30× | First Region cools; second Region commissioned |
| Month 14 | 6.86× | Second Region live |
| Month 17 | 8.38× | Second Region overtakes first |
| Month 18 | 24.33× | Second Region carries it |
| Month 20 | 42.90× | Second Region’s own peak; first Region wound down |
The platform absorbed two distinct growth waves on two distinct brands without changing anything underneath.
The two Regions show measurably different funnel characteristics:
| Metric | First Region | Second Region |
|---|---|---|
| IB-attributed share | 70.5% | 61.0% |
| Deposit conversion (registered → deposited) | 17.5% | 31.4% |
| Avg deposits per depositor | 6.4 | 5.5 |
The second Region converts registered traders to depositors at nearly twice the rate of the first Region. Same underlying CRM, same operations team, same PSP layer — different brand, different acquisition mix, different trader behavior. That’s a legible signal that the client’s brand-iteration thesis was working.
Across the full analysis window, total withdrawal requests amount to a USD-equivalent ratio of approximately 1.34:1 against completed deposits. Note that the deposit and withdrawal sides are denominated in different currencies and processed through different operational workflows — deposits flow automatically through the PSP aggregator, withdrawals go through a manual approval queue — so this ratio is best read as “the platform sustained a balanced two-way money flow with traders getting paid out at a clip slightly above what they’re depositing in any given window.” That’s a healthy retention picture for an IB-led retail forex book.
At the operational peak in late Year 1, the CRM was processing more than 1,100 internal tasks per month — registration approvals, KYC reviews, deposit confirmations, withdrawal approvals, IB account openings, support tickets — all routed through one workflow engine. The same engine continues to handle a smaller, steadier volume in the post-transition Region.
This engagement is the cleanest demonstration we have of what Kenmore’s Regions architecture is for. The story isn’t “we shipped a CRM.” Most CRM vendors can ship a CRM. The story is:
Speed to launch. The client’s first Region went live in roughly three weeks from contract. Their second Region — a fully separate brand on a separate MT server with a separate PSP set — went live in roughly six weeks from kickoff to QA-complete.
Brand iteration without re-platforming. When the client’s go-to-market thesis evolved, they didn’t migrate. They added a Region, ramped it, and let the prior Region wind down naturally as IBs and traders moved over. No data migration, no operator retraining, no downtime.
One operations team across multiple brands. The same CRM, the same admin staff, the same workflows, the same KYC pipeline served two Regions simultaneously — and across the wider relationship, has served six.
Sustained custom-development cadence. The platform’s standard product doesn’t have to fit perfectly out of the box. Custom validators, region-scoped workflows, fixed-currency-rate handlers, PSP-specific payee logic, and a long tail of small enhancements have been delivered on a cadence of days. The client has been compounding custom value for years.
Operational scaling under load. The platform absorbed a 68× lift in monthly deposit volume in one Region and then a separate near-peak in another Region — concurrently, on shared infrastructure, with no architectural rework in between.
This is what it looks like when a forex brokerage stops thinking of the CRM as a fixed deployment and starts thinking of it as a brand-iteration platform.
| Metric | Value |
|---|---|
| Operational time-to-live (first Region) | ~3 weeks |
| Time-to-live for second Region | ~6 weeks |
| Peak monthly deposit volume vs. baseline | 68× |
| Second Region’s peak vs. baseline | 43× |
| Active regional brands run on a single CRM | 6+ (across the broader relationship) |
| Distinct PSP endpoints integrated via NinjaCharge | 30+ |
| Supported languages | 6 |
| MT trading-server connections | 2 (one per Region) |
| IB-attributed client share | ~70% |
| Email confirmation rate | ~89% |
| KYC approval rate | ~33% |
| Registered → deposited conversion | ~19% overall (~31% on second Region) |
| Avg completed deposits per depositor | 6+ |
| Withdrawal-to-deposit USD-equivalent ratio | ~1.34:1 |
| Concurrent Regions on the same CRM during transition | 2 |
| Region transition: brand changeover with zero data migration | ✓ |
Kenmore's Regions architecture lets brokerages spin up new brands, test positioning, and migrate audiences — without touching the back office. Talk to us about your operation.
Multiple brands. One CRM. Zero migrations.
