RTX5 Broker Automations: IB, Groups and Rewards
Preview broker workflows for approved triggers, group assignments, IB commissions and eligible rewards. Confirm the supported build, run the acceptance scenarios and approve each rule before it changes an account or ledger.
Broker Operations, With Explicit Controls.
This preview describes how broker teams can specify onboarding, IB, group and reward automations. Availability is subject to the selected CRM and server build. Keep approval, permissions and reconciliation separate from trader algorithms; the examples below are workflow specifications rather than deployment evidence.
Define Broker Events
Start with a permitted onboarding, account, trade or payment event and record its stable identity.
Assign a Responsible Operator
Document the broker runtime, support responsibility and pause/recovery policy for the proposed workflow.
Test Before You Approve
Replay representative eligible, excluded and duplicate events without changing live accounts.
Reconcile Every Action
Trace the rule version, approver, account change and ledger result from the source event.
Automate broker operations with explicit rules
Broker automations act on client, account and payment events. Define the trigger, eligible population, action and approval before connecting a rule to a live account.
Swipe horizontally to view all columns.
| Trigger | Eligibility check | Proposed action and record |
|---|---|---|
| Onboarding approved | Approved client, permitted country and available account product. | Request account provisioning in an approved group; retain the onboarding decision and resulting account reference. |
| Group assignment requested | Operator scope, account eligibility and effective trading conditions. | Review and apply the approved group version; record the prior group and effective time. |
| Eligible trade finalized | Account's IB agreement, eligible volume and applicable commission schedule. | Accrue a commission entry linked to the original trade and schedule version. |
| Deposit settled | Confirmed provider result, client/campaign eligibility, amount and currency. | Evaluate an optional campaign once; keep the cash deposit and any promotional credit in separate records. |
| Transaction reversed or campaign expired | Linked original event, remaining entitlement and reversal policy. | Create a compensating adjustment and record the reason; preserve original event history. |
Broker Rule Execution Starts with Scope.
Use these acceptance requirements to evaluate a proposed broker rule engine. Support for each control must be demonstrated on a named build; this page does not establish native MQL or universal Expert Advisor compatibility.
Assign a Rule to an Account Group
Select only eligible accounts and identify the operator allowed to change the group rule.
Coordinate Concurrent Rules
Specify ordering and conflict handling when more than one rule can act on the same event.
Version Rule Parameters
Record thresholds, recipients, currency, expiry and the configuration version used for evaluation.
Restrict Rule Times and Sessions
Specify timezone, campaign opening and closing times, and treatment of delayed events.
Separate Operational and Trading Risk
A reward or commission rule must not silently alter account trading limits or permissions.
Review Rule Outcomes
Compare accepted, excluded, duplicate and failed actions with their source-event records.
Broker rules and trader algorithms: Broker operations and hosted trading algorithms have different permissions and lifecycles. Review the RX5 runtime proposal separately, including package compatibility, start/stop confirmation, disconnection and restart behavior.
Define the Contract Before Activation.
Broker workflow configuration is separate from source-code migration. Native MQL execution is not established here; the proposed Rust/RX5 development and migration guides describe the evidence needed for supported source constructs, packages and runtime behavior.
Versioned Rule Configuration
Record a rule identifier, configuration version and owner before connecting it to broker events.
Supported Operation Contract
List the documented account, group, commission and ledger operations available in the selected build.
Dry-Run Diagnostics
Expected output identifies the rule branch, eligibility decision and reason for rejection.
Event Processing Measurements
Measure processing delay, retries and resource usage against the proposed workload.
Input and Schema Validation
Validate currency, amount, account and event fields before calculating any action.
Dependency Inventory
Document external connectors, schema versions and permissions used by the workflow.
Approval Before Activation
Record review and approval before enabling a tested rule in its permitted account scope.
Make Broker Rules Reviewable by Operators.
A visual editor is a proposed interface option, not a verified release claim. Evaluate whether the selected build exposes the required broker triggers, eligibility gates and approvals before relying on a no-code workflow.
Proposed Visual Rule Definition
Specify the required trigger, eligibility checks, action and error path before selecting a rule editor.
Supported Trigger Register
Record which broker events the agreed build can process and the fields supplied with each event.
Explicit AND / OR Logic
Use sample events to verify condition precedence, missing values and excluded clients.
Action Output Definition
Describe the requested group change, notification or ledger entry and its approval boundary.
Reviewable Dry Run
Expected output shows the selected rule branch and proposed account or ledger effect without posting.
Controlled Activation
Approve a specific rule version and permitted scope; retain a pause and rollback procedure.
Configuration and Source Migration
Do not assume a visual rule exports MQL or Rust source. Confirm the actual configuration format and version contract; use the source-migration guide for a separate assessment of trading code.
Turn an Eligible Event Into A Reviewed Action.
Proposed broker event chains connect a source record to a permitted operational action. Confirm supported triggers and actions on the agreed build; capture excluded accounts, approval decisions and expected ledger effects in the dry run.
Onboarding-to-Account Request
After approved onboarding, propose an account request in an eligible group and retain the decision reference.
Account-to-Group Assignment
Use a versioned eligibility rule to request a group change; reject accounts outside the operator scope.
Trade-to-Commission Calculation
Calculate the proposed IB commission from eligible volume, recipient and rule version before posting.
Reversal-to-Commission Correction
Link a cancelled or corrected trade to its original commission and produce a traceable adjustment.
Event-to-Notification Dispatch
Specify authenticated notifications with a stable event ID, retry policy and delivery outcome.
Approved Multi-Action Sequence
Define each dependency and reconcile an unknown result before issuing the next action.
Scope Proposed Broker-Hosted Algorithms.
Proposed hosting runs compatible algorithms in the broker runtime. The cards below describe three review areas for the same proposed hosting range, not separate quantity tiers. Confirm resources, supported packages and service terms at /buy-platform before ordering.
Package and Runtime Compatibility
Confirm the RX5 package and broker runtime versions before proposing a hosted algorithm.
Device and Runtime Independence
A broker-hosted process may continue when the phone is offline; verify start, stop and reconnect outcomes.
Resource and Isolation Scope
Agree memory, CPU, concurrency, tenant isolation and operator responsibility in the deployment record.
Measured Connection Boundary
Request a dated latency result with region, workload and measurement boundary rather than a universal target.
Authorized Runtime Monitoring
Confirm the clients and roles permitted to read status and request runtime controls.
Recovery Acceptance
Test a runtime interruption, duplicate requests and reconciliation before any restart is accepted.
Proposed Broker Hosting Scope
Prices are planning values; account scope, resources, billing and service terms require confirmation.
Package Review
Scope: Confirm package compatibility and broker runtime access.
Runtime Review
Scope: Confirm resource limits, billing scope and accepted start/stop behavior.
Operations Review
Scope: Confirm workload capacity, recovery and service responsibilities.
Validate Broker Rules With Known Event Fixtures.
Broker-rule validation replays operational events and compares expected account and ledger effects. These are proposed acceptance requirements, not completed test results. Trading-strategy backtesting is documented separately under Backtesting Documentation.
Timestamped Event Fixtures
Use authorized, sanitized broker events with known account, group and ledger starting states.
Event-by-Event Replay
Compare each eligibility decision and proposed action with a reviewed expected result.
Reconciliation Report
Expected output includes source IDs, rule versions, recipient amounts, exclusions and differences.
Parameter Boundary Cases
Test amounts exactly below, equal to and above the configured threshold or cap.
Duplicate and Failure Cases
Replay duplicates, late events and unknown downstream results to check that money is not posted twice.
Separate Review Fixtures
Reserve independent sample events for acceptance after the rule configuration is agreed.
Reversals and Currency Precision
Include cancelled trades, refunded deposits, rounding and currency-unit policies in the expected ledger.
Compare Rule Outcomes Before Approval.
Use a controlled review to select broker-rule settings and document why they are appropriate. An automated optimizer or export format is not verified by this page; request supported functions and acceptance outputs for the selected build.
Compare Rule Parameters
Evaluate documented threshold and cap alternatives against the same permitted event fixture.
Commission Tier Review
Compare recipient amounts at each tier boundary, including reversals and partial corrections.
Choose Operational Review Criteria
Review eligibility, ledger correctness, exclusions and processing failures rather than optimizing reward volume alone.
Avoid Fitting One Campaign
Test different account groups, currencies, time boundaries and permitted client categories.
Boundary-Value Review
Check how a small input change affects the selected tier, cap or expiry decision.
Export Review Results
Require an agreed export showing fixtures, configuration versions, expected results and differences.
Separate Product and Policy Decisions
A passing fixture does not approve a campaign for every client or jurisdiction. The broker must approve its eligibility, financial treatment and operating scope before activation.
Connect an Approved Event Source.
Broker integrations need a documented contract for each supported route. No third-party connection becomes live through its name on this page; request the adapter version, authentication scope and successful and failed-event test records.
Outbound Event Notifications
Specify destination, schema, authentication, event ID and delivery acknowledgement for each notification.
Inbound Broker Events
Validate a trusted source and versioned payload before requesting an approved broker action.
External Signal Boundaries
TradingView or another named service is a compatibility target; a tested connector and operator permissions are required.
Operator Notifications
Define what a messaging integration may disclose and which actions require the broker console.
Operational Report Export
Agree the supported fields and access scope before exporting account or ledger records.
Risk and Oversight Feed
Specify permitted recipients, record retention and reconciliation responsibilities for external oversight.
Webhook Acceptance Requirements
Test invalid credentials, malformed payloads, replays, expired requests and unknown delivery outcomes. Record the supported authentication method and verify that failed authorization produces no account or ledger change.
Review the Record Behind Each Action.
These monitoring requirements describe the evidence to request for a broker automation demonstration. Confirm which views, event fields and controls the selected build provides; no live dashboard or update latency is established here.
Rule Status Overview
Require an operator view of enabled, paused, pending-approval and failed rule executions.
Recipient and Ledger Reconciliation
Trace each proposed or posted commission and reward to its source event and recipient.
Timestamped Audit Records
Expected records identify event time, processing time, actor, rule version and resulting action.
Errors and Exceptions
Define the alert recipient and review process for a rejected action or unresolved downstream result.
Campaign Limit Notifications
Specify thresholds for caps, expiry and unusual event volume without silently changing the rule.
Authorized Pause and Resume
Test who can pause or resume a rule and how queued events are handled after the change.
Control the Scope of Broker Actions.
Proposed broker controls should be tested before a rule affects live accounts. The acceptance record must show permitted and denied cases, queued-event handling and reconciliation; this page does not certify enforcement on an unspecified build.
Campaign Amount Cap
Reject or cap a proposed reward according to its approved currency and policy; record the calculation.
Per-Recipient Limits
Specify maximum credits or commissions per eligible recipient and time window.
Concurrent Action Limits
Define how pending and completed actions count toward a shared account or campaign limit.
Exception-Triggered Pause
Test the pause decision and disposition of queued work after an exception threshold is reached.
Eligibility and Time Gates
Exclude restricted jurisdictions, client categories and events outside the campaign window.
Cash and Credit Boundaries
Keep withdrawable cash, restricted bonus credit and IB commission entries separately identifiable.
Duplicate-Action Prevention
Use a stable business-action identity and verify retries cannot create another reward or payment.
Evaluate a Proposed RX5 Package.
The RX5 Marketplace is a proposed discovery and licensing workflow. This page does not establish a catalogue count, verified publisher record or universal package compatibility; consult the marketplace scope and approved terms before use.
Versioned Package Evidence
Request the package version, compatible runtime and reproducible test inputs before evaluation.
Clearly Identified Test Results
Separate illustrative, backtested and observed execution records; retain their dates and scope.
Publisher and Reviewer Identity
Use disclosed author and review information rather than unverified adoption or rating claims.
Demo Eligibility and Terms
Confirm whether a package offers a demo and what its licence permits before installation.
Publisher Scope
Confirm who maintains the package, handles support and approves updates.
Installation Acceptance
Test package permissions, installation, stop and removal on the supported client build.
Publisher Commercial Terms
Publication, demo access, licence scope, refunds and revenue arrangements require approved terms. Do not assume every package may be sold, trialled or deployed from this workflow description.
Keep Allocation Rules Separate from Rewards.
PAMM, MAM and copied trading require an investor mandate and verified allocation behavior. They are separate from IB commissions and promotional credits. Review the fund-manager allocation examples and confirm supported modes on the selected build.
Recipient and Mandate Approval
Require explicit authority for any proposed allocation or copied trading action.
Account-Relative Sizing
Specify the allocation basis, account snapshot and currency conversion used in the example.
Instrument and Account Filters
Record eligible instruments and accounts and demonstrate that excluded accounts are untouched.
Loss-Limit Response
Define the measured limit, comparison and permitted pause action; retain the expected denial result.
Multiple Source Reconciliation
Prevent overlapping sources from bypassing exposure limits or creating duplicate instructions.
Mobile Access Depends on Verified Client Scope.
Mobile monitoring and control are proposed workflows. Confirm iOS or Android availability, the named build and each supported task before relying on remote access; broker-hosted execution and phone connectivity have separate lifecycles.
Rule Status on a Supported Client
Confirm which account and rule records the tested mobile build can display.
Operational Notifications
Test notification delivery and escalation for errors without treating a push message as execution confirmation.
Authorized Remote Controls
Demonstrate allowed and denied pause/resume actions and reconcile their server results.
Approval Boundaries
Keep rule edits and financial approvals within the permitted staff role and client interface.
Broker Runtime Health
Request runtime identity, last confirmed state and recovery records from the responsible operator.
Define Broker Operations at the Required Scale.
Institutional deployments need a documented workload and acceptance review. No account count, latency, uptime or compliance certification follows from this page; agree supported functionality and commercial scope with the responsible teams.
Multiple Broker Rule Sets
Separate account groups, event sources, recipients and operators for each approved rule set.
Team Approval Boundaries
Demonstrate requester, approver and reviewer permissions, including denied cross-group actions.
Runtime Resource Scope
Agree capacity, isolation, monitoring and recovery responsibilities for the proposed deployment.
Adapter-Specific FIX Scope
Confirm the FIX dictionary, permitted messages, sessions and certification results for the requested route.
Reviewable Audit Output
Require records linking source event, configuration version, approval and resulting action.
Versioned Operations API
Request the actual contract, permission scopes, retry behavior and tested examples before integration.
Deployment Scope Review
Bring the expected event volume, account groups, required connectors and oversight workflow to a scoped demonstration.
Connect Broker Workflows Through a Defined API.
The API and SDK interfaces remain subject to published versioned contracts and sandbox evidence. Use the API documentation to prepare required operations and expected outputs; no Python or JavaScript SDK release is claimed by this preview.
Versioned Broker API Contract
Request the supported account, group, commission and rule operations with explicit authorization scopes.
Event Schema and Delivery
Specify event identifiers, ordering, reconnect and replay behavior for the agreed API version.
Supported SDK Inventory
Confirm which SDK language and version has tested examples; Python availability is not established here.
Client Integration Scope
Verify the documented browser or service integration and its authentication boundary before implementation.
Webhook Contract Guidance
Use the API guidance to specify authentication, validation, retries and reconciliation requirements.
Sandbox Acceptance Fixtures
Request permitted demo accounts and fixtures for positive, denied, duplicate and failed-action cases.
Understand the Controls Before Activation.
This page supplies preview guidance and worked examples for broker teams. Build-specific tutorials require tested steps, supported interfaces and reviewer records; use Help and API documentation for the current published scope.
Broker Event and Group Basics
Start with the event source, eligible account group, operator scope and resulting record.
Versioned Rules and Migration Boundaries
Separate broker rule configuration from MQL-to-Rust source assessment and RX5 runtime compatibility.
Dry Runs and Approval
Review representative eligible and excluded events before approving a rule version for activation.
Commission and Reward Reconciliation
Follow the worked IB reversal and reward examples, including caps, expiry and separate ledger treatment.
Operational Failure Scenarios
Prepare duplicate-event, denied-action, outage and recovery cases with explicit expected outputs.
Calculate IB commissions and linked reversals
An introducing-broker agreement needs an eligible volume definition, rate, hierarchy, settlement currency and reversal policy. The following fictional two-level schedule illustrates the accounting.
Swipe horizontally to view all columns.
| Recipient | Original accrual | Correction for 3 lots | Remaining accrual |
|---|---|---|---|
| Direct IB | 12 × $4 = $48 | −3 × $4 = −$12 | $36 |
| Parent IB | 12 × $1 = $12 | −3 × $1 = −$3 | $9 |
| Total | $60 | −$15 | $45 for 9 eligible lots |
Swipe horizontally to view all columns.
| Campaign | Eligibility and amount | Expiry and accounting |
|---|---|---|
| Deposit campaign example | 10% of an eligible settled deposit, capped at $200, once per eligible client. A $1,000 deposit creates a $100 credit under this example. | Example expiry: 30 days from award. State timezone, withdrawal effects, reversal rules and whether unused credit expires; cash remains a separate ledger. |
| No-deposit campaign | Explicit client and jurisdiction eligibility, identity checks, award limit and repeat-participation controls. | Define expiry, permitted use and any conversion/withdrawal conditions before enrollment. No-deposit does not imply unrestricted cash. |
| Group or IB campaign | Approved group membership and a versioned agreement; define whether membership is evaluated at trigger or settlement time. | Record the effective group/rate version, campaign owner and treatment of group changes or revoked eligibility. |
Test, approve and audit each automation
A repeated event or uncertain provider response should not create a duplicate reward, commission or account action. Agree the controls and test them before a rule is enabled.
- 01
Dry-run a versioned rule
Use representative, permitted sample events to show eligible and excluded accounts, proposed actions and ledger effects. A dry run calculates proposed outcomes without posting money or changing live groups.
- 02
Approve a bounded activation
Record the approver, rule version, account scope, campaign limits and effective time. Separate authoring from approval where the broker policy requires it.
- 03
Deduplicate and reconcile
Define a stable business-action identity from the source event, action and recipient. Record the rule version assigned on first processing and retain that version on every replay; editing a rule must not create a second reward for the same action. Reprocessing returns the existing result, and an unknown downstream result is reconciled before another action is issued.
- 04
Pause and correct
Define who can pause future actions, handle in-flight work and issue a linked reversal. Keep rule inputs, decision reasons, approvals, outcomes and corrections available in the audit record.
Swipe horizontally to view all columns.
| Test event | Expected policy behavior |
|---|---|
| Same settled deposit delivered twice | One eligible reward; second delivery points to the first result. |
| Ineligible client enters a campaign | No award; retain the eligibility decision and reason. |
| A credited deposit is later reversed | One linked correction under the campaign policy; retain both cash and credit histories. |
| Rule changes while events are pending | Use the agreed effective-time policy and preserve the version applied to each decision. |
Questions About Broker Automation.
Review the proposed workflow and the evidence required before activation.
How are broker automations different from trader algorithms?
Is a no-code broker rule editor already available?
Can several rules act on one event?
What happens when a broker integration disconnects?
Are broker rules independent of a staff member's device?
How should a rule be tested before approval?
Can an external webhook trigger a broker action?
How do promotional credits differ from cash and commission?
How are multi-team permissions checked?
How are restricted clients excluded from campaigns?
Can a team sell an automation package through the marketplace?
What limits and prices apply to hosted algorithms?
Review Your Broker Automation Workflow.
Bring one onboarding, IB, group or reward scenario to a scoped demonstration. Confirm supported triggers, approval boundaries and expected ledger outputs before enabling a live rule.