Answer

The short answer: IB onboarding is a document lifecycle

When people search for introducing broker onboarding templates, most expect a single template for the referral email they send a client. In practice, the work of an introducing broker (IB) is never finished by one email. You verify a partner, hand off the referral, disclose compensation and conflicts, communicate with the client, summarize the agreement, and report the ongoing status — and these are several linked documents whose audience, purpose and disclosure scope all differ. Designing that whole set around who each document is for, what it settles, and in what order it is kept is where organizing IB documentation begins.

Put differently, IB onboarding documents are not a single page shown to the client but a bundle of records: checked internally, connecting you to the partner, disclosed to the client, used by an approver to decide, and verifiable afterward. Even from the same case information, the scope you should disclose to a client differs from the undetermined notes you should keep only internally. That is exactly why splitting documents by audience, recording compensation and conflicts as facts, and never filling unverified fields by guessing form the foundation of transparency and repeatability. IB work is one area within financial-document templates that span everything from investment and trading records to client-ready drafts; for the wider picture, see the Financial Document Templates Guide.

What this article covers is the type, role and separation of information in these documents. It does not judge the validity of contract terms, whether registration is required, the legality of compensation, or regulatory compliance. Those requirements change with country or region, registration status, product and compensation model, and should be confirmed against the official sources for the relevant jurisdiction and with qualified professionals. Every figure, table and mini-tool value here is a fictional educational case — not a real institution, client, product or contract, and not a finished document ready to file or send. Reading alongside the IB operations templates in the Financial Templates Hub makes each document’s place easier to see.

Terms and purpose

Terms and purpose: why keep six documents

Seen as a document lifecycle, IB onboarding breaks into six documents with distinct roles. Fixing what each one exists to settle — for whom, and to confirm what — keeps the rest of the design consistent.

• Partner-verification request: an internal and partner-facing record for gathering the basic details and evidence of a prospective counterparty (such as a partner broker). It lines up name, location, registration or licensing claims, covered products, compensation terms, contacts, source documents and unverified fields.
• Introduction email to the partner: an external document that hands the case to the partner. It carries the minimum necessary facts and states what will be checked or communicated next.
• Compensation and conflict-of-interest disclosure: a client-facing document that shows who may receive what from whom, and whether that can move with trading volume or a product.
• Client onboarding checklist: an internal checklist that confirms nothing in the client communication is missing, making done / not done / needs-check visible.
• Referral-agreement summary: a summary that lets internal reviewers and approvers grasp the key points of an executed agreement quickly. It does not replace the underlying agreement.
• Monthly activity report: a periodic record, for partner and approver, of status after the referral — case state, unresolved items and next actions.

These are “types of template,” not a list of legally required documents. How far each is needed varies by jurisdiction and registration status. For the wider design of recording client interactions such as meeting notes, see the financial advisor client meeting notes template article; for organizing the evidence, disclaimers and approvals behind client-facing claims and advertising, see the financial advertising review checklist article.

Lifecycle

The lifecycle: from partner check to ongoing reporting

IB onboarding documents are created in order as the case progresses. The SVG below shows the five-stage lifecycle — partner check → agreement review → client communication → onboarding → ongoing reporting (it scrolls horizontally). Skip a stage and later disclosures or reports lose the trail back to their evidence.

The heart of this diagram is the early partner check and the compensation and conflict disclosure at stage 4. Enter the referral at stage 3 without settling those, and disclosures to the client lack an evidence base, while the monthly report at stage 5 cannot reconstruct when and what was checked. From here we look first at how to split documents by audience (the audience matrix), then at how to record compensation and conflicts.

Audience matrix

Document matrix: split by internal, partner, client and approver

Even for the same case, purpose, disclosure scope, tone and required checks change across internal, partner-facing, client-facing and approver-facing use. The table below is a general organizing view of the six documents by audience and purpose (it scrolls horizontally). Not mixing the same information into one document prevents over-sharing and omission at the same time.

The point is to keep internal notes out of the client-facing disclosure, and to keep the necessary unresolved items in the internal record. Disclose compensation and conflicts to the client clearly, and internally keep the basis for each check, the owner and the due date. Hold this separation firmly and you end up able to trace which version went to whom. How to split versions and think about diffs is covered in detail in the document version control, approvals and audit-trail article.

Compensation and conflicts

Compensation and conflicts: record facts, not vague wording

Compensation and conflicts of interest are the most delicate part of IB work. Wrap them in vague wording — “the usual referral fee,” “by separate arrangement” — and no one can verify them later. The purpose of a referral fee disclosure template is to record separately, as facts, who may receive what, from whom, and on what conditions. The SVG below is a relationship diagram of the compensation and information flow in the fictional case (it scrolls horizontally).

The conflict this diagram shows is the relationship in which “the client’s trading volume may feed the IB’s compensation.” Rather than hiding it, write it into the disclosure as a fact. The fields to keep in a compensation and COI disclosure can be organized as follows.

What matters here is not filling in a number by guessing while the rate is unsettled. Keep it as undetermined, with an owner and a due date attached. The template only helps you find gaps in these fields and record facts, observations, inferences and opinions separately; it does not judge whether that compensation design is lawful or whether the conflict disclosure is sufficient. Required disclosure wording and presentation rules vary by jurisdiction and registration status, so always confirm against official sources and professionals.

One consistent fictional case

The fictional case document pack and timeline

Let us run everything so far through one fictional case. The copy, tables and tool that follow all use the same names, dates and statuses.

North Gate Partners (a fictional IB corporation) refers a partner broker, Meridian Markets (fictional), to a client (case code C-2026-014, anonymous). The product is a generic CFD example, and compensation is a volume-linked rebate (rate undetermined). The documents are created on the following timeline.

Looking at this pack, you can see the evidence gathered in the June 15 partner check carry through to the June 22 agreement summary and the July 1 compensation disclosure. If the rate is still undetermined on July 1, keep undetermined in the disclosure and add the confirmation or update in the monthly report. Rather than ghost-writing a whole finished document, holding this heading structure, short field examples, before/after review, and unresolved flags is what makes a document verifiable later.

Role allocation

RACI: split drafting, review, approval and sharing

Once documents are split by audience, decide who drafts, who reviews, who approves and who shares. When the drafter and the approver are the same person, the objectivity of the disclosure suffers. The table below assigns responsible (R), consulted/checked (C), accountable/approve (A) and shared (S) roles to the fictional case pack — an educational RACI example (it scrolls horizontally).

The compensation / COI disclosure shared with the client, the introduction email going out externally, and the agreement summary and monthly report an approver uses to decide should each pass an approval (A) that is separate from drafting. Documents that stay purely internal, such as the verification request and checklists, can run with review (C) alone. Holding this role allocation as a field in the document lets you trace afterward “whose review it passed, and when it was shared.” How to design the stages of an approval workflow and keep the evidence trail is covered in the document governance article.

Mini-tool

IB document-pack planner

Choose relationship type, audience, stage, compensation status, language and approval need, and it shows the document categories that may be relevant, each document’s audience, the facts to gather, the reviewer and a guide to unresolved flags. This is teaching material for getting a feel for the workflow; it does not produce a verdict on legally required documents, whether registration is needed, or a partner rating. Even with JavaScript off, the defaults and static example output below show how to read it.

This planner is simplified teaching material for getting a feel for the workflow in the article. It may differ in part from the real service’s template names, categories and features, and it does not exhaust every combination of relationship and stage. Do not enter sensitive data such as a client’s name, address, account number or identity-document number (this tool neither transmits nor stores input). Confirm the formal templates and features in the free Financial Templates Hub.

Failure modes

Failure modes and review steps

The common places to stumble with IB onboarding documents are below. Each happens when you drift from the principles of “split the documents” and “record facts.”

• Internal notes leak into a client-facing document: reusing one document lets undetermined notes and internal judgments a client should not see slip out. Split versions by audience.
• Compensation left in vague wording: stopping at “by separate arrangement” makes who receives what from whom impossible to verify. Write the receiving party, paying party, type, conditions and verification date separately.
• Leaving undetermined items blank: blanking a field while the rate or cross-border eligibility is unsettled invites it to be misread as final. Keep undetermined with an owner and a due date.
• Mistaking the summary for the agreement: treating a referral-agreement summary as the agreement itself hides mismatches with the underlying document. State the underlying version and date and that the underlying agreement prevails.
• Writing sensitive data into the document body: putting a client’s account number or identity data directly into a document leaks it when shared. Link with a case code and separate storage and access rights.

As a review step, before sharing, check top to bottom: “is the audience right,” “is the disclosure scope neither too much nor too little,” “are any items still undetermined,” and “do the numbers, dates, proper names and mandatory wording match.” Templates and QA help confirm such unfilled variables, wording, structure and the presence of disclaimers, but they do not guarantee legal compliance, safety, reliability, client suitability or completion of KYC/AML. Passing the checks does not mean it clears screening, withstands an audit, or is safe.

Sensitive data

Handling and separating sensitive data

Sensitive data such as a client’s name, address, date of birth, account number and identity documents should not go into the document body beyond what is necessary. Write only a case code or reference ID in the document, and keep sensitive data under separate storage and access rights. This way, when you share a document with a partner or approver, you avoid the accident of the sensitive data traveling with it.

• Only identifiers in the body: write only a reference like “case code C-2026-014” in the document, and keep the actual client data managed separately.
• Separate access rights: define separately who may access the sensitive data, where it is kept and when it is deleted. Retain only the minimum necessary.
• State the sharing scope in the document: give each version a “shared with” and “retention policy” field so it does not reach unintended recipients.

Where input, output and history are processed and stored depends on the tool and settings you use. Avoid absolute expressions like “safe” or “completely private,” and confirm the actual processing and storage method against the current implementation and terms of use. The mini-tool on this page displays and processes in your browser and neither transmits nor stores input externally, but sensitive data should be handled with fictional, anonymized values in the first place. The mapping of terminology, figures and mandatory wording when handling client documents in multiple languages is covered in detail in the multilingual financial document templates article.

Using the Hub

Using the Hub: Free → Pro → Premium

Once you understand how to split the documents, confirm the actual IB operations templates in SG Group’s Financial Templates Hub. Use grows in stages as the operation broadens.

1. Confirm and use the structure on Free: with the free templates you can use without registration, confirm the fields and headings each document is built from, and use basic QA to spot gaps. The backbone of this article — “split the documents” and “record facts” — can be grasped here first. Confirm the specific templates and output available on the free page in the implementation.
2. Use it in real work on Pro: use the current IB operations template set in real work, with multilingual output such as Japanese and English, QA that checks for unfilled variables and mandatory wording, multiple output formats and a defined period of local output history. If you reuse the same formats and tailor them per case, this is the stage.
3. Operate and govern on Premium: use operational features such as client-specific template sets, version control and diffs, multi-stage approvals, branding and approved standard clauses, client and case workspaces, and hash or manifest evidence records. This is the stage where cases grow and approvals and evidence need managing.

The scope, number of languages, history period and account limits of each feature can change, so rather than fixing them in the copy, confirm the latest on the plans page as the single source of truth. Templates support drafting; they are not investment, legal or tax advice, a regulatory-compliance verdict, a provider assessment, or a substitute for screening or an audit. Related cost calculation and risk documentation are covered in the FX and CFD lot size calculator guide, the trading cost calculator guide, and the risk management plan template article.

Summary

Summary: answering the main query and the next step

What you really need for “introducing broker onboarding templates” is not a template for one email but a design that splits documents by audience and stage. Along the five stages — (1) partner check, (2) agreement review, (3) referral and client communication, (4) onboarding (compensation and conflict disclosure), (5) ongoing reporting — split the internal, partner-facing, client-facing and approver-facing documents, record compensation and conflicts as facts with “who, from whom, what,” and do not fill undetermined items by guessing. That is the backbone of organizing IB documentation.

In practice, five points keep you from going far wrong: (1) split versions by audience, (2) record compensation and COI as facts, (3) keep an owner and due date on undetermined items, (4) do not mistake the summary for the underlying agreement, and (5) separate sensitive data from the body. Because requirements change with country or region, registration status, product and compensation model, always confirm legal requirements against official sources and professionals. Start by confirming the structure of the same kinds of templates as this article’s fictional case in the free Hub.

Related

Related reading

Related cluster: version control, approvals and audit-trail design is in the document governance article, and finding templates starts from the English article index. Organizing the macro backdrop is covered in the macro analysis guide, and strategy validation in the TradingView backtesting guide.