Contact

Engineering for trading businesses

Connect your data. Supervise your operations.

C.G Solutions designs custom software for proprietary trading firms, brokers and their operations teams: risk supervision, MT5–CRM integration, historical data import and automated reporting.

Discuss my projectExplore selected work

Which process do you want to make more reliable?

  1. Supervise risk rules

    Follow accounts, positions and breaches against configured policies.

  2. Connect MT5 to your CRM

    Import authorised data, bring over the history and track synchronisations.

  3. Consolidate daily reporting

    Turn trading history into usable reports and flag incomplete data.

  4. Give operators visibility

    Bring states, detections, exposure and logs together in interfaces suited to their work.

Areas of engineering

What we engineer.

Five categories of systems for trading operations, and the application formats they are built in.

Systems for trading operations

Risk Supervision & Control

Software that supervises trading accounts against configured risk policies: rule evaluation, limits, each account’s status against those rules, and the interfaces operators use to follow it.

The problem

The risk policy exists, but applying and tracking it across accounts takes too many manual checks.

Engineering approach

Each policy becomes an explicit, configurable rule with a defined state. We establish with you how each rule is evaluated — periodically, or in reaction to trading events — what happens on a violation, and how every evaluation is recorded.

Typical deliverables
  • Rule-based supervision of accounts and positions, configurable per group
  • Limits: floating drawdown, position limits and volume caps
  • Symbol normalisation
  • Tracking of each account’s state against its configured policies
  • Violation handling workflows
  • Connection states and an operator console
  • Logging and operational diagnostics
Suited to

Proprietary trading firms, brokers and trading operations teams.

Scope and limits

Supervision is periodic or event-driven: it acts on what the platform has already reported, after a delay that can be measured. These systems do not themselves block an order before execution; that is only possible where the trading platform provides such a control on the server side. They are operational controls — not a guarantee against loss, not regulatory compliance, and not compatible by default with every firm’s rules.

Discuss a risk supervision systemRelated engineering referenceRisk Supervision & Control Systems

MetaTrader 5 & Trading Infrastructure Integration

Engineering around MetaTrader 5 and the infrastructure that surrounds it: account and position data, trade history, and controlled exchange with other systems.

The problem

The data and controls you need live inside the trading platform, and reaching them reliably is not straightforward.

Engineering approach

We start from what the platform’s interfaces actually permit — on the terminal side through MQL5, or on the manager side where your server access allows it — and design the integration within those constraints, with read access before write access.

Typical deliverables
  • Accounts, positions, deals and financial snapshots read from the platform
  • Trade history processing
  • Controlled, read-only data extraction
  • Manager-side integrations, where access is granted
  • Interoperability between the platform and other systems
  • Terminal tools and panels in MQL5
Suited to

Brokers, proprietary trading firms, trading infrastructure operators and trading technology providers.

Scope and limits

Every integration depends on the access, licences and interface terms of the platform and of your server. C.G Solutions is an independent engineering firm: it is not affiliated with, endorsed by or a partner of MetaQuotes. MetaTrader and MQL5 are trademarks of their respective owner.

Discuss an integration

Financial Data & CRM Integration

Trading data read from MetaTrader 5 and carried into CRM and back-office applications: an initial import of accounts and their history, then incremental synchronisation, each run tracked until the receiving system has accepted it.

The problem

Teams reconcile inconsistent records, or re-enter the same information in several systems.

Engineering approach

Data is mapped first, to a documented contract, then read from the source without write access; writes happen on the receiving side only, as the contract defines them. An import or a synchronisation records what it has sent and what was accepted, so that a run can be repeated, or resumed after an interruption, without duplicating its effects.

Typical deliverables
  • Read-only extraction at the source: accounts, positions, deals and financial snapshots
  • A documented data contract and mapping
  • Initial batch import of authorised accounts and history, within an explicit scope
  • Incremental synchronisation after the initial import
  • Persistent state, outgoing queue and acceptance tracking
  • Checkpoints, reconciliation, duplicate protection and controlled resumption
Suited to

Brokers, proprietary trading firms and financial operations teams.

Scope and limits

Access rights, APIs and the receiving system’s contract are confirmed during analysis; the fields available and the depth of history depend on the sources. The connector transmits source data: business calculations made in the CRM remain distinct from it. These mechanisms are designed to limit and expose inconsistencies; they do not guarantee that every record is delivered, or that data stays consistent in every failure scenario.

Discuss a data integrationRelated engineering referenceMT5–CRM Integration and Bulk Data Import

Operations Automation & Reporting

Recurring operational work turned into scheduled, observable processing: daily reports built from trading history, notifications, and the tracking that shows what ran, what did not, and when data was incomplete.

The problem

Daily reporting and monitoring depend on manual steps, and nobody is sure that a run completed.

Engineering approach

Each job has a schedule, a recorded state and a defined behaviour on failure. A daily report is built from the trading history of a reference day and states when that history is incomplete, so that missing data is never read as a day without exceptions. Notifications are aggregated into a summary operators can act on, rather than a stream of alerts.

Typical deliverables
  • Daily reports rebuilt from trading history, including position lifecycles
  • A reference day aligned with the trading server
  • Evaluation against configured limits
  • Completeness checks: incomplete data reported as such
  • Aggregated notifications and daily summaries
  • Processing-state and delivery tracking, exception handling and retries
Suited to

Operations and risk teams of brokers and proprietary trading firms.

Scope and limits

Schedules, data sources and notification channels are agreed per project. A report reflects the data made available by the source systems at the time it is read. Whether a notification arrives depends on the channel used and is not guaranteed.

Discuss an automationRelated engineering referenceDaily Reporting and Operational Notifications

Trading Monitoring & Detection

Software that helps operators review trading activity: rule-based detection, exposure views, and alerts that state why they were raised.

The problem

Relevant events are buried in activity, and reviewing them account by account does not scale.

Engineering approach

Detection starts from explicit rules and heuristics, each producing an alert that states why it was raised. The interface is built for review: an operator sees the alert, its context and its severity, and decides. Where risk supervision applies a defined consequence to a rule, monitoring informs an operator’s judgement.

Typical deliverables
  • Rule-based detection
  • Monitoring of activity patterns against defined heuristics
  • Position and exposure visualisation
  • Detection dashboards
  • Operational review workflows
  • Alerts that state their reason
Suited to

Risk and operations teams that review trading activity.

Scope and limits

Detection works on activity the platform has already reported; it is not a pre-trade control. A detection is a prompt for human review, not a verdict. Where statistical or machine-learning methods are considered, they are treated as experiments until they have been evaluated on your data; we publish no accuracy figures and claim no certification.

Discuss a monitoring systemRelated engineering referenceTrading Monitoring & Detection Systems

Application formats

Custom Desktop & Web Applications

The formats these systems are built in: operator consoles on the desktop, web interfaces and background services — designed around how the work is actually done.

The problem

A capable system is hard to operate because its interface was an afterthought.

Engineering approach

The interface is designed with the system, not after it: which states an operator must see, which actions need confirmation, and what should be impossible to do by accident.

Typical deliverables
  • Desktop applications and operator consoles
  • Web interfaces and dashboards
  • Background services and scheduled jobs
  • Interfaces for configuration, review and control
Suited to

Trading businesses that need an application around a specific operational process.

Scope and limits

Our specialisation is professional trading technology, not general-purpose web or app development. Desktop and web applications draw on our own engineering work; mobile applications are assessed project by project and are not presented as an established track record.

Discuss an application

Why custom

No two trading operations are the same.

A system that fits one environment rarely fits the next. These are the things we establish before proposing anything.

Technical constraints
What the platforms and interfaces involved allow, and what they do not.
Risk policies
The rules the operation applies, and how each should be evaluated and recorded.
Trading infrastructure
Servers, terminals, account structures, and the access each component is granted.
Operational processes
Who acts on what, when, and with which information.
Integration requirements
The systems that must exchange data, and the direction in which it flows.
Reliability requirements
What must keep running, and what must happen when a component stops.
Data security
Which data may be read, stored or transmitted, and by whom.

We do not offer generic development packages, a universal solution or a guarantee of regulatory compliance. Each system is engineered for stated requirements.

Integration & reliability

Built to be operated, not only delivered.

Systems that supervise accounts or move financial data must behave predictably when something goes wrong. These are the practices we design in.

Read-only first
An integration observes and reconciles before it is ever allowed to write.
Persistent state & queues
Processing records what it has done and what is waiting to be sent, and resumes from there after an interruption.
Acknowledged delivery
A record counts as delivered once the receiving system has accepted it; a positive transport response alone is not taken as acceptance.
Idempotency & controlled retries
Repeating or resuming a job is designed not to duplicate its effects; failures are retried within defined limits, never silently dropped.
Visible state & diagnostics
Rules, connection and session status, and exceptions are shown to the operator and logged.
Secrets kept apart
Credentials and keys are configured separately from the code and from the delivery package.
Delivery & rollback
Each delivery comes as a package with its installation procedure and a documented way back.
Stated limits
Each system documents what it observes, what it can act on, and what remains with the platform or the broker.

These practices are intended to reduce operational risk. They do not guarantee that every message is delivered, or that data stays consistent in every failure scenario.

Development approach

Seven stages, in this order.

The sequence is the same whatever the size of the system; maintenance, the last stage, applies when contracted.

  1. Requirements discovery

    What the operation needs, who uses the system, and which decisions it has to support.

  2. Operational & technical analysis

    The platforms, data, access rights and constraints the system must work within.

  3. Architecture & solution design

    Components, interfaces, data contracts, failure behaviour and acceptance criteria, written down before implementation.

  4. Incremental implementation

    Built in stages you can review, rather than delivered in one piece.

  5. Functional & reliability validation

    Checked against those acceptance criteria, including how the system behaves when something fails.

  6. Controlled delivery

    Put into service with you, in agreed steps, with the means to observe it.

  7. Maintenance & improvement

    Provided when contracted, with a scope defined with you. Systems and rules evolve as operational requirements change.

This describes how we work. It is not a certified process.

AI Project Architect

Not sure where to start?

Outline your requirements in a few minutes and receive a preliminary technical concept to discuss with our engineers.

Explore your project

Selected work

Engineering references.

Each one is presented with its context, the approach taken and its limits.

View selected work

Describe your operational requirement.

Tell us about the process, the systems involved and the constraints. We will tell you plainly what can be engineered, and what cannot.

Discuss your project