Migrateまで5週間、複利まで3年：既存ブックをKenmoreへ移し替えた地域ECN/STPブローカーの事例 — そしてそのまま定着

変革にフォーカスしたフォレックス・ブローカーの事例というものがあります。プラットフォームの入れ替え、規制面での舵の切り替え、右肩上がりの成長曲線。これはその手の事例ではありません。これは「安定」についてです。既存のトレーダーブックを持って来たクライアントが、「市場投入の準備ができた」プラットフォームを求め、5週間で稼働させ、最初の1か月でそのブックの大半を移行し、その後の2年半にわたって同じ基盤で複利を積み上げ続けた――そんな話です。プラットフォーム移行はありません。再アーキテクチャもありません。事業が成熟するにつれて、PSP、口座タイプ、IB向けツール、業務機能が、ただ着実に積み増されていっただけです。

ひとことで言えば、回復力のあるブローカーの物語です。そしてそれが、私たちのいちばん好きなタイプです。

クライアントについて

クライアントはMENA地域で事業を展開する地域ECN/STPフォレックス・ブローカーで、新興アジアまで広がる相当なトレーダーベースを有しています。登録済みクライアントの約40%がMENA諸国から接続し、残りの約25%は南アジアおよび東南アジアからです。プラットフォームは英語とアラビア語のUIにエンドツーエンドで対応しており、右から左へのレイアウト、ローカライズされたメールテンプレート、アラビア語対応のサポートルーティングを備えています。ただし、トレーダーベースの共通語は英語で、アラビア語は母語オンボーディングのためのセカンダリ・ローカリゼーションです。

プロダクトラインは、明確に伝統的なリテール・フォレックスです。MetaTrader 5で提供され、アクティブトレーダー向けのスプレッドがタイトなECN口座、新規参入者向けのStandard口座に加え、機関投資家向けの専用口座設定のロングテール、PAMM/MAMのマネーマネージャー、リベート連動のIBサブ口座、そして米国株ラインがあります。チャレンジフェーズも、資金提供プログラムも、シンセティック・インストゥルメントもありません。あるのは、稼働中のトレーディングルーム、背後にいる実在のブローカー、そして、そのプラットフォームを使うトレーダーをオンボーディングし、KYCを行い、資金を入金し、サポートし、報酬を支払うための運用の仕組みだけです。

そのGo-to-marketはIB主導です。登録済みトレーダーの約45%は、プラットフォーム内のマルチティアIBプログラムによってIntroducing Broker（紹介ブローカー）から紹介されました。稼働中のIB担当は数百規模の下限で推移し、サブIBのロングテールはさらに広がっています。マルチティアのリベート・エンジンが、ブローカーが報酬として補填したい分だけ、コミッションを複数レベルにわたって振り分けます。

ローンチ

提案書はYear 1の第3四半期末に署名されました。範囲はKenmore基準では従来型でした。すなわち、MT5のTrader’s Room、組み込みCRM、マルチティアIBモジュール、Tools4BrokersのPAMM拡張、入金用に1つのPSPとの連携、手動の銀行振込および暗号資産の入金フォーム、ライブチャット、多言語対応、そしてTrader’s Roomの新しいデザインです。

開発は標準の4つのフェーズ――Discovery、Development、Testing、Deployment――を経て進み、契約締結からおよそ5週間でプラットフォームは稼働しました。稼働開始後の最初の2週間で、MT5サービス接続をセットアップし、メール基盤を構成し、ライブチャットをデプロイし、最初のトレーダー第1コホートを移行しました。最初のPSP連携（地域で利用できる暗号資産対応のプロセッサ）は、ローンチのマイルストーンそのものと並行して提供されました。

ローンチの決定的な出来事が「切り替え」ではなかったのは、その後に続いた「移行」があったからです。ローンチ後2か月目の終わりまでに、既存のトレーダーブックは、新しいプラットフォームへ完全にインポートされました。口座履歴、KYC書類、そしてIB階層もすべて移行されています。この移行の1か月だけで、プラットフォームがこれまで保有してきたトレーダーの約3分の2を占めています。残りの3分の1は、その後に続く30か月間で、IBネットワークと直接登録によって、自然に積み上げられていきました。

提供モジュール

Trader’s Room と Forex CRM（MT5）

クライアントは初日から既存ブックを吸収できるTrader’s Roomを必要としていました。さらに、すべての運用イベントを1つのCRMワークフローで振り分けられ、ブローカー業務を回すための、筋の通った管理画面をスタッフに提供できることが求められていました。私たちは、組み込みCRMを搭載したTrader’s Roomとして提供しました。第2年の運用ピーク時には、システムが月間ピークの1か月で、1,000件超の社内タスクを処理していました。登録の承認、KYCレビュー、入金確認、出金承認、IB口座の新規オープン、振替リクエスト、そしてトレーダーの更新――これらすべてが、ロールベースの権限と、言語にもとづく割り当てによって制御される単一キュー経由でルーティングされていました。

これまでの取組の中で、プラットフォームは入金・出金タスクの完了について高い処理量の記録を残しており、台帳の両側で完了率が99%以上を維持しています。この信頼性指標こそが、見込み客が「KenmoreのTrader’s Roomは本当の取引運用を扱えるのか？」と尋ねるときに、私たちが強調しがちなものです。入金と出金の完了率が主要なカードネットワークと同等であり、それが30か月にわたって維持されたという点が評価されています。

MetaTrader 5 統合

クライアントはMT5でのみ取引しています。ローンチ時に単一のMT5サービス接続を用意し、ブローカーの取引プロダクトラインごとに口座グループを設定しました。そして、それ以降ずっとこのインフラは安定したまま維持しています。プラットフォーム移行はありません。MT4からMT5への移行もありません。ホワイトラベルからダイレクトサーバへの移動もありません。Year 1でクライアントがローンチしたMT5スタックは、今日彼らが稼働させている同じMT5スタックです。この安定性は意図的であり、Kenmoreの取組は「退屈になるべきだ」と私たちが考える要素のひとつです。取引プラットフォームは、成功しているブローカーが運用上の注意の大半を費やしたい場所ではありません。

マルチティアIB管理

IBプログラムはクライアントにとって主要な獲得チャネルであり、取組の中で最もカスタマイズされたモジュールです。私たちは初日から、既存のマルチティアIB階層を新しいプラットフォームへ移行しました。紹介用URL、サブIBティア、コミッション規則――それから、その後の2年間にわたってシステムを段階的に拡張していきました。

現在の設定では、無制限の数のIBティアをサポートしており、リベートロジックは、pips、コミッションの割合、固定キャッシュ、あるいは利益分配といった指標に応じて、IBごと・プロダクトごとに設定できます。また、それらを複数同時に使ったカスタム数式としても構成できます。マルチティアのリベート・エンジンは、継続的なベースでコミッションイベントを生成します。透明性のためにリベート変更イベントが記録され、IBはワンクリックでダウンロード可能なCSVとして、その全サブツリーを取得できます。

現在、登録済みトレーダーベースの約45%はIBに起因しています。つまり、ブローカーが保有する各クライアントのほぼ半分が、有料の獲得や直接サインアップではなく、IBネットワークを通じて獲得されているということです。IBプログラムは、このクライアントにとって、他のブローカーにおける「有料トラフィック」に相当します。主要なチャネルであり、努力とともに拡大し、そしてプラットフォームがそれに奉仕するよう設計されているチャネルです。

PAMM/MAM マネーマネージャーモジュール（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.

多言語対応

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.

決済ソリューション

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 高度な営業チーム 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.
• メール-template variable expansion.クライアントは、確認、入出金ステータス、KYCリマインダー、IBリベートの支払いなどにまたがって、カスタマイズされたメールテンプレートを数十種類保有しています。案件期間を通じて、新しいテンプレートで必要になるたびに、新しいサブスティテューション変数（口座タイプ名、支払い方法の詳細、IBティア名）を都度追加しました。
• Custom IB referral-URL handling.標準のIB紹介URLに加えて、クライアントには複数のカスタムURL形式と、異なるIBキャンペーン向けのパラメータ規約があります。私たちはCRMを通じて、そうした形式と対応するトラッキング・パイプラインのサポートを提供しました。

これらの運用は安定しています。ローンチ後の30か月間（ローンチ月と移行月を除く。これらは取扱量が多い月でした）について、開発ログを見ると、月あたり平均3〜5件の改善が完了しており、特に2年目後半に集中しています（その時期にSales Module、WhatsApp OTP、Cregisのcrypto-PSP連携がすべて着地しました）。また、IBツール群が成熟し、PAMMで合意ワークフローが導入されたことで、3年目にも再び増勢が見られます。

What the Data Says

このプラットフォームは30か月以上稼働しています。以下の数値は運用データから取得し、比率・倍率・パーセンテージとして表しています。絶対値としては示しません。

30か月間複利で増えた移行済みのブック

ローンチと移行のシーケンスは、データ上では「途方もない規模のスパイクが1回、その後30か月間は着実に積み上がる」という形で見えます。新規の取引参加者の約3分の2は、既存ブックがインポートされたローンチ後最初の2か月間で出現しました。残りの3分の1は、その後の年数にわたってIBプログラムと、自然増によって構築されました。つまり、ローンチ時にブローカーが既存トレーダーを2人引き継いだごとに、プラットフォームの自然増およびIB主導のチャネル経由でおよそもう1人が追加で登録した計算です。

3年目末までに、登録済みトレーダー基盤は移行後のベースラインの約1.55倍に成長していました。

ローンチ後の月次ペースは、自然増による登録の大きな波が2回あることを示しています。1回目は2年目のQ4（IBマーケティングの後押しで、前四半期の平均が4倍になったことによる）で、2回目は3年目のQ1です。これらの間には、30〜80の範囲の安定状態の月が挟まっています。

入金量は1桁ではなくオーダー規模で拡大

より明確な成長ストーリーは、入金量の側にあります。1年目Q1（ローンチ後の最初の四半期）が、案件のベースラインでした。3年目Q1までに、四半期の入金量はそのベースラインの11倍超にまで成長しています。

出金量は入金量に連動しており、アクティブなリテール・ブローカーに典型的な0.7〜0.9の比率でした。一度入金してすぐ離れるパターンではなく、クライアントが継続的に入金し、取引し、出金する“継続運用型”のトレーディング業務です。案件期間中に観測された月次の最大入金量は、初期ローンチ時のベースラインの130倍超で、これは一部には、ブローカーのより高いティアの口座タイプを経由して流れ込む、時折の機関投資家による入金が寄与していました。

単一のプラットフォームで動く従来型プロダクト

ブローカーの口座タイプのカタログは、私たちのプラットフォーム上でも最も充実した部類の1つです。110を超える口座設定が定義されており、ブローカーのプロダクトライン全体にまたがっています。

• スタンダード口座（手数料なし、スプレッド広め）——新規登録の大半。
• ECN口座（ロースプレッドにロットごとの手数料）——アクティブ・トレーダー向けの商品。
• 高入金の顧客向けのProおよびInstitutional口座。
• PAMM ManagerおよびPAMM Investor口座（マネーマネージャーの資金フロー向け）。
• ウォレット、リベート、リワード、デモ、米国株、ボーナス対象資格のある口座がロングテールを埋めています。

これらの設定はいずれも、単一のMT5サービスに対して動作します。

クライアントのエンゲージメントは一貫している

登録済みトレーダー基盤におけるエンゲージメントの主要数値：

• おおよそ 登録トレーダーの10人中9人 はメールアドレスを確認済みです——登録ファネルが、ボットのサインアップではなく実在のトラフィックであることを示唆するには十分な高さです。
• 10人中7人 はKYCの承認を完了しており——地域のブローカーとしては堅実なコンプライアンス比率です。
• 登録口座の4件中3件 はアクティブな状態にあります（削除、停止、またはアーカイブされていません）。
• 登録トレーダーの45％ はIBに紐づいています——つまり、IBプログラムは、取り分の面で最大の単一獲得チャネルです。
• トレーダーベースの10％ は資金投入済み口座のステータスに到達しています——確立されたブローカーにおける一般的な小口のフォレックス転換率です。

業界標準レベルの信頼性

移行インポートを除く、処理済みの入金・出金タスク記録全件において、入金完了の実行は98.9%で、出金完了の実行は99.4%です。運用チームは、数十人規模の管理者として計測できるほど小さく、ロール設定には複数のMENA地域のオペレーションロールに加え、専用の営業・マーケティング、IT、IB-VIP、閲覧者ロールが含まれており、これらはいずれもKenmoreのロールベースアクセス制御で権限付与されています。

ソース配分：MENA主導で、大きなアジアのプレゼンス

IPに基づくトレーダーベースの地理的分布は、意味のある南部・東南アジアでの存在を伴う強いMENA集中を示しています。さらに、同一のBackofficeを通じて多言語プラットフォームが受け入れる、欧州およびその他地域のトレーダーも末尾として存在します。

口座タイプの構成

実取引口座が口座台帳を圧倒的に占めており、IB口座とMAM口座を合わせると全口座の約30%に達します。これは本ブローカーのプロダクト戦略に特徴的な組み合わせです。とりわけMoney Managerの比率は、この規模のブローカーとしては非常に高く、クライアントがマネーマネージャー領域を並行する収益ストリームとして投資していることを反映しています。

決済チャネルのミックス

取扱量で最大の2つの入金チャネル――手動の銀行振込と手動のcryptoウォレット――が、記録された全入金量の約85%を占めています。PSP経由のロングテール（Cregis crypto、Ninjacharge経由の地域の法定通貨PSP）は、残り15%を、取引頻度がはるかに高い形で処理します。この分布は、より大口のクライアントがハイタッチな決済レールを好む一方で、リテール基盤では自動化されたPSPルーティングを利用するようなブローカーに典型的です。

このプローブが示すもの

このエンゲージメントから得られる結論は、いわゆるホッケースティックのような話ではありません。これは、安定運用（定常状態）の物語です。

稼働までのスピード：既存のブックがある状態で契約から稼働システムまでわずか5週間。ブローカーの既存トレーダーブックは2か月目のうちに移行されていました。これは、ブローカーがday oneに向けて構築する余裕を持つグリーンフィールドの立ち上げではありません。途中で口座を落とすことも、KYC書類を落とすことも、IB階層を崩すこともなく、既存の顧客ブックが新しいプラットフォームへ移行したのです。移行用のツールと、day-oneのTraders Roomスコープは、説明どおりに機能しました。

リプラットフォームなしでのレジリエンス。単一のMT5スタックで継続稼働して30か月。プラットフォーム移行はなく、リプレース事件もなく、大規模なアーキテクチャ変更もありません。Year 1で稼働開始したプラットフォームが、現在も稼働しており、その上により豊富なモジュール構成がレイヤーされています。ブローカー運営者にとって、これは実は最も実現が難しい「退屈な」成果――成長を受け止めながらボトルネックにならないプラットフォーム――です。

継続的なケイパビリティとしてのカスタム開発。 毎月30か月間、毎月3〜4件の小規模なカスタム改善——これが、ワンショットの納品ではなく、機能するパートナーシップのリズムです。標準モジュールのロードマップが、ブローカーに必要な大部分をカバーします。カスタム層は、ブローカー特有の“端の部分”を扱います。どちらも同じプラットフォーム上で動きます。

IB主導の成長エンジンをスケール。トレーダーベースの45%が、インプラットフォームのIBプログラムによるもの。低い数百の規模でアクティブなIBロスターを持ち、その下により広いサブIBの裾野が広がります。継続的にコミッションを支払い、完全な監査ログを備えたマルチティアのリベートエンジン。IBモジュールは、このエンゲージメントで最も拡張されたモジュールであり、ブローカーの成長と最も直接的に相関しているモジュールでもあります。

ロックインなしのマルチPSP冗長構成。ブローカーはローンチ時に1つのPSPから開始し、現在は決済連携を4つに加え、手動レールも運用しています。各連携間でスマートルーティングを行っています。単一のプロセッサが日次上限に達する、または地域レールがダウンした場合でも、オペレーターの介入なしに入金を代替チャネルへ振り替えます。

スケールにおける信頼性。プラットフォームで処理される取引履歴全体において、入金と出金の完了率が99.9%超。実際にブローカの運用担当者が体感するのは、この指標です——大見出しのAUMの数字ではなく、入金がクリアされ、出金がエスカレーションなしに処理されるかどうかです。

これは、私たちが望む形で機能しているときのKenmoreのエンゲージメントの姿です。高速なローンチ、スムーズな移行、安定したプラットフォーム。そして、ビジネスを消費するのではなく事業とともに複利で効いていくカスタム開発のリズム。

一目でわかる主要KPI

指標	値
契約から稼働システムまでの期間	約5週間
継続稼働の月数	30+
トレーダーベースの成長 — 移行後のベースラインから現在まで	1.55×
四半期の入金取扱高 — 年3 vs 年1（同一の暦四半期）	11×
月次の入金取扱高のピーク vs 初期ローンチのベースライン	130×+
出金対入金の取扱高比率（定常状態）	約0.7〜0.9
登録トレーダーベースにおけるIB帰属シェア	45%
ネットワーク内のアクティブな紹介ブローカー（IB）	低い数百
プラットフォーム上で定義された口座タイプ設定	110+
口座タイプのプロダクト名の種類	35
Trader’s RoomおよびCRMでサポートされている言語	2（English, Arabic — RTL対応）
本番稼働中のPSP連携	4（プラス手動の銀行＆amp;暗号資産レール）
取引プラットフォーム	MT5のみ — プラットフォーム移行なし
登録トレーダーにおけるメール確認率	約90%
登録トレーダーに占めるKYC承認シェア	約71%
登録トレーダーのうちアクティブ口座シェア	約74%
入金の完了率（ステータス：completed）	98.9%
出金の完了率（ステータス：completed）	99.4%
ローンチ後に出荷したカスタム改善	30か月で130+
管理側（オペレーションチーム）の規模	数十名の管理者

---