How to Start an Online Brokerage: An Evidence-Led Launch Plan

Define the business before choosing software

The launch begins with a permissions and responsibility map, not a platform demonstration.

Write a one-page operating-model statement that names the proposed legal entities, decision-makers, countries, client classifications, products, venues or counterparties, account structures, marketing channels, custody arrangements, payment flows, and revenue sources. Distinguish dealing as principal, arranging, introducing, advising, managing, executing, safeguarding, and technology-only activities. Similar websites can conceal very different regulated activities. The label "broker" is not a permission, and incorporating a company is not authorisation to provide financial services.

Map the lifecycle of money, orders, data, and complaints. For each step, identify who contracts with the client, who holds or controls funds, who performs identity and sanctions checks, who sets trading terms, who receives an order, who decides its routing, who is the execution counterparty, who calculates balances, and who resolves disputes. This map gives counsel and regulators concrete facts to assess. It also exposes dependencies that a vendor brochure may hide.

State exclusions and launch boundaries. If a product, country, client type, referral channel, payment method, or execution model is not approved for the first release, mark it out of scope in configuration and marketing. A credible plan is narrower than a list of every market the founders hope to enter. Expansion should be treated as a change to the operating model, with a fresh permissions, risk, technology, and disclosure review.

Build a jurisdiction and permissions matrix

Create a matrix with one row for every proposed combination of entity, country, product, client type, and activity. Record the regulator or other competent authority, applicable regime, required permissions, local-presence considerations, capital and insurance questions, conduct obligations, reporting, marketing restrictions, and the legal opinion owner. Do not infer that one licence permits worldwide solicitation. Cross-border rules can depend on where the client is located, how the service is promoted, and which entity performs each activity.

Official regulator material should anchor the analysis, but application pages are not a substitute for tailored advice. The UK Financial Conduct Authority tells applicants to determine whether authorisation is needed, prepare final documents, and be ready, willing, and organised. ASIC says an Australian financial services licence assessment considers competence, financial resources, and the ability to meet ongoing obligations. The CFTC explains that intermediaries in covered U.S. futures activity are generally required to register. These are different regimes, not interchangeable routes.

Record both the legal conclusion and the facts on which it depends. For example, a conclusion may assume no local retail solicitation, no custody, no advice, or a particular counterparty structure. If product or marketing teams later change that fact, the assumption register should trigger review. Keep dated copies or references to official materials because rules, portals, forms, fees, and regulatory expectations change.

Design governance, capital, and accountable ownership

Translate the proposed business into an organization chart with named decision rights. Assign owners for regulatory reporting, financial crime, client money or safeguarding where applicable, dealing and conflicts, best execution, complaints, product governance, security, privacy, business continuity, finance, outsourcing, and vendor risk. A job title alone is insufficient: document delegated authorities, independent challenge, escalation thresholds, committee cadence, and evidence retained.

Prepare base, downside, and severe-but-plausible financial forecasts. Include regulatory capital or other prudential resources where applicable, licensing and adviser costs, staff, insurance, banking, payment processing, market data, liquidity, platform, connectivity, hosting, cybersecurity, audit, reporting, chargebacks, complaints, and orderly wind-down. Separate client money from the firm's operating cash in the model. Confirm every regulatory calculation and buffer with advisers for the specific permission set.

Regulators assess people as well as documents. Controllers, senior managers, responsible managers, and other key individuals may need to demonstrate competence, fitness, propriety, time commitment, and effective oversight. Build evidence from genuine experience and working procedures rather than generic policy templates. The management team should be able to explain the business model, major risks, outsourced services, financial assumptions, client outcomes, and what it will do when a control fails.

Specify the full brokerage control environment

Document onboarding from first visit to account closure. Cover marketing approval, geographic eligibility, identity and business verification, sanctions and politically exposed person screening, risk assessment, appropriateness or suitability where relevant, classification, disclosures, agreements, funding-source checks, deposits, withdrawals, ongoing monitoring, account restrictions, complaints, retention, and data-subject requests. Assign systems of record and manual fallbacks.

Define trading controls separately. Product approval should cover instrument specifications, sessions, price sources, corporate actions, margin, leverage, negative-balance treatment where applicable, stop-out, financing, commissions, markups, order types, rejection logic, market disruption, error trades, and changes to trading conditions. Execution governance should connect the disclosed model to measurable routing, pricing, slippage, rejection, conflict, and counterparty oversight.

Treat reconciliations as launch-critical product requirements. Reconcile cash, client ledgers, payment providers, bank statements, positions, trades, liquidity counterparties, fees, swaps, commissions, partner remuneration, and general-ledger postings at defined frequencies. Set tolerances, investigation workflows, ageing, correction authority, and independent review. A visually complete client portal is not ready if operations cannot prove balances and resolve breaks.

Procure technology against responsibilities and evidence

Break the stack into capabilities: public website, consent and analytics, onboarding, KYC and screening, client portal, CRM, payments, account and ledger services, trading front end, order and execution services, pricing and market data, risk, liquidity connectivity, reporting, communications, monitoring, security, and data warehouse. A supplier may bundle several capabilities, but the contract and architecture should identify each component, dependency, subprocessor, and service boundary.

Require vendors to label functions as generally available, configurable, custom, third-party, beta, roadmap, or unsupported. Ask for current documentation, architecture and data-flow diagrams, interface specifications, environment model, release policy, security responsibilities, incident process, recovery evidence, support coverage, pricing assumptions, and exit support. Product marketing can establish what a supplier says publicly; only the proposal and contract define what your entity receives.

RTX5 publishes plan-specific CRM, bridge and FIX options on its broker pricing page. Use that as the commercial starting point for a launch brief, then confirm hosting, market-data rights, payment connections, support, adapter scope and acceptance criteria in the written quote. Product licensing does not provide company formation, regulatory permission or a committed launch date.

Test operations, failure paths, and launch readiness

Build acceptance cases from client and operational journeys. Test registration, failed verification, duplicate identity, deposit and withdrawal exceptions, account creation, permission changes, quotes, each order type, partial fills, rejection, cancellation, margin events, session boundaries, corporate actions where relevant, statements, complaints, account suspension, and closure. Include different roles, currencies, locales, devices, and accessibility needs. Capture evidence and trace every result to a requirement.

Exercise failure paths rather than relying on a polished demonstration. Simulate a payment-provider outage, stale market data, liquidity disconnection, delayed execution report, message duplication, database recovery, key staff absence, third-party incident, and a discrepancy between client and counterparty records. Verify alerts, ownership, safe degradation, client communication, reconciliation, and recovery. Recovery objectives should name the service, data-loss expectation, dependency assumptions, and evidence from an actual test.

Use a formal go-live decision with unresolved-risk visibility. Minimum inputs include permission status, signed supplier contracts, production configuration, penetration and vulnerability findings, reconciliations, support rosters, monitoring, runbooks, incident and complaint procedures, training, client disclosures, rollback criteria, and sign-offs from accountable owners. A commercial deadline should not silently waive legal or operational readiness.

Launch in controlled stages and supervise continuously

A controlled launch limits products, countries, clients, volumes, funding methods, and operational complexity while the team validates real workflows. Define thresholds for increased exposure and conditions that stop expansion. Compare production outcomes with acceptance assumptions: onboarding failure, funding delays, order rejection, execution quality, reconciliation breaks, support demand, fraud indicators, complaints, system capacity, and vendor responsiveness.

Create a change process that sends new products, markets, promotions, counterparties, vendors, integrations, algorithms, and material configuration through legal, compliance, risk, security, finance, and operational review. Record the rationale, testing, approvals, client communication, effective date, monitoring, and rollback. Platform flexibility does not make a change automatically permitted or safe.

Maintain an evidence library rather than treating authorisation and go-live as finish lines. Keep board and committee records, monitoring outputs, reconciliations, incident reviews, complaints analysis, vendor assessments, training, financial forecasts, policy attestations, access reviews, recovery exercises, and regulatory correspondence. Revisit the original operating-model statement when the business evolves; otherwise the website, contracts, platform settings, and permissions can drift apart.