When a Broker's KYC Request Becomes a Red Flag

Here is a screenshot an NRI reader in Sharjah forwarded to the desk last week: a WhatsApp message from a "senior account manager" asking for a scan of his Emirates ID, his PAN card, six months of HDFC statements, and — this is the part that stopped us — his MT5 login and password for a "security check". The broker's branded header carried a logo that matched a DFSA register entry. The password request did not. Legitimate brokers do collect a lot of information, and the regulatory reasons are real. The question this piece settles is which columns on a broker's intake form are compliance and which columns should make a reader walk out.

TL;DR

Credentials requests are never compliance — always walk.
The entity collecting your data must match the regulator's register exactly.
Source-of-funds questions should feel bureaucratic, not consultative.

Red Flag #1: Information requested before any licence paperwork is shown

The sequence matters. A real onboarding flow starts with the broker identifying itself: a client agreement, a risk disclosure, and a terms-of-business document that names the licensed entity, its register number, and the regulator supervising it. KYC comes after the reader has seen who is asking.

What the Sharjah screenshot showed is the reverse. The "manager" asked for identity documents and bank statements before a single licensing page was shared. For an NRI living in the Gulf, this inversion is specifically dangerous — the reader is told to prove he is Indian-born and Gulf-resident before the broker proves it is a broker.

Why it matters: the regulator sequence is deliberate. The DFSA Conduct of Business module requires client-facing disclosures to precede data collection, and firms that skip this step are usually unlicensed intermediaries operating under a borrowed logo. If a counterparty wants your Emirates ID before it has shown you its own paperwork, you are not onboarding — you are being harvested.

A broker never needs the password to your trading terminal. Not for verification. Not for a security check. Not to "mirror a trade so you can see how our strategy works". There is no legitimate internal workflow at any regulated firm — Exness, XM, IC Markets, Pepperstone, or any entity on the DFSA register — that requires a client's MT4 or MT5 login credentials.

Access to trade on your behalf is granted through limited power-of-attorney documentation, which is a signed, dated instrument subject to firm-level compliance review and reversible at your instruction. It is not a password handover over WhatsApp.

What this request actually is: the counterparty wants to log in as you, place trades that generate volume (and spread revenue for them), and in the worst case initiate withdrawals once your funded account has a balance. Among NRI readers who have written to the desk after losing capital this way, the credential handover almost always preceded the loss by less than two weeks.

Why it matters: the asymmetry between what a broker can legally do with a signed authority and what it can do with your raw login is the difference between a regulated custody relationship and an unauthorised seizure.

Red Flag #3: Duplicate KYC that never gets cross-referenced to anything

Here is the pattern. The intake form asks for your Emirates ID. Then the follow-up email asks for the same Emirates ID uploaded through a second portal. A week later a different staffer messages asking if you can send the "clearer scan" to a Gmail address. The documents never seem to converge into a single file on their end. New requests keep arriving.

A functioning compliance function builds a client file once. The upload channel is encrypted, the file is logged, and if an additional document is needed later the request references the existing record. Compare the request to how the UAE's SCA-regulated intermediaries structure onboarding under its Investor Protection framework — intake is one portal, one log, one file.

Why it matters: duplicative KYC without cross-reference almost always means the person collecting your documents is not the person processing them, and nobody downstream has the authority to say "we already have this". For NRI readers this is particularly consequential — PAN cards and Indian bank statements that circulate through unlogged channels become feedstock for identity misuse on the India side, where enforcement is slower and the paper trail colder.

Red Flag #4: Source-of-funds queries phrased as sales qualification

Legitimate source-of-funds enquiries are bureaucratic and faintly tedious. The firm asks for a document — a salary slip, a sale deed, a dividend statement — and lodges it against a template. The questions come from compliance, not sales. They do not iterate. They do not probe.

What we see in the inboxes forwarded to the desk is the opposite. "Just between us, how much liquidity do you have across your accounts?" Or: "What's your typical ticket size if we were to open you at the premium tier?" Or the version an NRI reader in Doha was asked last month: "If your Indian mutual funds were liquidated, roughly what number are we looking at?"

Those are not AML questions. Those are sales qualification questions wearing a compliance costume. A regulated firm's source-of-funds process does not care about your total wallet. It cares whether the specific sum you are depositing can be traced to a declared source. If the conversation drifts into net worth territory, the person on the other end is pricing you, not verifying you.

Red Flag #5: Documents routed to WhatsApp or a personal email address

The address matters. A regulated broker provides a documented, firm-controlled upload channel — usually a client portal behind two-factor authentication, occasionally a dedicated compliance email at the firm's primary domain. What the channel is NOT: a WhatsApp conversation with an individual, a Gmail or Outlook address belonging to an "account manager", or a Telegram channel the staffer sends you a QR code to join.

Each of those routes removes the document from any audit log the firm maintains. If the staffer leaves — or was never actually employed — the record of what you handed over leaves with them.

The reader in Sharjah whose screenshot opened this piece was asked to send his HDFC statements to a Gmail address followed by a Dubai mobile number. The broker's actual client portal, discovered later, had a working document upload page. The staffer never mentioned it. There is a reason staffers never mention it when the goal is off-books collection.

Why it matters: for NRI readers who maintain active Indian banking relationships, a statement sitting in a stranger's personal inbox is an identity-theft vector that spans two jurisdictions and two enforcement regimes. Nobody in Dubai will chase an account harvested through a Mumbai login attempt six months later.

Red Flag #6: The entity collecting the data is not the entity on the regulator's register

This one is the quiet killer. The broker's website displays a DFSA licence number. The onboarding emails arrive from a company with a similar name — one word different, or a Ltd versus a FZCO suffix — and the terms-of-business PDF names a Mauritius or Seychelles subsidiary.

For NRIs this split is nearly standard practice at the retail-forex end of the market. The DFSA licence number on the landing page refers to a sister entity that handles institutional clients. The retail client agreement — the one you are actually signing — belongs to an offshore subsidiary with a different, lighter supervisory regime. Your capital, legally, is held under the offshore entity's rules, not the DFSA's.

The verification step: pull the licence number from the broker's own website, check it against the DFSA public register, and confirm the entity name on the register matches the entity on your client agreement, letter-for-letter. If the names diverge — even by a suffix — you are a client of the second entity, and the first entity's regulatory posture is marketing, not law.

Red Flag #7: The "compliance call" that quietly turns into an upsell

The call starts correctly. A voice confirms your name, asks you to repeat the last four digits of your Emirates ID, reads a short script about risk disclosure. Three minutes in, the script dissolves. The caller mentions that your deposit tier qualifies you for a managed account program, that there is a limited-time bonus if you upgrade in the next 48 hours, that your account manager — a different person entirely — will reach out shortly.

Compliance calls do not qualify leads. The person reading the risk acknowledgement is not the person who then tries to sell you anything. The division is required by conduct-of-business rules at every tier-1 regulator supervising the brokers on the desk's shortlist, and the DFSA's own Conduct of Business module makes it explicit.

What the hybrid call signals is one of two things: the firm has no separation between its compliance function and its sales function (which means its compliance function doesn't really exist), or the person on the call is a third-party IB — an introducing broker — pretending to speak with the firm's authority. For an NRI reader whose cross-border tax position depends on which entity actually holds the account, confusion about who is calling with what authority is not a cosmetic problem.

The Verdict

The honest reading of broker KYC in the Gulf retail market is that most of what gets asked is defensible — AML rules apply, PEP screening applies, source-of-funds documentation applies, and tier-1 regulators like the FCA (which supervises Exness, FXTM, and HF Markets at the group level) require a far more intrusive intake than a casual retail user expects. Being asked for a lot of documents is not, by itself, a sign of fraud. It is a sign of a firm being audited.

What distinguishes compliance from predation is channel, sequence, and authority. The firm should identify itself before you identify yourself. The channel should be firm-controlled and logged. The authority should be documented. The entity collecting the data should match the entity on the regulator's register. If a reader is forwarding WhatsApp messages to the desk and the questions in those messages fail any of those tests, our conclusion is uniform: close the chat, do not send another document, and lodge the broker name with the DFSA's complaints portal. We would reverse this stance if a specific firm could demonstrate — in writing, from its licensed-entity domain — that its onboarding sequence has been externally audited against the DFSA Conduct of Business module within the last twelve months, with the audit letter referenced in the client agreement. Until that evidence surfaces for a specific name, the checklist above holds.

FAQ

Why do legitimate brokers need so much personal information?

Three regulatory layers stack onto any Gulf-licensed retail broker. Anti-money-laundering rules require identity verification and source-of-funds documentation. PEP screening requires employer and relationship-to-government disclosures. Suitability rules — enforced by the DFSA Conduct of Business module — require income, net worth, and trading-experience data so the firm can match products to clients. The volume of paperwork is real. What distinguishes a compliant request from a predatory one is which channel it travels through and whether the entity asking is the entity on the regulator's register.

No. There is no legitimate workflow — technical support, account verification, compliance audit, bonus activation, or any other framing — that requires a client to share trading-platform credentials with broker staff. Access on your behalf is granted through limited power-of-attorney documents, which are signed, dated, logged, and reversible. A password handover is irreversible until you change it, by which point trades can have been executed and funds moved. If you have shared credentials, change the password immediately and audit the trade history for activity you did not authorise.

How do I verify that the entity collecting my KYC is actually the licensed broker?

Pull the licence number displayed on the broker's website. Open the DFSA public register directly in your browser rather than clicking a link in the broker's email, and search by that licence number. Compare the registered entity name — including the full suffix (Ltd, FZCO, DMCC) — against the name on the client agreement you are being asked to sign. If the names do not match letter-for-letter, you are being onboarded by a different entity, likely an offshore subsidiary, and the DFSA licence displayed on the marketing site does not govern your relationship.

I am an NRI resident in the UAE — are my Indian documents at additional risk when I hand them to a Gulf-based broker?

The exposure is structurally higher because enforcement sits in two jurisdictions with no shared compliance database. A PAN card, Aadhaar reference, or Indian bank statement circulated through an unlogged channel in Dubai becomes material that can be used for identity misuse on the Indian side, where the local regulator and the firm's Gulf regulator do not routinely cross-reference breaches. Insist on an encrypted, firm-controlled upload portal for every Indian document, and keep a dated log of what you shared, when, and through which channel.

What should I do if I have already sent documents through an informal channel like WhatsApp?

Stop sending further documents through that channel immediately. Request the firm's compliance email at its primary domain and resend only through that address, keeping a dated copy of the correspondence. Change passwords on any account whose login details were part of the exchange — Indian net-banking in particular, where unauthorised access cascades fastest. Lodge a written complaint with the DFSA's complaints portal naming the staffer, the channel, and the documents transmitted; this creates a record you can reference if the firm's conduct is later investigated and matters for any civil recovery you may pursue.