Security at True Vestoworthen

1. Two-factor and multi-factor authentication

Every True Vestoworthen account supports two-factor authentication (2FA) using a time-based one-time code from an authenticator app on your phone. We recommend turning it on the day your account is activated, and your personal manager will walk you through the pairing if you have not used one before. SMS codes are offered only as a fallback where an app is genuinely not available, because telephone networks are easier to attack than app-based keys.

2FA is optional in the sense that the platform remains usable without it, but accounts holding a trading balance are strongly encouraged to enable it, and the dashboard reminds you until you do. Multi-factor checks are also applied automatically in certain situations, for example a login from a new country or a change of withdrawal details, where an email confirmation is required in addition to the password.

If you lose your device, recovery is handled through support with identity verification, described in section 6. One-time recovery codes are generated when you enable 2FA; each works once when your phone is unavailable.

2. Encryption of data

All traffic between your browser and the platform travels over TLS, and certificates are kept current so the padlock in your address bar is always valid. Inside the systems, personal data and verification documents are encrypted at rest, which means a copy of a stored file is unreadable without the keys held in the access-controlled management layer.

Encryption covers the systems holding account records, identity documents and the audit log described in section 8. Card numbers are never stored on our systems at all: payments are processed by regulated providers, and we keep only the last four digits and an issuer reference so support can identify a payment.

Responsibility sits with the engineering team in London, reviewed at least annually and after any significant infrastructure change. Where a provider processes data, for example for identity checks, its security obligations are written into the contract before any data is sent.

3. Protection against fraud and phishing

The only domain through which True Vestoworthen operates is https://true-vestoworthen.co.uk, and email we send comes from addresses ending in true-vestoworthen.co.uk. Any other site, app or message using our name, however convincing, is not ours. The Fraud warning page explains how clone firms work and how to report one.

Official messages never ask for your password, a one-time code, or full card details. Where we need to confirm something sensitive, we ask you to log in and act inside the platform rather than reply to a message. Each account can also set a personal security word with its manager, which you may ask the caller to confirm before discussing anything about your account.

If a message claiming to be from us looks slightly wrong, a different tone, an urgent deadline, an unexpected attachment, do not click anything in it. Forward it to [email protected] and we will tell you whether it came from us.

4. Login notifications

You receive an email whenever a new device signs in to your account for the first time, and another when unusual activity is detected, such as a login from a country you have not used before or several failed password attempts. The notification tells you the device type, the approximate location and the time, so a glance is enough to know whether it was you.

If a notification surprises you, open the sessions page described next, end every session you do not recognise, and change your password immediately. Then write to support so the account can be flagged while we check the audit trail together. Acting within minutes matters more than being certain.

Notification emails never contain links that ask for credentials. If a so-called alert pressurises you to confirm details, it is phishing regardless of how it looks, and section 3 applies.

5. Managing devices and sessions

The security page of your dashboard lists every active session: the browser, the device, the IP address and when it last refreshed. From the same list you can end any session instantly, or sign out everywhere at once, which is the recommended action if a device is lost, sold or borrowed.

Sessions expire automatically after a period of inactivity. Withdrawal requests additionally require re-entering your password and, where 2FA is enabled, a fresh one-time code, so an open tab alone is never enough to move money.

Devices used for 2FA pairing are remembered, and the trusted-device list can be cleared at any time, forcing a full two-factor check on the next login from each device. That is the right step after travelling or changing phones.

6. Account recovery

Recovering an account always involves verifying that you are the account holder, never simply answering questions that could be looked up about you. The standard route is an email to [email protected] from the address on the account, followed by an identity check against the documents already held from verification, and, where anything is inconclusive, a short call with your personal manager.

Recovery has deliberate limits. Support cannot read your 2FA secret back to you, cannot disable 2FA on the basis of a polite email alone, and cannot change the destination bank account in the same conversation that changes the account email. Steps that matter are separated by confirmation delays, which is slower but closes the easiest route an attacker has.

While a recovery is in progress, withdrawals on the account are paused by default. That pause is lifted as soon as the check completes, and it exists precisely so that someone impersonating you cannot combine a takeover with a same-hour transfer.

7. API key permissions

Where the platform connects to an exchange account on your behalf, it does so through API keys you create with limited permissions. The keys we ask for allow reading market and balance data and placing trades. Withdrawal permission is not required, and you should never grant it to any third-party service, ours included, unless a support article for a specific feature explicitly says otherwise and you understand why.

Keys are stored encrypted, shown in full only once at creation, and can be revoked from your dashboard at any moment, which immediately stops any new action that relies on them. Revocations and rotations are recorded in the audit history with the session that made them.

If a key was created with broader permissions than needed, revoke it and create a correctly scoped replacement. Your manager can review the current key list with you and confirm what each entry is for.

8. Audit history

Logins, failed login attempts, new devices, changes to strategy settings, deposits, withdrawal requests and edits to personal details are all recorded with a timestamp and the session responsible. The history is shown to you in the dashboard, in the same plain language as the monthly reports, so you can check what happened without asking anyone.

The same records serve disputes and investigations: if you query a withdrawal or a strategy change, support reads the same trail you can see, which keeps the conversation factual. Entries cannot be edited or deleted by anyone, including our staff, and retention follows the Privacy Policy.

Reviewing the audit history occasionally is a good habit, particularly after travelling or granting a new API key. Anything you do not recognise should be raised immediately through the incident route in the next section.

9. Support during incidents

If you suspect unauthorised access, the fastest route is email to [email protected] with the subject line containing the word security, followed by a call to your personal manager. The account can be frozen while the audit trail is reviewed, which stops logins, trades and withdrawals without touching the balance itself.

A security incident follows a set order: contain first, communicate second, restore third. You will be told who is handling the case, what is paused and what the next step is, with updates at agreed intervals. If credentials were reused on other sites, changing them there is treated as part of the fix.

Suspected incidents also improve the platform: confirmed attack patterns feed back into login rules and alert thresholds. Reporting something that turns out to be benign is never a waste of anyone's time.