IB顧客オンボーディング文書テンプレート|紹介・手数料開示・月次報告を整理
Financial Templates Hub — IB業務シリーズ FH06
IB顧客オンボーディング文書テンプレート|紹介・手数料開示・月次報告を整理
IB オンボーディング テンプレートは、一通の紹介メールを作る道具ではありません。提携前確認、紹介、報酬・利益相反の開示、顧客案内、契約要約、月次報告という、対象者も目的も違う文書を「誰向けに・何の順番で残すか」で分ける、文書ライフサイクルの設計です。この記事では、一貫した架空の教育用ケースで6種の文書パックを整理し、無料テンプレートからProの多言語出力への道筋を示します。
- IBオンボーディングを6種の文書に分けて考える
- 社内/提携先/顧客/承認者で開示範囲を変える
- 報酬・利益相反は「誰が誰から何を」を事実で記録する
- 本文・図表・ツールの例はすべて架空の教育用ケース
この記事の要点
- IBオンボーディングは一通のメールではなく、提携前確認→契約確認→紹介前→顧客案内→月次レビューと続く文書ライフサイクルである。
- 同じ案件でも、社内用・提携先用・顧客共有用・承認者用で目的・開示範囲・トーン・必須確認が異なる。文書を混ぜない。
- 報酬・利益相反は曖昧語で隠さず、「誰が・誰から・何を・どの条件で受け取り得るか」「確認日」「根拠文書」「未確定事項」を分けて記録する。
- 顧客の氏名・口座番号・本人確認情報はテンプレート本文に入れず、保存場所とアクセス権を案件コードで分離する。
- 本文・表・SVG・ミニツールの値はすべて架空の教育用ケース。テンプレートは文書作成の補助であり、事業者評価・登録要否・法的適合の判定ではない。
目次を開く
結論
結論:IBオンボーディングは「文書ライフサイクル」である
IB オンボーディング テンプレートを探すとき、多くの人が期待するのは「顧客へ送る一通の紹介メールのひな形」です。しかし実務のIB(Introducing Broker、紹介業者)業務は、一通のメールでは完結しません。提携先を確認し、紹介の橋渡しをし、報酬と利益相反を開示し、顧客を案内し、合意を要約し、継続状況を報告する——これらは対象者も目的も開示範囲も異なる、複数の文書が連なるライフサイクルです。この全体を「誰向けに・何を・どの順番で残すか」で設計することが、IB業務の文書整理の出発点になります。
言い換えると、IBオンボーディングの文書は「顧客に見せる一枚」ではなく、「社内で確認し、提携先とつなぎ、顧客へ開示し、承認者が判断し、後から検証できる記録の束」です。同じ案件情報でも、顧客に開示すべき範囲と、社内だけで持つべき未確定メモは違います。だからこそ、文書を対象者ごとに分け、報酬・利益相反を事実として記録し、未確認の項目を推測で埋めないことが、透明性と再現性の土台になります。IB業務は投資・トレード記録から顧客向け文書まで扱う金融文書テンプレートの一分野で、全体像は金融文書テンプレート完全ガイドで俯瞰できます。
本記事で扱うのは、文書の種類・役割・情報の分離です。契約条項の妥当性、登録の要否、報酬の適法性、規制への適合は判断しません。これらは国・地域、登録区分、対象商品、報酬構造で要件が変わり、対象法域の公式資料と有資格の専門家で確認すべき事項です。掲載する数値・図表・ミニツールの値はすべて架空の教育用ケースであり、実在する金融機関・顧客・商品・契約ではなく、そのまま提出・送付に使える完成文書でもありません。まずはFinancial Templates HubのIB業務テンプレートを見ながら読み進めると、各文書の位置づけが掴みやすくなります。
用語と目的
用語と目的:6種の文書は何のために残すか
IBオンボーディングを文書ライフサイクルとして捉えると、役割の違う6種に分解できます。まずそれぞれが「誰のために・何を確定させるために残すのか」を押さえると、後の設計が一貫します。
- IB提携先確認依頼:提携を検討する相手(提携先ブローカー等)の基本情報と根拠を集めるための社内・提携先向け記録。名称、所在、登録・許認可の主張、対象商品、報酬条件、連絡先、根拠文書、未確認欄をそろえます。
- IB提携先への紹介メール:案件を提携先へ橋渡しする外部向け文書。必要最小限の事実と、次に何を確認・案内するかを示します。
- IB報酬・利益相反開示:顧客に対し、誰が誰から何を受け取り得るか、それが取引量や商品に連動し得るかを示す顧客共有向け文書。
- 顧客オンボーディングチェック:顧客案内の抜けを確認する社内向けチェックリスト。案内済み・未案内・要確認を可視化します。
- 紹介契約サマリー:締結済み契約の要点を社内・承認者が短時間で把握するための要約。原契約の代わりではありません。
- IB月次活動報告:紹介後の継続状況を提携先・承認者向けに記録する定期報告。案件の状態、未確定事項、次アクションを残します。
これらは「テンプレートの種類」であって、法的に必須な文書の一覧ではありません。どの文書がどこまで必要かは法域と登録区分で変わります。顧客との面談記録のように、より広い顧客対応の記録設計はIFA・FP面談記録テンプレートの記事、顧客向け表示や広告の根拠・免責・承認の整理は金融広告審査チェックリストの記事で扱います。
ライフサイクル
文書ライフサイクル:提携前確認から継続報告まで
IBオンボーディングの文書は、案件の進行に沿って順番に生まれます。次のSVGは、提携前確認→契約整理→顧客案内→オンボーディング→継続報告という5段階のライフサイクルを示したものです(横スクロールできます)。段階を飛ばすと、後の開示や報告で根拠がたどれなくなります。
この図の要は、序盤の①提携前確認と、④で行う報酬・利益相反の開示にあります。ここを固めずに③紹介から入ると、顧客への開示に根拠が付かず、⑤月次報告で「いつ・何を確認したか」を後追いできません。以降では、まず対象者ごとに文書をどう分けるか(文書マトリクス)、次に報酬・利益相反をどう記録するかを順に見ていきます。
対象者別マトリクス
文書マトリクス:社内・提携先・顧客・承認者で分ける
同じ案件でも、社内用・提携先用・顧客共有用・承認者用では、目的・開示範囲・トーン・必須確認が変わります。次の表は6種の文書を対象者と目的で整理した一般的説明です(横スクロールできます)。同じ情報を一つの文書に混ぜないことが、情報の出しすぎと出し漏れを同時に防ぎます。
| 文書 | 主な対象 | 目的 | 開示範囲 | 必須確認 |
|---|---|---|---|---|
| 提携先確認依頼 | 社内 提携先 | 提携先情報と根拠を集める | 内部が広い | 登録主張・根拠文書・未確認欄 |
| 紹介メール | 提携先 | 案件の橋渡し | 必要最小限 | 事実の正確さ・送付先 |
| 報酬・COI開示 | 顧客 | 報酬と利益相反を示す | 顧客に明確 | 誰が誰から何を・条件・確認日 |
| オンボーディングチェック | 社内 | 案内の抜けを確認 | 内部のみ | 案内済み/未案内/要確認 |
| 紹介契約サマリー | 社内 承認者 | 合意要点を短時間で把握 | 内部・承認者 | 原契約の版・日付・優先 |
| 月次活動報告 | 提携先 承認者 | 継続状況を記録 | 合意した範囲 | 状態・未確定・次アクション |
ポイントは、顧客共有向けの開示に社内メモを混ぜないこと、そして社内向けの記録から必要な未確定情報を落とさないことです。顧客には報酬・利益相反を分かりやすく開示し、社内では確認の根拠・担当・期限まで残します。この分離を徹底すると、後で「どの版を誰に渡したか」を追える状態になります。版の分け方や差分の考え方は文書の版管理・承認フロー・監査証跡の記事で詳しく扱います。
IB業務テンプレートの構造を無料で確認する
提携先確認・紹介・報酬開示・顧客チェック・契約サマリー・月次報告——各テンプレートがどんな項目で構成されるかは、無料のFinancial Templates Hubで実際に見て確かめられます。まず構造を掴んでから、自分の案件に合わせて整えましょう。
無料テンプレートで構造を確認する報酬・利益相反
報酬・利益相反:曖昧語で隠さず事実で記録する
IB業務で最も慎重に扱うべきは、報酬と利益相反です。「所定の紹介料」「別途取り決め」といった曖昧語でまとめると、後から誰も検証できません。紹介手数料 開示 テンプレートの目的は、誰が・誰から・何を・どういう条件で受け取り得るかを事実として分けて記録することです。次のSVGは、架空ケースにおける報酬と情報の流れを示した関係図です(横スクロールできます)。
この図が示す利益相反の核心は、「顧客の取引高がIBの報酬に連動し得る」という関係です。これを隠すのではなく、開示に事実として書きます。報酬・COI開示に残すべき欄は、次のように整理できます。
| 記録欄 | 架空ケースの記入例 | 状態 |
|---|---|---|
| 受け取る側 | IB:ノースゲート・パートナーズ(架空) | 確認済み |
| 支払う側 | 提携先:メリディアン・マーケッツ(架空) | 確認済み |
| 報酬の種類 | 取引高連動リベート(想定) | 確認済み |
| 算定の考え方 | 顧客の約定量に応じた料率(例示) | 未確定 |
| 利益相反の内容 | 取引量増でIB報酬が増え得る | 確認済み |
| 確認日/根拠 | 2026-06-22/契約ドラフト v0.3 | 確認済み |
| 未確定・確認担当 | 料率・越境提供の可否/確認担当:内部レビュー | 要確認 |
ここで重要なのは、料率が決まっていない段階で数字を推測で埋めないことです。未確定として残し、確認担当と期限を添えます。テンプレートは、こうした欄の抜けを見つけ、事実・観察・推定・意見を分けて記録するのを助けるだけで、その報酬設計が適法か、利益相反の開示が十分かを判定するものではありません。開示の必須文言や表現要件は法域と登録区分で変わるため、必ず公式資料と専門家で確認してください。
一貫した架空ケース
架空ケースの文書パックとタイムライン
ここまでの考え方を、一つの架空ケースで通してみます。以降の本文・表・ツールでも、同じ名称・日付・状態を使います。
ノースゲート・パートナーズ(架空のIB法人)が、提携先ブローカーのメリディアン・マーケッツ(架空)を、ある顧客(案件コード C-2026-014、匿名)へ紹介するケースです。対象は一般的なCFDの例、報酬は取引高連動リベート(料率は未確定)とします。文書は次のタイムラインで生まれます。
| 日付 | 段階 | 文書 | 対象 | 状態 |
|---|---|---|---|---|
| 2026-06-15 | 提携前確認 | IB提携先確認依頼 | 社内 | 確認中 |
| 2026-06-22 | 契約整理 | 紹介契約サマリー | 承認者 | 承認待ち |
| 2026-06-29 | 紹介 | IB提携先への紹介メール | 提携先 | 下書き |
| 2026-07-01 | 顧客案内 | 報酬・COI開示+オンボーディングチェック | 顧客 | 確認待ち |
| 2026-07-31 | 継続報告 | IB月次活動報告 | 提携先 | 未着手 |
このパックを見ると、6/15の提携前確認で集めた根拠が、6/22の契約サマリー、7/1の報酬開示へと引き継がれていくのが分かります。7/1時点で料率が未確定なら、開示にも未確定を残し、月次報告で確定・更新を追記します。完成した長文を丸ごと代筆するのではなく、こうした見出し構造・短い記入例・確認前/確認後の差・未確認フラグを持つことが、後から検証できる文書の条件です。
役割分担
RACI:作成・確認・承認・共有を分ける
文書を対象者ごとに分けたら、次は「誰が作り・誰が確認し・誰が承認し・誰が共有するか」を決めます。作成者と承認者が同一だと、開示の客観性が損なわれます。次の表は架空ケースの文書パックに、作成(R)・確認(C)・承認(A)・共有(S)の担当を割り当てた教育用のRACI例です(横スクロールできます)。
| 文書 | IB担当(作成) | 内部レビュー | 承認者 | 共有先 |
|---|---|---|---|---|
| 提携先確認依頼 | R | C | — | S:社内 |
| 紹介契約サマリー | R | C | A | S:承認者 |
| 紹介メール | R | C | A | S:提携先 |
| 報酬・COI開示 | R | C | A | S:顧客 |
| オンボーディングチェック | R | C | — | S:社内 |
| 月次活動報告 | R | C | A | S:提携先・承認者 |
顧客へ共有する報酬・COI開示や、外部へ出す紹介メール、承認者が判断に使う契約サマリー・月次報告には、作成とは別の承認(A)を通すのが基本です。一方、社内だけで完結する確認依頼やチェックリストは、確認(C)まででも回せます。この役割分担を文書の欄として持っておくと、「誰の確認を経て、いつ共有したか」が後から追えます。承認フローの段階設計や証跡の残し方は、文書ガバナンスの記事で扱います。
ミニツール
IB文書パック・プランナー
関係形態・対象者・進行段階・報酬の状態・言語・承認要否を選ぶと、必要になり得る文書カテゴリ、各文書の対象、集める事実、レビュー担当、未確定フラグの目安を表示します。これは工程を体感するための教材で、法的に必須な文書、登録の要否、提携先評価の結論は出しません。JavaScriptが無効でも、下の初期値と静的な出力例で読み方が分かります。
このプランナーは、記事の工程を体感するための単純化した教材です。実サービスのテンプレート名・カテゴリ・機能とは一部異なることがあり、関係形態と段階の組み合わせを網羅もしていません。顧客の氏名・住所・口座番号・本人確認番号などの機微情報は入力しないでください(このツールは入力を送信も保存もしません)。正式なテンプレートと機能は無料のFinancial Templates Hubで確認してください。
失敗例
失敗例と確認手順
IBオンボーディングの文書でつまずきやすいのは、次のような点です。いずれも「文書を分ける」「事実で記録する」という原則から外れたときに起きます。
- 顧客共有文書に社内メモが混入する:一つの文書を使い回すと、顧客に見せるべきでない未確定メモや内部の判断が漏れます。対象者ごとに版を分けます。
- 報酬を曖昧語で済ませる:「別途取り決め」で止めると、誰が誰から何を受けるかが検証できません。受け取る側・支払う側・種類・条件・確認日を分けて書きます。
- 未確定を空欄で放置する:料率や越境提供の可否が未確定なのに空欄にすると、確定済みと誤読されます。
未確定と確認担当・期限を残します。 - サマリーを契約と取り違える:紹介契約サマリーを合意そのものとして扱うと、原契約との食い違いに気づけません。原契約の版・日付と「原契約が優先」を明記します。
- 機微情報を文書本文に書く:顧客の口座番号や本人確認情報を文書へ直接書くと、共有時に流出します。案件コードで紐づけ、保存場所とアクセス権を分けます。
確認手順としては、共有前に「対象者は正しいか」「開示範囲は過不足ないか」「未確定は残っていないか」「数値・日付・固有名詞・必須文言は一致するか」を上から順にチェックします。テンプレートやQAは、こうした未入力変数・表現・構成・免責の有無の確認を助けますが、法令適合・安全性・信頼度・顧客適合性・KYC/AML完了を保証するものではありません。チェックを通過したことは、審査に通る・監査に対応できる・安全である、といった結論を意味しません。
機微情報
機微情報の扱いと分離
顧客の氏名、住所、生年月日、口座番号、本人確認資料などの機微情報は、テンプレート本文に必要以上に入れないのが基本です。文書には案件コードや参照IDだけを書き、機微情報は保存場所とアクセス権を分けて管理します。こうすると、文書を提携先や承認者へ共有するときに、機微情報まで一緒に渡ってしまう事故を防げます。
- 本文には識別子だけ:文書には「案件コード C-2026-014」のような参照だけを書き、実際の顧客情報は別管理にします。
- アクセス権を分ける:誰が機微情報にアクセスでき、どこに保管し、いつ削除するかを別途定めます。必要最小限だけを保持します。
- 共有範囲を文書に明記:各版に「共有先」「保持方針」を持たせ、想定外の相手に渡らないようにします。
なお、入力・出力・履歴がどこで処理・保存されるかは、利用するツールや設定で変わります。「安全」「完全なプライバシー」といった絶対的な表現は避け、実際の処理・保存方式は現行の実装と利用条件で確認してください。本記事のミニツールはブラウザ内で表示・処理し、入力を外部へ送信・保存しませんが、そもそも機微情報は架空・匿名データで扱う設計にすべきです。多言語で顧客文書を扱う場合の用語・数値・必須文言の対応関係は日英・多言語金融文書テンプレートの記事で詳しく扱います。
Hubでの利用
Hubでの利用:Free→Pro→Premium
文書の分け方を理解したら、SG GroupのFinancial Templates Hubで実際のIB業務テンプレートを確認します。利用は、業務の広がりに応じて次のように段階的に対応します。
- Freeで構造を確認・利用する:登録不要で使える無料テンプレートで、各文書がどんな項目・見出しで構成されるかを確認し、簡易QAで抜けを見ます。本記事の「文書を分ける」「事実で記録する」の骨格は、まずここで掴めます。無料ページで使える具体的なテンプレートや出力は実装で確認してください。
- Proで業務利用する:現行のIB業務テンプレート群を業務で使い、日英など複数言語での出力、記入漏れや必須文言の有無を確認するQA、複数の出力形式、一定期間のローカル出力履歴などを活用します。同じ様式を案件ごとに繰り返し整えるならこの段階です。
- Premiumで運用・ガバナンスする:顧客別のテンプレートセット、版管理と差分、複数段階の承認、ブランドや承認済み定型文、顧客・案件ワークスペース、ハッシュ/マニフェスト等の証跡といった運用機能を使います。案件が増え、承認と証跡の管理が必要になった段階です。
各機能の対応範囲・言語数・履歴期間・アカウント数は変更され得るため、本文には固定せず、最新はプランページを唯一の正として確認してください。テンプレートは文書作成の補助であり、投資助言・法律助言・税務助言・規制適合判定・事業者評価・審査や監査の代行ではありません。関連するコスト計算やリスク文書化は、FX・CFDロット計算完全ガイド、取引コスト計算完全ガイド、リスク管理計画テンプレートの記事で扱っています。
全テンプレート・多言語出力をProで比較する
無料で構造を掴んだら、現行のIB業務テンプレート群、日英などの複数言語出力、記入漏れ・必須文言のQA、複数の出力形式が、業務にどう効くかをプランページで比較できます。
全テンプレート・多言語出力をProで比較するFAQ
よくある質問
IB顧客オンボーディングではどの文書が必要ですか?
IB報酬開示には何を記録しますか?
紹介契約サマリーは契約書の代わりになりますか?
顧客向けと社内向けで文書を分ける理由は?
提携先確認テンプレートで安全性を判断できますか?
複数言語の顧客文書はどう管理しますか?
顧客の本人確認情報をテンプレートへ保存してよいですか?
ProとPremiumはIB業務でどう使い分けますか?
まとめ
まとめ:主質問への回答と次の一歩
「IB オンボーディング テンプレート」で本当に必要なのは、一通のメールのひな形ではなく、対象者と段階で文書を分ける設計です。①提携前確認、②契約整理、③紹介・顧客案内、④オンボーディング(報酬・利益相反開示)、⑤継続報告——この5段階に沿って、社内用・提携先用・顧客共有用・承認者用の文書を分け、報酬・利益相反を「誰が誰から何を」で事実として記録し、未確定を推測で埋めない。これがIB業務の文書整理の骨格です。
実務では、(1)対象者ごとに版を分ける、(2)報酬・COIを事実で記録する、(3)未確定に確認担当と期限を残す、(4)サマリーと原契約を取り違えない、(5)機微情報を本文から分離する——この5点を押さえれば大きく外しません。国・地域、登録形態、商品、報酬構造で必要事項は変わるため、法的な必須要件は必ず公式資料と専門家で確認してください。まずは無料のHubで、この記事の架空ケースと同じ種類のテンプレートの構造を確認してみましょう。
次に読む
FH07:IFA・FP面談記録テンプレート|顧客説明・確認事項・フォローアップを残す — 顧客との面談・説明の記録設計へ進むと、オンボーディング後の顧客対応が整います。
免責事項
- 本記事は、IBオンボーディング文書の種類・役割・情報分離を教育目的で解説する記述的なコンテンツです。テンプレートは文書作成の補助であり、投資助言、法律助言、税務助言、規制適合判定、事業者評価、審査・監査の代行ではありません。契約条項の妥当性、登録の要否、報酬の適法性、顧客勧誘や越境紹介の可否を判断・保証するものではありません。
- 掲載したIB「ノースゲート・パートナーズ」、提携先「メリディアン・マーケッツ」、顧客「案件コード C-2026-014」、日付・報酬・状態はすべて架空の教育用ケースであり、実在する金融機関・顧客・商品・契約ではありません。同じ例示を本文・図・表・ミニツールで一貫して用いており、そのまま提出・送付に使える完成文書ではありません。
- 出力QAやチェックリストは、未入力変数・表現・構成・免責文の有無などの確認を補助するもので、法令適合、安全性、信頼度、顧客適合性、KYC/AMLの完了を保証しません。チェック通過は、審査に通る・監査に対応できる・安全である、といった結論を意味しません。顧客向け・広告・契約・同意・免責・適合性・報酬開示等の要件は、法域・登録区分・商品・対象者で変わるため、対象法域の公式資料と有資格の専門家で確認してください。
- 顧客の氏名・住所・生年月日・口座番号・本人確認番号などの機微情報は、記事のミニツールや文書本文に入力・保存しないでください。本記事のミニツールと図表はブラウザ内で表示・処理し、入力を外部へ送信・保存しません。「安全」「完全なプライバシー」等の絶対表現は避け、実際の処理・保存方式は現行の実装と利用条件で確認してください。プラン別の機能・料金・対応範囲・履歴期間・アカウント数は変更され得るため、最新はプランページを唯一の正としてご確認ください。
参考資料
- SG Group Financial Templates Hub(https://sggroup.jp/ja/financial-templates-hub/)
- SG Group Financial Templates Hub プラン一覧(https://sggroup.jp/ja/financial-templates-hub/plans/)
- 金融庁(Financial Services Agency, Japan)(fsa.go.jp)
- 証券取引等監視委員会(SESC)(fsa.go.jp/sesc)
- 消費者庁(Consumer Affairs Agency)(caa.go.jp)

