Frequently Asked Questions

We help brokers plan, deploy and operate trading infrastructure. Our core work covers MT5 main-label application coordination and technical setup, maintenance of existing MT4/MT5 environments, server hosting and managed operations, liquidity and Bridge connectivity, and coordination of selected CRM, KYC/AML and payment integrations.

We work on a B2B basis with brokers, financial institutions and other eligible businesses. Entity, licensing, jurisdiction and vendor-acceptance requirements are reviewed before a project is confirmed.

No. We do not open retail trading accounts, solicit deposits, execute trades as a broker, manage investments or hold client money.

We support eligible firms seeking a full MT5 server licence, commonly described in the industry as a main-label licence. We help prepare the technical scope, coordinate the application process and implement the environment after approval. The licence agreement is issued by MetaQuotes, and all eligibility decisions, commercial terms and approval timelines remain at MetaQuotes’ discretion.

MetaQuotes applies its own onboarding and KYC requirements and may require an acceptable regulatory licence and supporting corporate information. Requirements can change and may vary by entity and jurisdiction, so eligibility must be checked for the specific applicant before any timeline or outcome is assumed.

No. We can review readiness, coordinate documents and manage the technical work, but MetaQuotes alone decides whether to contract with an applicant.

No. New MT4 server licences are no longer generally issued. We continue to support, host, maintain and migrate existing authorised MT4 environments where the client already has the necessary licence and access rights.

No. We are an independent technology and implementation provider. MetaQuotes licensing is contracted separately and remains subject to MetaQuotes’ own review and terms.

Depending on the agreed plan, services can include server provisioning and hardening, platform updates, configuration and change control, access management, monitoring, log review, backup checks, capacity planning, incident triage and coordination with third-party vendors.

We can coordinate installation, configuration, testing and change control where the client has valid licences, documentation and vendor access. The third-party developer remains responsible for its own software, fixes, warranties and contractual service levels.

Client-side Expert Advisors and server-side plugins are different components. We can help reproduce compatibility or performance issues and test relevant server changes within an agreed environment, but we do not certify arbitrary third-party code or guarantee the behaviour of an EA or plugin.

Incident severity, communication channels, response targets and escalation paths are defined in the applicable support plan or service agreement. Third-party outages are triaged and escalated to the responsible provider where required.

Architecture can be designed around major financial and cloud regions, subject to provider availability, data-residency requirements, LP endpoints and the client’s budget. The final region, server specification and network design are confirmed during scoping.

No universal latency figure applies. Measured latency depends on server location, the LP or Bridge endpoint, network route, platform load and other third-party systems. Where required, the project can define measurable latency targets and a testing method.

They can be designed into the deployment. Backup frequency, retention, standby topology, recovery procedures and RTO/RPO targets depend on the selected architecture and service plan; they should not be assumed unless stated in the proposal or agreement.

No. We can help assess, introduce and technically integrate independent liquidity providers, subject to each provider’s onboarding, approval and contract.

No. Some environments use an MT5 Gateway, while others use FIX connectivity through a third-party Bridge or aggregator. The correct design depends on the interfaces offered by the LP, execution model, routing requirements and operational controls.

A typical scope can include endpoint coordination, symbol and contract mapping, price-feed and order-flow validation, execution settings, markups, rejects, demo/live separation, logging, launch testing and rollback planning.

Aggregation is generally considered when multiple liquidity sources require consolidated pricing, routing rules, execution controls or resilience. A broker using one LP and a supported Gateway may not need a separate aggregation layer.

The relevant third-party provider remains responsible for its service under its own contract. EBS FinTech can assist with evidence collection, technical triage and vendor coordination within the agreed support scope, but does not assume the provider’s liquidity, execution, uptime or contractual obligations.

Often, yes. We can coordinate supported third-party systems and the relevant platform or back-office workflow. Feasibility depends on API availability, documentation, access permissions, security requirements and the selected vendors.

No. Identity verification, screening and payment processing are performed by the selected third-party providers and the client’s own compliance and operations teams. EBS FinTech’s role is limited to agreed technical integration and support.

Usually, subject to a technical review. We will need the vendor’s supported interface, documentation, test access, commercial permissions and escalation contacts before confirming scope.

Controls may include hardened operating systems, network segmentation, IP restrictions, multi-factor authentication, least-privilege access, encrypted transport, secrets management, monitoring, audit logging and DDoS protection. The exact control set depends on the architecture and contract.

Storage locations and backup regions are chosen during architecture design and recorded in the project scope. The client remains the controller or responsible business for its customer data and must confirm that the design meets applicable privacy, retention and regulatory requirements.

Access should be limited to authorised personnel and governed by named accounts, permissions, approval processes and logging. The specific access model is agreed with the client and may also depend on MetaQuotes and third-party vendor requirements.

Yes, where the client has the required licence, administrator access, data rights and cooperation from relevant vendors. A migration may cover architecture review, server deployment, configuration mapping, history or data handling, testing, cutover and rollback planning.

There is no single fixed timeline. MetaQuotes onboarding, regulatory readiness and third-party approvals sit outside the technical build. After prerequisites are available, timing depends on server architecture, instruments, groups, liquidity, integrations, testing and branding. A project schedule is issued after discovery.

UAT support, configuration checks, launch checklists, administrator handover and operating guidance can be included in the project scope.

Projects normally include a one-time implementation fee and, where ongoing hosting or technical operations are required, a recurring service fee. MetaQuotes, cloud, data-centre, LP, Bridge, CRM, KYC and payment-provider charges may be separate unless expressly included.

Key factors include platform and licence status, server topology, regions, expected workload, number of environments, liquidity paths, integrations, migration requirements, security controls and support coverage.

Monitoring and on-call coverage can be provided under qualifying managed-service plans. Coverage hours, severity definitions, response targets and communication channels must be stated in the applicable proposal or service agreement.

No. We can coordinate technical requirements and work with the client’s appointed advisers, but the client must obtain its own legal, tax and regulatory advice and maintain all approvals required for its business.

The broker or other regulated client is responsible for its policies, risk assessment, customer due diligence, sanctions screening, monitoring, recordkeeping and regulatory reporting. Technology integrations do not transfer those obligations to EBS FinTech.

No. Service availability is subject to EBS FinTech’s own due diligence, applicable sanctions and export restrictions, and the acceptance rules of MetaQuotes and other involved providers.

• Main label: Industry shorthand for a full MetaTrader server licence contracted directly with MetaQuotes.
• MT5 Gateway: A connectivity component designed to connect MT5 with a supported liquidity venue or exchange.
• Bridge: Third-party software connecting a trading platform with external pricing and execution venues.
• FIX API: An institutional messaging protocol used for orders, executions and market data.
• Aggregation: Consolidation and routing across more than one liquidity source.
• A-book: A model in which relevant client order flow or resulting exposure is routed to an external counterparty.
• B-book: A model in which relevant risk is internalised and managed by the broker.
• RTO: The target time for restoring a service after an incident.
• RPO: The target point to which data should be recoverable after an incident.
• UAT: User acceptance testing performed before production launch or a material change.