パートナーに前のブローカーを辞めた理由を聞いても、レートが低すぎたという答えはほとんど返ってきません。返ってくるのは、入金が遅れた、誰かに催促してやっと入金された、あるいはある月だけ不足していて、誰も理由を説明できなかった、という話です。
パートナーコミッションは収益です。チャネルや代理店を運営するIBは、その収益から人件費を支払っています。月次の支払い処理を単なるバックオフィス業務として扱うブローカーは、ネットワーク内のすべてのパートナーに対して、彼らの収益は優先度が低いと静かに伝えているのと同じです。そしてパートナーは、それに応えて自分の顧客を別の場所へ移します。
これはパートナープログラムの運用面の話です。レートの決め方は別の論点であり、これは commission structure guide で扱っています。ここで扱うのは、実際に資金を外へ出す方法です。
パートナーにとっての「期日どおりに支払われる」とは何か
パートナープログラムでは2つのことが起きますが、ブローカーはしばしばそれらを混同します。コミッションは顧客の取引に応じて継続的に発生し、コミッションは一定のスケジュールで支払われます。パートナーはその両方を、別々の理由で重視します。
発生額はリアルタイムで見える必要があります。月の途中でもダッシュボードを開けば、ここまでにいくら稼いだかを確認できるパートナーは、実際に入ってきた数字も信頼します。月に一度しか数字を見られないパートナーには、それが正しいかどうかを確かめる手段がないため、食い違いが出るたびに疑問ではなく争いになります。Kenmoreの multi-level IB module は、ライブのMT4およびMT5の取引データに基づいて計算し、発生額をその場でパートナーポータルに表示するため、ほとんどの争点を未然に防げます。
その次に必要なのは、支払いが予測可能であることです。必ずしも早い必要はありません。予測可能であることが重要です。毎月5日に着金すると分かっているパートナーは、それを前提に計画できます。3日から12日のどこかで支払われるパートナーにはそれができず、4日になった時点で問い合わせを始めます。
スケジュールの決め方
月次が一般的な標準であり、ほとんどのプログラムでは問題なく機能します。ただし、最初の紹介報酬を受け取るまでに長く待つことになるため、初回支払いが多くの新規パートナーにとって沈黙の始まりになります。
週次または隔週は処理コストが高くなりますが、新しいパートナーや、より短いサイクルで動く地域では十分に回収できます。現実的な妥協案は、パートナーシップの最初の数か月は速いサイクルにし、その後、関係が固まったら月次にすることです。パートナーは早く現金を受け取れるので、それが目的です。
どの方法を選ぶにせよ、明示してください。スケジュールはパートナー契約書とポータルに記載し、次回の支払日がダッシュボードで見えるようにします。
しきい値と繰り越し
最低支払しきい値は、送金コストの方が大きくなる12ドルを国際送金で支払ってしまう事態を防ぎます。パートナーがしきい値を受け入れるのは、次の2条件が満たされている場合です。しきい値が事前に明示されていること、そして残高が失効せずに繰り越されることです。
しきい値は全体で一律にするのではなく、支払い方法ごとに設定してください。cryptoでの支払いはbank wireよりはるかに低い金額でも経済的に成立するため、全方法を一律のしきい値にすると、安価に送れる小口支払いを止めてしまうか、採算の合わないwireを無理に通してしまいます。
繰り越された残高はポータルに表示してください。パートナーが「しきい値未満、次回サイクルへ繰り越し」と見れば、何が起きたかを理解できます。何も表示されなければ、コミッションが消えたと思われます。
通貨
コミッションは自社の口座通貨で発生します。パートナーは、それを実際に使える通貨で受け取りたいのです。
ナイジェリアの代理店にドルで支払うのは一見太っ腹に見えますが、本人が選んでいないレートで両替されて目減りすれば意味がありません。費用がユーロ建てのヨーロッパのパートナーにドルで支払うのも、理由なく為替リスクを相手に押し付けているだけです。
為替差損を自社で吸収するのか、相手に負担させるのかを決め、文書化し、一貫して適用してください。パートナーはどちらの方針でも受け入れます。受け入れないのは、少ない支払い額を見て初めてその方針を知ることです。
地域別のレール
すべての地域で使える単一の方法はありません。これはクライアント側ですでに解決した問題と同じです。multi-PSP routing のインフラはここでも使えますが、1つ違いがあります。パートナー支払いは外向きであり、件数は少なく、1件あたりの金額は大きいという点です。
bank transferは、銀行インフラが整った市場で、特に高額の支払いをする場合に、確立されたパートナーには有効です。ただし遅く、手数料がかかり、送金経路によっては単純に失敗することもあります。
地域の支払いレールこそ、現地の代理店が実際に求めているものです。パートナーの居住国でのlocal bank transferは、国際送金よりも速く、安く決済でき、IBネットワークが最も速く伸びるいくつかの市場では、これが唯一確実に機能する方法です。
e-walletは、カードや銀行インフラが脆弱な市場のパートナーをカバーし、決済も速いです。
stablecoinおよびcryptoでの支払いは、かなりの割合のパートナー、特にコミュニティオーナーや国境を越えて活動する人たちの標準になっています。決済が速く、手数料は予測可能で、パートナーはコルレス銀行を待つ必要がありません。crypto決済に関する運用要件は crypto payment gateway guide で扱っており、その多くはパートナー支払いにそのまま適用できます。
2つか3つの方法を用意し、パートナーに選ばせるのはコストが小さく、繰り返し発生する摩擦を取り除きます。payment solutions の解説は提供側の話ですが、複数プロバイダにまたがってルーティングするなら aggregation model を理解しておく価値があります。
送金手数料を誰が負担するか
パートナーが少ない支払い額を不審に思う前ではなく、最初の支払い前に決めてください。
どちらの方針も正当化できます。手数料を自社負担する方が明快で、パートナーの照合作業も簡単になります。高額な方法、特により安い方法が使えるのにその方法を選んだ場合は、相手負担にするのも妥当です。
問題なのは、手数料が予告なく差し引かれることです。契約書に明記し、支払記録には明細として表示し、支払い処理の前にパートナーが純額を確認できるようにしてください。
パートナーに見せるべき内容
支払いを照合するパートナーは、誰にも連絡せずに次の3点を確認したいのです。どの期間の支払いか、どの顧客とどのレベルが発生源か、そして総額がどのように純額になったかです。
そのため、支払い記録には期間、顧客別または紹介別の取引量、配下にネットワークを持つパートナー向けのレベル別コミッション、しきい値繰り越し、手数料、そして方法と日付を含む純額が必要です。サブパートナーを持つパートナーにとっては、どの部分のネットワークが成果を出しているかに注目するため、レベル別の内訳が特に重要です。
これはレポーティング業務であり、他の CRM reporting と並ぶものです。一度構築すれば、パートナーチームの恒常的な負荷を取り除けます。
承認、コンプライアンス、書類対応
パートナーへの支払いは事業者への支払いであり、クライアントの出金とは別のカテゴリに分類されます。
パートナーは最初の紹介の前ではなく、最初の支払いの前に本人確認を完了しておく必要があります。オンボーディング時にパートナーのKYCを行うと、何のメリットもなく採用が滞ります。成果を出さないパートナーは支払いも発生しないためです。最初の支払い時に実施すれば、サインアップの摩擦を増やさずに必要な確認はすべて行えます。文書の扱いも、すでに運用しているKYC and AML workflowと同じです。
パートナーが請求書を発行するのか、それともこちらが自社計上で支払うのかを決め、一貫して運用してください。会社として活動している大口パートナーは、通常は請求書発行を望みます。個人パートナーは通常その対応能力がなく、自社の会計士に渡せる自社計上の明細のほうが有用です。
あらかじめ設定した閾値を超える支払いには、承認ゲートを設けてください。実行前に1人が内容を確認するだけで、本来なら一度に50人のパートナーに影響してしまう設定ミスを防げます。
支払いが失敗したとき
必ず起こります。銀行が送金を拒否する、ウォレットアドレスが誤っている、パートナーの情報が変わったのに誰も更新していない、といったことです。
関係性を損なう失敗は、何も知らせないことです。支払いが戻っていたのに空の口座を見て初めて気づいたパートナーは、ブローカーが支払わなかったと思います。同日にメッセージを受け取ったパートナーは、ブローカーが対応していると分かります。
アラートはパートナー側だけでなく、ブローカー側にも設定してください。パートナーチームはパートナーより先に失敗を把握できるべきです。また、失敗した金額は調整キューに消えるのではなく、パートナーの残高に目に見える形で戻るべきです。
リクエストではなく、スケジュールで実行してください
パートナーの依頼があったときだけ支払う仕組みのプログラムは、成長するほど支払い管理に費やす時間の割合が増えていきます。目指すべきは、誰もスプレッドシートを開かなくても実行される定期実行です。コミッションは実取引データから計算され、ツリーが各レベルに配分し、閾値と手数料が適用され、1回の承認に回されて、資金が移動します。
これは実現可能で、主にコミッションエンジンが取引サーバーに直接接続されているか、それとも誰かがレポートを書き出して手作業で照合しているかの問題です。後者の方法はパートナーが20社なら成り立ちますが、200社になると破綻します。
Kenmore Designは2006年からブローカー向けにこのレイヤーを構築してきました。multi-level IB moduleは、無制限の階層、pipsベースのコミッション、スプレッドの割合、利益または入金、あるいはロットごとのキャッシュを、通常口座とセント口座の両方で処理し、パートナー側レポートとMT4およびMT5連携を、月額定額料金で提供します。今パートナーを募集しているなら、recruitment guideとenablement guideで最初の支払い前に起こることを確認できます。
IB支払い戦略の構築に関するご相談を依頼する
Introducing Brokerネットワーク向けに、信頼性の高いコミッション支払いの仕組みを設計するための専門的なアドバイスを受けましょう。支払いスケジュール、最低支払い基準額、通貨換算、支払い方法、承認プロセス、パートナー向けレポートを評価し、予測可能で透明性の高いコミッション支払いを実現できるよう支援します。
一緒に現在のパートナー支払い業務を見直し、貴社のブローカー業務の財務プロセスと長期的な成長に合致した支払い戦略を策定します。
