Want someone to review your trading history without being able to place orders? MetaTrader provides a separate investor password for read-only access. That does not make the account anonymous or secure every connection you have with your broker. Before sharing a live view, establish what it reveals, how access can be revoked, and whether the other person needs the account at all rather than a limited report with identifying details removed.

What does read-only account access actually mean?

The MetaTrader 5 documentation distinguishes master and investor passwords. Investor authorization permits observation and analysis, but not trading. MetaTrader 4 help describes a similar distinction. This is an authorization mode for a session connected to the broker’s server, rather than a separate investment product. Other systems need their own permission checks; a familiar label is not evidence that they work identically.

A read-only session does not pause the owner’s trading or prevent losses. An owner or previously enabled automation may continue trading while an observer watches. Balance and equity can therefore differ and change. Use the account balance, equity and margin explanation to interpret those figures, rather than treating visibility as permission to act. Seeing a trading record also provides no assurance that the displayed strategy will produce comparable future results.

You may want help reviewing a history while keeping the size of your savings private. Ask which columns and dates are genuinely necessary for the task. A static report with account identifiers removed may be enough. Avoid publishing an investor password in a comment, public group or open webpage as evidence of credibility. Decide who should receive it before creating access.

Three access routes with separate checks

Three access routes with separate checksTerminal, client portal and API rights and revocation must be checked separately.Trading terminalSession rights on the serverObservation ≠ order rightsClient portalSeparate login and functionsConfirm the provider’s scopeAPIs and servicesSeparate keys and permissionsCheck revocation procedure
Terminal, client portal and API rights and revocation must be checked separately.

How do terminal, portal and API permissions differ?

Make a private list of access routes: trading terminal, client portal, mobile application and connected services. Record each route’s purpose and revocation procedure without recording passwords. Depending on the provider, a portal may handle documents, contact details or money instructions. An investor password in the terminal does not establish the permissions granted by a portal or another application.

An API is an interface through which software communicates with a provider. Check its own official permission description for data access, order actions, money functions and key revocation. Calling a service “analytics” does not define its actual rights. If an integration demands the master password or broad permissions for a viewing task, pause and ask the broker about an appropriate restricted alternative.

Disabling automated trading, hiding the order panel or closing a window does not turn a master credential into an investor credential. Restrictions should follow from authorization, rather than the appearance of the interface. The MT4 and MT5 comparison explains why platform features should also be checked separately.

How can you check access without risking live money?

Start with your own demo account using virtual funds. MT5 server settings describe changing the investor password when the owner knows the master password. Confirm that your provider supports this mechanism and ask about the procedure in your installed version. Do not follow an unsolicited “activate viewing access” link sent by another person.

  1. Check within the official application that the selected account is a demo and that its server belongs to your intended provider. The colour of a window alone is not evidence because interface settings can change.
  2. Create a separate investor password using the provider’s instructions. Open a separate demo session with that credential so that you do not mistake an already authenticated owner session for the observer’s restricted connection.
  3. Inspect the permission indication and access to history. If checking rejection of an order, do so exclusively on demo. Never submit a live order merely to discover whether a restriction is working.

Example: a report or a continuing account view?

In a hypothetical exercise, Anna has a demo balance of PLN 10,000 and an open position. Her practice partner needs only five completed trades. Anna chooses a report containing those trades rather than continuing access to the whole account. If live observation is necessary, she agrees the scope and end of access first. These amounts and events illustrate a decision; they are not a service test.

The first demo trade and execution-record exercise offers a starting point. If you cannot establish the authorization mode, end that session and resolve the uncertainty with official support.

Do read-only access and 2FA protect every detail?

No. Removing order permission restricts one function, while still potentially revealing account size, trading history and current exposure. A recipient can keep information already viewed. Revoking access cannot retrieve their saved reports or screenshots. Decide whether you accept that disclosure before granting a continuing connection.

Check two-factor authentication, or 2FA, separately for the portal and terminal. MetaQuotes describes 2FA/TOTP as requiring server support. Its documented investor-password mode does not request a one-time code. Do not infer that the protection used for your principal login also protects a read-only session. Confirm the actual arrangement with your provider.

Limit permission to act and permission to see separately. Preventing trades addresses only the first question.

Editorial conclusion

How do you revoke access when a task ends?

Record the procedure for changing the investor password and revoking connected permissions before sharing anything. Changing one credential may not terminate every existing session or API key. When a collaboration ends, ask which sessions must be closed and how revocation can be confirmed. Do not assume every device immediately disconnects without confirmation from the provider.

If you also shared a master password, recovery code or email access, address the wider exposure through official support and secure each affected route. The Polish financial supervisor’s communication on investment-firm cybersecurity emphasises additional access protection. A recipient’s promise to have logged out is not a substitute for revoking their permissions. Its supervisory context is Poland, although the access inventory is useful more broadly.

What to do after closing this article?

  1. List the access routes you actually shared, their permissions and their revocation procedures. Keep this note private without passwords, recovery codes, account numbers or identity documents; you need a record of access arrangements rather than another collection of secrets.
  2. Practise identifying read-only authorization on demo and record what you observed. If permissions remain unclear, ask official support to explain them before sharing any credential. Use the provider’s confirmed process, rather than a live transaction, to resolve uncertainty.
  3. Agree the task, visible information and end of observation with the recipient. Choose a limited report when it is sufficient, and ask the provider how to confirm that every relevant permission has been revoked when the collaboration finishes.