A hierarchy is not a permission model.

Agent & Distributor Platform Development

Build agent management, sub-agent controls and commission records around the network your operation can authorize.

Specify your agent network
Agent network console with master-agent hierarchy, scoped player access, commission calculation and statement review
The service, clearly defined

What is an iGaming agent and distributor platform?

Agent and distributor software manages a defined network of business users, their permissions, reporting and agreed commercial relationships. It is distinct from an affiliate tracking system: agents may perform operational functions that require additional financial and access controls. The exact authority of each role is established in the project scope.

Define network delegation, verification and revocation

The architecture records which entity can create or manage another, what each role may view and which actions require approval. A hierarchy should not automatically imply unlimited access to descendant player records or balances. We define revocation, transfer and suspension behavior so staff changes do not leave uncontrolled accounts in the network.

Map the distributor, master-agent and sub-agent tree to separately approved powers: create an account, view a branch, assign a player, change a plan, request allocation or approve settlement. Record onboarding evidence and any operator-required agent verification before activation. Inherited permissions cannot exceed the approved parent scope; transfers, suspension and revocation must address active sessions, API credentials, queued jobs and outstanding obligations as well as the visible hierarchy.

  • Distributor, agent and sub-agent role model
  • Delegated access and approval boundaries
  • Onboarding, suspension and ownership transfer
DEFINE EACH AUTHORITY SEPARATELY
Create a sub-agent

Does not imply access to every descendant player record.

View activity

Does not imply permission to change a balance or settlement.

Revoke or transfer

Needs an explicit ownership and session policy.

COMMISSION RULE SPECIFICATION

A statement needs
an explainable basis.

Rule version
Approved effective plan
Calculation basis
Agreed eligible activity
Effective context
Defined statement period
Source activity
Eligible records and linked adjustments
Approval
Permissioned review before settlement

Historical statements retain their applicable rule and period when a branch is transferred or access is revoked. The agreed calculation and approval process determine the statement.

Version commission, credit allocation and settlement rules

Revenue share, fixed fees, turnover-based arrangements and other permitted plans need documented calculation rules. We define the underlying data, settlement periods, adjustments and approval process. If credit or balance allocation is part of the approved operation, it receives its own ledger and limit model rather than being implemented as an editable number in a dashboard.

Specify whether the calculation uses turnover, GGR, NGR or another approved basis, including deductions, taxes or fees where applicable, currency, tier rates, negative carryover and statement cutoff. Keep player funds, network allocation and commission payable on distinct records. Limit changes and concurrent allocation requests need controlled approval and reconciliation. Effective-time player or branch transfers preserve earlier statements and route late settlements, reversals and corrections through explicit adjustment rules.

  • Versioned commission and adjustment rules
  • Settlement statements and approval workflows
  • Credit, allocation and reconciliation controls
Scope and responsibilities

Map the network, financial model and approval rights.

A hierarchy interface is only one part of an agent platform. Agree who can onboard users, adjust credit, approve payments and change commissions within the intended operating arrangement.

WorkstreamProject scopeDependencies to confirm
Hierarchy and accessCommission agreed distributor/agent levels, roles and account boundaries.Approved network structure and authorized operating permissions.
Commissions and creditImplement the selected rules, balances, settlement and correction workflow.Defined accounting model, approval limits and contractual terms.
Network operationsBuild performance views, exception queues and activity evidence.Consistent data definitions, data access and review responsibilities.
Questions before the next move.

Agent permissions, commissions and network questions

Discuss your requirements
Is an agent platform an affiliate platform?

Not necessarily. Affiliates usually refer and track traffic, while an agent may be authorized to perform operational tasks. We separate acquisition attribution from account, financial and administrative authority before choosing shared modules.

Can agents create sub-agents?

That can be implemented where the operating model permits it. Delegation limits, approval, data access, revocation and reporting need explicit rules rather than unrestricted hierarchy creation.

Can we configure different commission plans?

Yes, within the agreed model. Each plan should define its calculation basis, eligible activity, negative adjustments, timing and approval. We preserve the applicable rule version with each settlement period.

How do you prevent one agent seeing another network?

The authorization model applies hierarchy and role boundaries on server-side data access, reports and actions. Acceptance testing includes cross-agent access attempts and audit evidence for delegated changes.

What happens to commission history when a player moves to another agent?

The transfer needs an effective time, an authorized approver and a record of both assignments. We define whether activity is attributed by its original event time or another agreed cutoff, including late settlements, reversals and corrections. Closed statements retain their original assignment and rule version; any permitted adjustment is recorded separately. Tests compare both branches so the transfer cannot silently duplicate commission or rewrite an approved period.

What is needed to scope an agent or distributor platform?

Supply the intended hierarchy, products and markets, role/approval matrix, player-assignment rules, commission plans, permitted allocation model and existing platform interfaces. Include migration records, reporting needs and agent-onboarding requirements. The proposal separates custom engineering, provider licences, data migration, infrastructure and operating support, with acceptance scenarios agreed before rollout.

Does an agent dashboard authorize credit or payment handling?

No. Software implements only the allocation, limit and financial actions expressly permitted by the operator-approved model and agreements. Required authority, provider access, approval and reconciliation are confirmed separately. Player funds, credit or network allocation and commercial commission retain distinct records and responsible owners.

How is an existing agent network migrated or handed over?

Inventory identities, parent relationships, role grants, player assignments, effective deal versions, open statements and permitted allocation balances. Rehearse import validation and source-to-target reconciliation, including transferred players and late adjustments. Record unresolved differences, incoming support/finance owners, access changes and the point at which the new system becomes authoritative.

Separate records with different meanings.

Player funds.
Network allocations.
Commercial commission.

Reporting should preserve each record’s authority, permitted viewers and reconciliation path.

Give the network practical reporting

Agents need visibility into their permitted activity, while central operators need consolidated oversight and exception detection. Reports should preserve the difference between player funds, network allocations and commercial commissions. We scope filters, exports and support evidence around the actual hierarchy, with negative tests proving that access cannot cross an unauthorized boundary.

  • Role-specific dashboards and exports
  • Hierarchy-aware audit and exception reporting
  • Cross-agent access and financial test scenarios
A controlled route to release

Model the network before enabling financial actions

  1. Define the network and permission hierarchy

    Specify agent levels, account access, financial limits and approval responsibilities. Document commission bases, settlement periods and the records each network role may see.

  2. Implement controlled commissions and transfers

    Build the agreed network actions and calculations with versioned rules and auditable approvals. Keep partner visibility separate from operator authority over accounts and corrections.

  3. Reconcile network and operator records

    Exercise hierarchy changes, reversals and settlement exceptions. Compare agent statements with the operator ledger and deliver investigation paths for disputed commissions or balances.

Your release package

Hierarchy, commission and approval records

  • Network hierarchy and authority specification
  • Agent onboarding and access workflows
  • Commission and settlement calculation model
  • Role-specific dashboard implementation
  • Financial reconciliation and permission tests
  • Network administration and support documentation
Your ambition. Our next conversation.

Define your agent and distributor hierarchy

Bring the proposed account hierarchy, credit or settlement rules, commission model and approval responsibilities. We will map permissions, balance movements, reporting and exception handling for each level of the distribution workflow.

Let’s build
Your privacy. Your choice. Read the privacy policy