Going live with MetaTrader 5 is not the end of the project. It is where platform operations begin.

The environment keeps moving after launch. MetaQuotes ships new builds. Windows and infrastructure components need patching. Liquidity providers change symbols, sessions and connection parameters. Bridge vendors release updates. CRM, payment and KYC systems revise their APIs. Staff join and leave, and vendor access tends to outlive the project it was granted for.

Each change looks contained to one system. It rarely is. A production MT5 brokerage depends on Trade and Access Servers, price feeds and LP sessions, a Bridge or Gateway, CRM and onboarding, payment and KYC integrations, Manager or Web API applications, reporting, and the monitoring and backup layer underneath all of it. The more automation and third party integration a broker adds, the more failure points there are to cover — and maintenance has to cover the chain, not just the server process.

What an MT5 maintenance checklist should cover

A workable programme answers five questions on a schedule:

Availability — are trading, access, data and integration services reachable?
Integrity — do prices, orders, deals, balances and external records agree?
Configuration — are Symbols, Groups, permissions and routing still correct?
Security — is privileged access controlled and accounted for?
Recoverability — can service and data actually be restored?

MetaQuotes documents several interfaces for connecting MT5 to trading and post-trade systems — Manager API, Web API, Server API, Report API and Gateway API — along with automated monitoring and restart functions for feeds, gateways and servers. Anything connected through those interfaces sits inside the maintenance scope.

Daily checks

Daily work concentrates on what can affect pricing, execution or account records the same day.

Service reachability. Confirm the Trade Server and every Access Server are online and accepting connections. A running Windows process proves very little. The check should include a controlled test login from outside the data centre, using a dedicated monitoring account rather than a client’s credentials, alongside login success rates, unusual disconnection volumes, feed and gateway status, scheduled restarts, and whether automatic recovery worked. Where several Access Servers are deployed, verify that traffic is distributed as intended and that failover remains available.

Resources and logs. Track CPU, memory, disk usage and growth rate, network throughput, packet loss and service response time against your own baseline rather than a fixed percentage. Sensible thresholds depend on account volume, quote frequency, history retention, plugins and reporting load.

For the desktop terminal, MetaQuotes stores platform and Expert journals separately, filed by date. Broker side maintenance should extend to the Trade Server, Access Server, Gateway, API and infrastructure logs available within the authorised environment. Collecting logs is not the point — classifying them is. Repeated service errors, failed logins, API timeouts, feed interruptions, rejected orders, Symbol configuration warnings, plugin failures and unexpected administrative actions each deserve a category and an owner. A warning that repeats while trading continues normally may be an early sign of a capacity or integration problem and should not automatically be treated as noise.

LP pricing and Bridge sessions. The differences between FIX API and MT5 Gateway connections determine which of these checks matter most. Check FIX logon status, quote timestamps, stale or frozen prices, missing instruments, unexplained spread movement, bid and ask sanity, heartbeats, execution latency, reject codes and fallback LP status. The aim is to separate genuine market conditions from a broken feed, a mapping error or a delayed session.

Order flow, reconciliation and backups. Review rejection rate by reason, execution latency against baseline, partial fills, cancelled or expired orders, unmatched trades, and differences between MT5, Bridge and LP records. Check balance operations, deposits, withdrawals and manual adjustments for failed or duplicated postings. Then confirm backup jobs completed, files landed where expected, sizes look plausible, encrypted offsite copies transferred and retention is working. A backup job that quietly stopped will not announce itself until a restore is needed.

Weekly checks

Weekly reviews target configuration drift and access control.

Administrative access. Review Admin, Manager, dealer, risk, support and API accounts for rights no longer needed, dormant accounts, shared credentials, over privileged vendor accounts, unusual login times or locations, and temporary permissions that were never revoked. Use named accounts wherever the platform and connected systems support them — shared administrator logins make it impossible to establish who changed what.

Symbols and sessions. Ahead of market holidays, daylight saving changes and LP session notices, confirm trading and quoting sessions, closures and early closes, Symbol visibility, execution and filling settings, contract size, volume limits and step, stop and freeze levels, close only restrictions and source symbol mapping. Holiday schedules should be prepared in advance, not edited in production an hour before a market closes.

Groups and trading conditions. Check leverage, margin, stop out, commission, swap, mark up, Symbol permissions, execution restrictions, account currency, Group structure, naming conventions, configuration variants and CRM to Group mapping against approved commercial settings. Where several Groups share similar names, the risk of an incorrect CRM to Group mapping increases — and a perfectly correct account opening request can still deliver the wrong trading conditions.

CRM, payment and KYC. Test representative workflows end to end rather than checking API availability. Create a client, approve and reject KYC, open an account, confirm the Group and leverage applied, post a deposit, submit a withdrawal, assign an IB relationship, then read the audit log. A successful API response is not evidence that the intended account change actually happened.

Bridge and LP reports. Compare Bridge execution reports with MT5 deals and LP statements: unmatched tickets, volume and price differences outside tolerance, duplicate fills, missing commission entries, unexplained reject codes, repeated failover, and routing outside the intended rule set. What counts as the intended rule set depends on the broker’s A-Book, B-Book or hybrid execution design, and reconciliation should be read against that design rather than in isolation. This is what separates a technical execution problem from a trading loss or a client complaint.

Patch status. Review available Windows and security updates, but do not push them into production simply because they exist. Classify by severity, affected server role, restart requirement, compatibility concerns, test status and rollback method. An emergency vulnerability may justify an accelerated path; it does not justify an undocumented change.

Monthly and quarterly reviews

Monthly work moves from service health to resilience and governance.

Take a controlled configuration snapshot and compare it with the last approved baseline. New Groups, Symbol changes, permission changes, new plugins or APIs, revised routing rules, additional Access Servers and altered LP settings should all be accounted for. Anything unexplained is configuration drift — and drift becomes the accepted production state if nobody looks.

Recovery testing belongs on the same cycle. Restore configuration and application data in an isolated environment, start services from backup, confirm permissions, reconnect test integrations, validate Symbol and Group settings, and check the alternative Access Server path. Frequency should follow the broker’s own risk assessment, architecture and regulatory obligations rather than a target copied from another firm.

Capacity review compares current usage with previous months and expected growth: account numbers, concurrent sessions, tick volume, disk growth, report processing time, API traffic, Bridge throughput, backup duration and alert frequency. Plan before the server reaches a limit, not after performance degrades.

Vendor review covers hosting, data centre, LP, Bridge, CRM, payment, KYC and monitoring providers — actual incidents and support response against contracted scope, plus invoices, account limits and usage charges. Pair it with complaint analysis from support and dealing. Repeated reports of login failures, missing Symbols, wrong leverage, commission or swap disputes, delayed deposits or rejected orders may indicate a Group, regional node or integration fault that infrastructure monitoring has not detected.

Every production change should leave a record: reason, affected systems, requester, approver, implementer, test evidence, timing, verification results, rollback instructions and any incident that followed. Quarterly, widen this into a full access audit, a documented disaster-recovery exercise, and an architecture and supplier-risk review.

Updating the platform without breaking it

Treat platform updates as change management, not installation.

Start with the release notes and identify the components affected. Build numbers do not tell you what was touched. MetaQuotes published the Build 6060 release notes on 23 July 2026 and scheduled the update for 24 July 2026. The published changes cover the Terminal, MQL5 and MetaEditor, with further changes in the Strategy Tester and Web Terminal. The release notes do not identify Build 6060 as a Trade Server update.

Three items in this release deserve a broker side policy and compatibility review rather than treatment as a routine client update. Native Model Context Protocol (MCP) support brings a built in AI Assistant to the Terminal and MetaEditor and allows external MCP compatible agents to connect to the trading environment; AI operation permissions are controlled through terminal security settings, which can permit, prohibit or require manual confirmation for AI initiated trading, with separate controls for network requests and command line access. Brokers may still need an internal policy on where and by whom AI agents are used. Passkey availability is enabled on the broker side and functions as an additional factor alongside the existing login and password. And two new account access levels with separate passwords — Trader, which permits trading but not password changes or funding operations, and Money Manager, which permits deposits, withdrawals and transfers but not trading — should be incorporated into the broker’s access control and operational procedures.

Where external AI providers or MCP compatible agents are used, the broker should separately assess data access, credential handling, trading permissions and the provider’s applicable privacy terms.

The release also removes support for publishing trading reports via FTP, which MetaQuotes describes as a deprecated legacy feature. Any workflow still relying on it should be migrated to an alternative before the affected terminals are updated.

A release of this type warrants a review of authentication policy, account access design and the broker’s position on AI agent access, plus testing of representative client builds. It should not be described as a Trade Server upgrade unless authorised server documentation or MetaQuotes support confirms one.

Map the dependencies that could be affected: CRM, Manager and Web API services, Bridge or Gateway, LP connections, payment and KYC integrations, reporting tools, plugins, client EAs, and web and mobile onboarding flows. Scope this against the actual deployment.

Test in an environment close enough to production to expose real incompatibility. Cover startup, administrator and client login, price delivery, order placement and modification, execution and rejection handling, deposits and withdrawals, CRM account opening, Group assignment, Manager API functions, Bridge routing, reports, representative EAs and reconnection. Include the negative cases: rejected KYC, invalid Group requests, dropped LP sessions, API timeouts.

Back up the current state outside the system being changed, under the broker’s own encryption and access control policy. Then choose a maintenance window against trading sessions, client geography, LP availability and internal support coverage. Weekends are not automatically safe — some markets, reporting processes and regional operations keep running.

Notify dealing, risk, support, compliance, finance and technology on what is changing, when, which services may be affected, how to escalate, and what client communication has been approved. Implement using the approved procedure and record deviations as they happen.

Verify afterwards, properly. Repeat the important production checks: logins, quotes, execution, Group conditions, deposits and withdrawals, CRM synchronisation, Bridge and LP connectivity, reports, backups and monitoring alerts. A service that started successfully is not a completed change.

Keep a rollback plan that has been tested. It should state the trigger conditions, who decides, which files and versions are required, how post change data is handled, how integrations return to their previous state, and how the rollback itself is verified. An untested rollback document is a hope, not a plan.

Two settings worth a second pair of eyes

Group and Symbol changes can cause avoidable incidents because they take effect on a client’s trading conditions immediately. How MT5 Group configuration determines those conditions in the first place is covered separately; the checks below concern what to verify before changing them in production.

Before touching production Symbols, verify contract size, tick size and tick value, calculation mode, profit and margin currencies, execution type, filling modes, trading and quoting sessions, volume limits, stops and freeze levels, swap method and rollover days, commission, margin rates, visibility and close only status.

For Groups, verify available Symbols, leverage, margin and stop out rules, commission, swap, markup, account currency, execution restrictions, reporting settings, CRM mapping and IB programme mapping.

High impact changes should run on a maker checker basis: one person prepares, another reviews before implementation.

Backups are not a recovery plan

A virtual machine snapshot is not necessarily a recovery strategy. External databases, integration servers, API services, Bridge components and credential stores frequently live elsewhere.

The protected scope should include MT5 configuration, Group and Symbol settings, account and trading records, administrative permissions, authorised plugins, Bridge and routing configuration, LP connection settings, CRM data, payment and reconciliation records, reporting data, integration code, encrypted credential vaults, certificates and recovery keys, and the operating procedures and vendor contacts needed to use them.

Having the files does not prove the environment can be recovered. Restore critical components periodically in an isolated environment and document what was restored, how long each step took, which dependencies failed, whether permissions survived, whether records reconciled, and which documentation needs updating. Credentials should never sit in unencrypted operational documents — they belong in an approved secret management system, with ownership and recovery recorded separately.

Ten mistakes that keep repeating

Updating production without testing.
Running without a representative test environment.
Treating every build as the same type of update.
Backing up a server image while leaving application configuration and external data unprotected.
Letting multiple vendors share one Administrator account.
Changing Groups or Symbols without independent review.
Monitoring connectivity but not rejects or quote freshness.
Never reconciling MT5, Bridge, CRM and LP records.
Leaving accounts active for former employees and expired vendors.
Maintaining a rollback document nobody has ever tested.

Suggested MT5 maintenance calendar

Frequency	Recommended checks
Daily	Service availability, Access Server connections, resources, logs, LP pricing, Bridge sessions, rejects, latency, reconciliation exceptions, backup jobs
Weekly	User permissions, dormant accounts, Symbol sessions, holidays, Group settings, commission, swap, CRM workflows, payment reconciliation, LP execution reports, patch status
Monthly	Configuration comparison, recovery testing, capacity review, vendor performance, complaint analysis, change log review, version planning
Quarterly	Full access audit, disaster recovery exercise, architecture review, supplier risk review, documentation update
Before an update	Release note review, dependency mapping, test validation, backups, maintenance window, communications, rollback preparation
After an update	Logins, prices, trading, APIs, Bridge, CRM, payments, Groups, reports, monitoring, backup verification
After an incident	Timeline reconstruction, root-cause analysis, reconciliation, access review, corrective actions, runbook update

Adapt the cycle to your trading model, products, jurisdictions, infrastructure and service commitments. A documented checklist, supported by a real test environment, controlled updates, recorded changes and verified recovery, is what turns platform maintenance from reactive troubleshooting into an operational process you can plan around.

How EBS FinTech supports MT5 maintenance

EBS FinTech provides ongoing MT4 and MT5 technical support for brokers that need structured platform operations after deployment. The scope can include server monitoring, update planning and implementation support, backup and recovery procedures, Access Server maintenance, Group and Symbol configuration, LP connectivity together with troubleshooting and coordination of MT5 to Gateway or Bridge integration, CRM and API integration support, hosting and operating system coordination, incident response, change management and technical reporting, subject to the agreed service scope.

Third party Bridge software is procured and held by the broker, and its ongoing maintenance and support remain the responsibility of the relevant vendor unless separately agreed in writing.

The support boundary should be defined at the start of the engagement. Responsibilities are usually split between the broker, MetaQuotes, the hosting provider, the liquidity provider, the Bridge vendor and the CRM supplier. A written responsibility matrix removes the delay that follows an incident when nobody is sure whose check it was.

For brokers reviewing existing MT5 infrastructure or preparing a longer-term operating model, EBS FinTech can assess the current maintenance scope, identify responsibility gaps and establish a clearer support and change management process.

EBS FinTech provides technology and infrastructure services to broker operators. EBS FinTech does not provide brokerage services, does not hold or manage client trading funds, and does not solicit individual investors.