MT5 화이트라벨과 메인 라벨의 차이: 신청 요건과 구축 절차

MT5로 브로커 사업을 준비하다 보면 메인 라벨, 화이트라벨, 그레이 라벨이라는 표현을 접하게 됩니다. 모두 MT5를 제공하는 방식이지만, 계약 상대방과 서버 관리 권한, 고객 데이터를 다루는 범위는 서로 다릅니다.

자체 로고가 표시되는지만 확인해서는 이 차이를 알 수 없습니다. 거래 조건을 변경할 때 누구의 승인이 필요한지, 장애가 발생하면 누가 복구하는지, 공급업체를 바꿀 때 무엇을 이전할 수 있는지까지 살펴봐야 합니다.

이 글은 세 가지 구조의 차이와 선택 기준, 신청 준비부터 구축과 운영 인수까지 확인할 사항을 설명합니다. 첫해 예산의 세부 산정은 별도 주제로 다루고, 여기서는 계약 구조와 운영 권한, 도입 절차에 집중합니다.

플랫폼을 누가 소유하는가

MT5는 MetaQuotes가 개발하고 지식재산권을 보유한 소프트웨어입니다. 브로커는 계약에 따른 사용 권한을 확보합니다. 자체 서버를 운영하더라도 소프트웨어 자체를 소유하는 것은 아닙니다.

메인 라벨, 화이트라벨, 그레이 라벨은 이 글에서 사용하는 업계의 운영 구조 구분입니다. MetaQuotes의 공식 상품 등급을 세 가지로 나눈 목록은 아닙니다. 특히 MetaQuotes가 사용하는 ‘White Label licensing’이라는 표현과 업계에서 다른 회사의 서버를 이용하는 구조를 뜻하는 ‘화이트라벨’을 구분해야 합니다.

제안서를 검토할 때는 다음 세 가지를 따로 확인하십시오.

• 소프트웨어 계약: 사용 계약의 명의자는 누구인가.
• 서버 통제권: 설정 변경, 관리 계정, 백업을 누가 통제하는가.
• 고객 계약: 고객에게 금융 서비스를 제공하는 법인은 누구인가.

소프트웨어 사용권과 금융 서비스 인허가도 별개입니다. MT5 계약이 있다는 사실만으로 특정 지역에서 브로커 영업을 할 자격이 확인되는 것은 아닙니다.

메인 라벨: 서버와 관리 권한을 직접 보유하는 구조

업계에서 메인 라벨 또는 풀 라이선스라고 부르는 방식은 운영사가 MetaQuotes와 직접 소프트웨어 이용 계약을 맺고 자체 서버 환경을 운영하는 구조를 뜻합니다. 여기서 라이선스는 소프트웨어 사용권입니다.

운영사는 계약에서 허용하는 범위 안에서 거래 상품, 고객 그룹, 거래 조건과 관리 권한을 통제합니다. 서버 인프라는 임차할 수 있고, 일상적인 유지보수는 외부 기술 업체에 맡길 수도 있습니다. 유지보수를 위탁하더라도 계약 명의와 최종 관리 권한을 누가 보유하는지는 명확해야 합니다.

이 구조는 자체 운영 기준에 따라 플랫폼을 관리하고, 연동 업체와 유지보수 업체를 선택할 필요가 있는 브로커가 검토할 수 있습니다. 그만큼 업데이트, 접근 보안, 백업, 장애 대응을 담당할 체계도 필요합니다.

계약 전에는 Administrator 계정 관리 방식, 호스팅 계약 명의, 백업 접근 권한, 유지보수 업체 교체 시 인수인계 조건을 확인해야 합니다. 외부 업체에 서버 운영을 맡기더라도 운영사가 필요한 계정과 문서를 확보할 수 있어야 합니다.

직접 소프트웨어 계약을 맺었다는 이유만으로 다른 회사에 플랫폼을 재제공할 권한까지 생기는 것은 아닙니다. 제3자 브랜드 운영이 포함된다면 허용 범위와 필요한 승인을 별도로 확인해야 합니다.

직접 계약하는 구조로 사업을 준비하고 있다면 MT5 메인 라벨 구축에 필요한 신청 준비, 서버 배포와 시스템 연동 범위를 함께 검토하십시오.

화이트라벨: 내 브랜드, 다른 회사의 서버

이 글에서 화이트라벨은 기존 서버 운영사의 MT5 환경을 이용하면서 자체 브랜드로 서비스를 구성하는 방식을 뜻합니다. 상위 서버 운영사가 서버를 관리하고, 브로커는 계약에서 정한 범위 안에서 고객 관리와 운영 업무를 수행합니다.

브랜드 표시, 고객 그룹 분리, 보고서 접근, 거래 조건 변경 범위는 계약마다 다릅니다. 자체 명칭이나 로고가 표시된다는 사실이 독립된 서버 통제권을 뜻하지는 않습니다.

승인 정책에 대해서는 다음과 같이 구분해 이해해야 합니다.

2022년 말 업계 보도에 따르면 MetaQuotes는 신규 고객을 위한 MT4 및 MT5 화이트라벨 승인을 중단한 것으로 알려졌습니다. 따라서 어떤 구조든 확정하기 전에 계약 상대방, 서버 통제권, 최신 승인 요건을 확인해야 합니다.

현재 공식 표현은 MetaQuotes의 브로커용 MT5 안내에서 확인할 수 있습니다. 이 설명만으로 특정 공급업체의 재제공 구조나 개별 신청의 승인 가능성이 확인되는 것은 아닙니다.

권한을 검토할 때는 ‘관리자 계정 제공’이라는 설명을 더 구체적으로 확인하십시오. Administrator는 서버 구성과 관리에, Manager는 부여된 범위 안에서 고객 계정과 거래 관련 업무를 처리하는 데 사용됩니다. Manager 접근 권한이 있다고 해서 서버 전체 설정이나 백업에 접근할 수 있는 것은 아닙니다.

예를 들어 고객 그룹의 거래 조건을 바꾸거나 특정 보고서를 추출해야 할 때, 운영사가 직접 처리할 수 있는지 공급업체에 요청해야 하는지 확인해야 합니다. 요청이 필요한 업무는 처리 시간과 긴급 연락 절차까지 정해 두는 것이 좋습니다.

MT5 화이트라벨이라는 이름으로 구축 상담을 받더라도, 제안된 계약 구조와 실제 제공되는 관리 권한을 기준으로 내용을 검토하십시오.

그레이 라벨: 가장 가벼운 진입 방식과 그 대가

그레이 라벨은 공급업체마다 의미가 다른 상업적 표현입니다. 일반적으로 화이트라벨보다 브랜드 분리와 관리 권한이 제한되고, 고객이 상위 브로커의 플랫폼을 더 직접적으로 이용하는 형태를 가리킵니다.

자체 구축 작업이 적을 수 있지만, 그만큼 거래 조건과 고객 관리 방식에서 상위 업체에 의존하게 됩니다. 초기 도입이 간단하다는 이유로 사업 위험까지 낮다고 판단해서는 안 됩니다.

그레이 라벨 제안을 받았다면 다음 사항을 먼저 확인하십시오.

• 고객 약관에 기재되는 계약 법인
• 고객 확인과 계정 승인 책임
• 고객 자금의 입출금 상대방
• 고객 정보와 거래 내역에 대한 접근 범위
• 자체 브랜드와 상위 브로커 명칭이 각각 표시되는 위치

소개 브로커(IB) 관계와 무엇이 다른지도 구체적으로 설명받아야 합니다. 별도의 브랜드 화면이 제공된다는 것만으로 독립된 브로커 운영 구조가 성립하는 것은 아닙니다.

향후 자체 서버로 옮길 계획이 있다면 고객 관계를 이전할 수 있는지, 어떤 데이터를 제공받을 수 있는지를 계약 전에 확인해야 합니다. 브랜드를 바꾸는 작업과 운영 환경을 이전하는 작업은 다릅니다.

제안받은 구조를 판별하는 방법

아래 표는 일반적인 구조를 비교하기 위한 기준입니다. 실제 권한은 상품 이름이 아니라 계약과 계정 설정으로 확인해야 합니다.

확인 항목	메인 라벨	화이트라벨	그레이 라벨
소프트웨어 계약 관계	운영사가 MetaQuotes와 직접 계약	기존 서버 운영사 등과 계약하며 상위 사용 권한 확인 필요	상위 브로커 또는 공급업체와의 실제 계약 관계 확인 필요
서버 통제권	운영사가 확보하고 유지보수를 위탁할 수 있음	대체로 상위 서버 운영사가 통제	대체로 상위 업체가 통제
Administrator와 Manager	자체 관리 체계에 따라 역할별 권한 설정	제공 도구와 허용 업무를 개별 확인	접근이 제한되거나 별도 포털만 제공될 수 있음
고객 데이터	보관 위치와 외주 업체의 접근 범위 확인	고객 계약 주체와 데이터 접근·반출 권한 확인	상위 업체와의 고객 관계 및 제공 가능한 데이터 확인
상위 업체 서비스 중단	유지보수 업체 교체에 필요한 계정과 문서 확보 여부 확인	서버 접근과 서비스 지속이 상위 업체에 의존	고객 서비스와 데이터 접근이 함께 영향을 받을 수 있음
계약 종료 후 이전	계약 상태, 백업 및 시스템 호환성을 바탕으로 이전 계획 수립	데이터 제공, 이전 협조, 비용과 일정 확인	고객 관계 이전 가능 여부와 데이터 제공 조건부터 확인

고객 데이터는 단순히 ‘누구의 소유인가’만 물어서는 부족합니다. 고객 계약 주체, 개인정보 처리 책임, 열람 권한, 반출 형식과 보존 의무를 구분해야 합니다.

보고서를 내려받을 수 있다는 것과 운영 환경 전체를 이전할 수 있다는 것도 다릅니다. 계정, 거래 이력, 미결제 포지션, 심볼과 그룹 설정을 어떻게 처리할지 별도 계획이 필요합니다.

어떤 구조를 선택해야 하는가

먼저 운영에 필요한 권한을 정한 뒤, 그 권한을 확보할 수 있는 구조를 검토하는 순서가 좋습니다.

• 플랫폼 설정과 운영 업체 선택을 직접 통제해야 한다면: 메인 라벨을 검토하되, 자체 운영 또는 외부 유지보수 체계를 함께 준비합니다.
• 자체 브랜드가 필요하고 서버 운영은 공급업체에 맡기려면: 화이트라벨 구조에서 허용되는 권한과 현재 승인 요건, 공급업체 의존 범위를 확인합니다.
• 상위 브로커와 밀접한 관계로 제한된 범위를 운영하려면: 그레이 라벨이라는 이름보다 고객 계약과 실제 제공 기능, 향후 이전 조건을 살펴봅니다.

어느 구조든 월 이용료만으로 비교하기는 어렵습니다. 서버, 연동, 지원 범위가 다르면 같은 금액의 제안도 제공하는 내용이 달라집니다. 실제 비용은 서버 구성, 유동성 연결, 통합 범위 및 운영 지원 수준에 따라 달라집니다.

신청과 구축은 어떤 순서로 진행하는가

신청 자료 준비, 외부 기관 심사, 서버 구축은 서로 연결되어 있지만 같은 절차는 아닙니다. 먼저 확정해야 할 사항과 병행할 수 있는 작업을 나누면 불필요한 재작업을 줄일 수 있습니다.

1. 신청 법인을 정하고 사용할 이름을 먼저 확인한다

고객과 계약할 법인, 회사의 법정 명칭, 서비스에 사용할 브랜드명과 도메인을 먼저 정리합니다. 이 이름들이 서로 다르다면 어떤 관계인지 설명할 수 있어야 합니다.

회사 등록이나 브랜드 제작을 진행할 때는 MetaQuotes 신청에 사용할 명칭도 가능한 한 이른 단계에 확인하는 것이 좋습니다. 회사 등록이 완료되었다는 사실만으로 해당 명칭이 소프트웨어 신청 과정에서도 받아들여지는 것은 아닙니다.

심사 과정에서 명칭 변경을 요구받으면 단순히 웹사이트 로고만 바꾸는 것으로 끝나지 않을 수 있습니다. 법인명까지 변경해야 한다면 등록 서류 갱신, 필요한 인증, 웹사이트와 신청 자료 수정, 재제출에 추가 비용과 시간이 발생할 수 있습니다.

명칭에 관한 사전 문의가 최종 승인을 보장하지는 않습니다. 다만 관련 요구사항을 확인하지 않은 채 여러 문서와 계약에 이름을 확정해 두면, 변경 시 손봐야 할 범위가 커집니다.

2. 신청 자료를 준비하고 웹사이트 정보와 대조한다

신청 준비 단계에서 일반적으로 요청되는 자료의 범주는 다음과 같습니다. 이는 준비 방향을 잡기 위한 분류이며, MetaQuotes가 모든 신청에 동일하게 적용하는 고정 제출 목록은 아닙니다.

자료 범주	준비할 내용
법인 등록 자료	법인 설립·등록 증빙, 등록 주소 및 현재 법인 정보를 확인할 수 있는 서류
이사·주주 확인 자료	해당되는 개인의 신분증명과 주소 증빙. 법인 주주가 있다면 그 법인의 등록 자료와 소유 관계를 설명하는 자료
실제 소유자 및 지배 구조	법인을 최종적으로 소유하거나 지배하는 실제 소유자(UBO)를 확인할 수 있는 지분·지배 구조도 및 관련 증빙
인허가 관련 자료	해당되는 금융 서비스 인허가 문서와 허용 업무 범위를 확인할 수 있는 자료
웹사이트와 사업 정보	실제 운영 주체, 제공 예정 서비스, 약관과 연락처를 확인할 수 있는 웹사이트 및 사업 설명

인허가 문서가 ‘해당되는 경우’라는 표현은 인허가가 없는 법인도 승인된다는 뜻이 아닙니다. 신청 구조에 필요한 자격과 증빙은 별도로 확인해야 하며, 회사 등록 서류를 금융 서비스 인허가 문서로 대신 설명해서는 안 됩니다.

자료를 모은 뒤에는 서류 사이의 일치 여부를 확인해야 합니다. 개별 파일이 정확하더라도 다른 자료나 웹사이트와 내용이 맞지 않으면 추가 설명과 수정이 필요할 수 있습니다.

제출 전에는 다음 항목을 대조하십시오.

• 신청 법인의 명칭과 등록번호가 관련 서류에 일관되게 기재되어 있는가.
• 이사, 주주 및 실제 소유자 정보가 지분·지배 구조 설명과 일치하는가.
• 웹사이트의 회사 소개, 약관 및 연락처에 표시된 법인이 신청 구조와 맞는가.
• 브랜드명과 법인명이 다르다면 그 관계가 명확하게 설명되어 있는가.
• 이전 회사명이나 다른 프로젝트의 문구가 웹사이트와 첨부 자료에 남아 있지 않은가.

주주와 실제 소유자 정보를 모두 웹사이트에 공개하라는 의미는 아닙니다. 심사에 제출하는 정보끼리 일치하고, 웹사이트가 실제 운영 주체를 오해하게 만들지 않아야 한다는 뜻입니다.

정확한 제출 목록과 인증 요건은 심사 주체의 최신 요청에 따릅니다. 회사명이나 지분 구조가 바뀌었다면 영향을 받는 자료를 함께 갱신해야 합니다.

3. 외부 신청은 병행하되 각 절차의 조건을 따로 관리한다

소프트웨어 신청, 은행·결제 서비스 제공업체(PSP)의 심사, 유동성 공급자(LP)의 계좌 개설은 필요한 자료가 준비되는 범위에서 병행할 수 있습니다. 그러나 한 곳의 승인이 다른 곳의 승인을 보장하지는 않습니다.

각 절차에는 자체적인 선행 조건이 있을 수 있습니다. 추가 법인 자료, 사업 설명, 인허가 관련 증빙 또는 다른 계약의 진행 상태를 요청받을 수 있으므로 모든 신청이 같은 속도로 끝난다고 가정해서는 안 됩니다.

진행 상황은 다음과 같이 구분해 관리하는 편이 좋습니다.

진행 항목	별도로 확인할 사항
소프트웨어 신청	신청 주체, 요청 자료, 사용 조건과 승인 상태
은행·PSP	계약 법인, 예정 자금 흐름, 지원 범위와 심사 상태
LP	계약 주체, 거래 조건, 증거금 요건, 초기 입금·최소 잔액 조건 및 연결 정보 제공 시점

LP가 요구하는 자금은 용도부터 구분해야 합니다. 포지션을 유지하기 위한 증거금과 계좌에 미리 넣어 두는 예치금은 같은 의미로 사용해서는 안 됩니다. 계약에 따라 예치한 자금이 증거금으로 사용될 수 있으므로 사용 방식, 추가 납입 조건과 출금 제한을 확인해야 합니다.

특정 업체의 거절이 곧 프로젝트 전체의 종료를 뜻하지는 않습니다. 다만 계획한 운영에 필수적인 기능을 확보하지 못했다면 대체 방안을 마련하거나 개시 일정을 조정해야 합니다.

4. 선행 조건이 갖춰지면 서버 배포와 연동을 진행한다

서버 역할 설계, 용량 산정, 접근 권한 계획, CRM 업무 흐름 정리는 신청 단계에서도 진행할 수 있습니다. 반면 실제 소프트웨어 배포와 사용은 해당 승인 및 계약 조건에 맞춰 진행해야 합니다.

LP 연결 테스트에는 접속 정보와 거래 조건이 필요합니다. CRM 연동에는 계정 생성 규칙, 고객 그룹 배정과 승인 상태 처리 방식이 정해져 있어야 합니다.

기술 구축에서는 다음 항목을 연결해 확인합니다.

• 서버 구성과 관리 접근 경로
• Administrator 및 Manager의 역할별 권한
• 심볼 매핑, 거래 세션, 수수료와 증거금 설정
• LP·브리지의 주문 및 가격 연결
• CRM의 계정 생성과 상태 변경 처리
• 모니터링, 백업 및 장애 알림

예를 들어 MT5와 LP의 심볼 이름만 연결했다고 해서 설정이 끝나는 것은 아닙니다. 계약 크기, 가격 자릿수, 거래 시간 등 관련 사양도 대조해야 합니다. CRM에서 계정 생성 요청이 성공하더라도 올바른 고객 그룹과 거래 권한이 적용되었는지 확인해야 합니다.

5. 서버 설치와 영업 개시를 구분한다

서버 설치 완료는 기술 작업의 한 단계이며, 영업 준비 완료를 의미하지 않습니다.

운영 전에는 주문 처리와 보고서, 계정 권한, 장애 알림을 테스트하고, 구성 범위에 맞는 백업·복구 절차를 검증해야 합니다. 관리 계정 목록, 구성 문서, 유지보수 시간과 장애 연락망도 인수해야 합니다.

동시에 운영사는 필요한 소프트웨어 사용 조건과 인허가, 자금 처리 수단, LP 연결 등 예정된 서비스에 필수적인 조건이 갖춰졌는지 확인해야 합니다. 기술 검수가 끝났더라도 이러한 조건이 미완료라면 개시 여부를 별도로 판단해야 합니다.

최종 인수 시에는 미해결 항목, 담당자와 완료 조건을 문서로 남기는 것이 좋습니다. ‘서버가 켜져 있다’는 상태와 ‘운영팀이 책임을 맡아 서비스를 시작할 수 있다’는 상태를 구분하는 과정입니다.

목표 시장은 라이선스와 KYC 구조에 어떤 영향을 미치는가

목표 고객의 소재지와 제공 상품은 인허가 검토 및 고객 확인(KYC) 절차를 설계할 때 고려해야 합니다. 운영사는 독립적인 법률·규제 자문을 통해 사업 범위를 확인하고, 그 결과를 실제 운영 절차에 반영해야 합니다.

기술적으로는 신청 고객을 어느 계약 법인에 배정할지, 거주 국가를 언제 확인할지, 추가 검토가 필요한 신청을 누구에게 전달할지 정해야 합니다. 고객 확인이 끝나기 전 거래 계정에 적용할 제한과 승인 후 활성화 조건도 정의해야 합니다.

사이트 언어를 선택하거나 특정 국가의 접속을 차단하는 설정만으로 영업 가능 여부를 판단할 수는 없습니다. 기술 공급업체는 확인된 운영 요건을 시스템에 구현하고, 법률·규제 판단은 해당 자문을 통해 확인하는 방식으로 역할을 구분해야 합니다.

EBS FinTech가 담당하는 범위

EBS FinTech는 브로커의 MT5 플랫폼 구축, 서버 인프라 및 기술 통합을 지원합니다. 프로젝트에서는 계약 구조를 먼저 확인하고 운영사가 보유할 권한과 기술 업체가 수행할 작업을 구분합니다.

EBS FinTech는 서버 구성과 배포, 관리 권한 체계 설정, LP·브리지·CRM 연동, 모니터링과 백업 구성, 운영 전 테스트와 인수인계를 수행합니다. 프로젝트별 구체적 범위와 지원 수준은 제안서에 명시됩니다.

소프트웨어 승인과 금융 서비스 인허가, 외부 금융기관의 심사는 각 기관의 결정에 따릅니다.

MT5 도입을 검토하고 있다면 계약 법인, 목표 지역, 제공 상품, 필요한 관리 권한과 기존 시스템 정보를 준비해 주십시오. MT5 화이트라벨 및 메인 라벨 구축 서비스를 통해 필요한 구성과 지원 범위를 논의할 수 있습니다.

이 글은 일반적인 구조 비교를 위한 자료이며 법률·규제 자문이 아닙니다. MetaTrader 5 및 MT5는 MetaQuotes의 상표입니다. EBS FinTech는 독립적인 기술 서비스 제공업체이며 MetaQuotes를 대신해 승인 결정을 내리지 않습니다.