Technology
Layer by layer, with the dependencies written down
ClonePips is modelled as audiences on top, platform services and engines in the middle, and execution adapters at the base. Dependencies point downward only, which is what makes the risk and execution behaviour testable in isolation.
- Nine layers across three tiers
- Four execution venues behind adapters
- One API gateway in front of every surface
Architecture
The stack, top to bottom
Each layer declares what it depends on and whether it holds capital or execution authority. Criticality is the marker that matters operationally.
Audiences
Audience applications
standardInvestor, provider and broker surfaces served by the application.
Platform services and engines
API gateway
regulatedPublic and tenant-scoped entry point for every integration surface.
Copy engine
execution criticalCaptures provider signals and produces per-follower copy instructions.
Risk engine
regulatedEvaluates rules before, during and after execution across every account.
Allocation engine
regulatedOwns capital allocation state: portfolios, allocations, scaling, rebalancing.
Fee engine
regulatedCalculates performance, subscription and trade fees and posts ledger entries.
Analytics
standardComputes immutable performance snapshots and the metric vocabulary.
Execution layer
Execution adapters
execution criticalVenue-specific connectivity translating platform types into broker payloads.
Data plane
regulatedPersistence, event log and stream that every other layer reads from.
Execution adapters
MetaTrader 4 bridge
In developmentorder routing
MetaTrader 5 bridge
In developmentorder routing
FIX / dealing integration
In developmentliquidity provision
External liquidity provider
In developmentliquidity provision
ClonePips internal venue
In developmentsignal only
Engines
The copy and risk engines
Copying and risk are separate decisions, evaluated in separate engines. A signal that fails a risk rule never becomes an order, and the evaluation is recorded either way.
- The copy engine captures a provider signal and produces a per-follower instruction
- The risk engine evaluates rules before, during and after execution
- The allocation engine owns portfolios, allocations, scaling and rebalancing
- The fee engine calculates what each side owes, from the venue fee plan
Why engines are separate
- Risk logic can be tested without a copy signal
- Copy behaviour can change without touching risk rules
- Each engine owns one decision, so its log is readable
Execution
Execution adapters
Venue-specific behaviour lives behind an adapter. Each declares the capabilities it will support and whether capital can move through it; none is connected in this build.
MetaTrader 4 bridge
In developmentAccount snapshot, symbol catalog, order placement and modification, position close, trade and balance streams, statement export.
MetaTrader 5 bridge
In developmentThe MT5 capability set with order routing scope, delivered as its own adapter module.
FIX / dealing integration
In developmentLiquidity provision scope: snapshots, catalog, order lifecycle, trade stream and statement export.
Internal venue and liquidity providers
In developmentA signal-only internal venue and an external liquidity provider adapter, so routing can be tested before any external connection exists.
Data
The data plane owns account state
Account state is held independently of any single venue, so a broker can change execution routing without migrating the records a console reads.
- Venue adapters translate; they do not own the record
- Snapshots are immutable, so a report can be reproduced later
- Scope is per tenant, per account and per strategy
Reproducibility
- A snapshot is a point-in-time record, not a recalculation
- Drawdown is derived from the snapshot it was published with
- Reports carry currency and period with the figures
API
API and integrations
Every surface goes through the API gateway, which is what makes a broker front-end possible without venue-specific knowledge. The gateway and its webhooks are in development; nothing is served in this build.
REST API
In developmentTenant-scoped endpoints for accounts, strategies, allocations, risk configuration and reporting.
Webhooks
In developmentEvent delivery for order, allocation and risk events, with replay from the immutable log.
White-label surfaces
In developmentClient-facing broker surfaces on your domain and theme, driven by the same API.
Reporting exports
In developmentStatement and report exports generated from the same snapshots the interface reads.
Engineering
How this repository is organised
Is this architecture implemented?
The layering, registries and contracts are implemented as configuration and types. The services behind them are in development, and every page in this build labels them that way.
What enforces the dependency direction?
The type and module boundaries: components depend on lib and data, and lib never imports from app or components. Services will be added behind the same contracts.
How is behaviour evidenced?
The evaluation log. Risk decisions, configuration changes and order events are recorded as they happen, because an operational review reconstructs decisions from records rather than from memory.
Notices
Risk warning
Trading foreign exchange, CFDs and leveraged instruments on margin carries a high level of risk and may not be suitable for all investors.
No advice
Information on this site is provided for general information only and does not constitute investment advice or a recommendation.
Technical
Bring your integration questions
A technical demo covers the gateway surface, the adapter boundary and the records an integration would read and write.