Pocket Broker Customer Support in Brazil

Support channels

Support lives inside the product: the channels sit in the site and the app, reachable after logging in. Outside them, the only published contact is the developer email shown in the Android store.

It is worth starting with what is verifiable, because this is where a great deal of wrong information circulates. There is no telephone centre advertised, there is no confirmed office in Brazil and there is no company called "Pocket Broker" with support of its own — the name is the Brazilian nickname for Pocket Option.

The channels inside the product

As on almost every platform of the kind, the normal route of contact is the account's support area, reachable through the site and the app. Most requests go through there, because the agent can see the sign-up and the history without having to confirm your identity over several rounds. No official page consulted for this guide publishes a catalogue of those channels — which exist, at what hours they operate, in which languages — so the practical guidance is to use what appears on your screen, inside the official domain, and to be wary of any channel found outside it.

The contact published outside the site

The official Android app listing on Google Play shows [email protected] as the developer contact, identified as Pocket Investments S.R.L. It is a developer address, not a customer support desk, and it serves mainly as a verifiable point of identity for the company behind the app.

The rule with no exception

Legitimate support never asks for your password. Profiles presenting themselves as "Pocket Broker support" in messaging groups, video comments and direct messages are not an official channel, and a request for credentials is the sign that settles the doubt — as is an invitation to deposit through a link sent in private. The login page describes the most common access scams in detail.

The real channels sit inside the site and the app, after logging in. The only contact published outside them is the developer email on the Android store — and no genuine support asks for a password.

What support handles

Support settles what is under the platform's control: account access, the progress of a deposit and a withdrawal, and the review of verification documents. Beyond that its reach is small.

Separating the two lists saves days of messages. A good part of the frustration users report comes from requests that support has no way of meeting, because they do not depend on it.

Verification: the most frequent case

A large share of tickets is born of the same origin. The Public Offer requires scanned copies of an identity document and of proof of the residential address; the Payment Policy asks for a full copy of all the pages of the document and reserves to the company the right to request utility bills, bank confirmation or an image of the card. The period for the client to comply is 10 business days from the request, extendable to 30 days. A cropped document, a photo with glare or an address at odds with the sign-up produce a refusal, and the refusal reopens the cycle. The full script is in account verification.

Money that is stuck

On payment matters, support can tell you the stage of the request, but it does not speed up the external provider. That is why proof with an identifier and a timestamp is worth more than any description of the problem: with it, the agent locates the transaction; without it, the conversation turns into an exchange of questions. The timings and the limits are in withdrawal problems.

Access, payments and verification are support's territory. The result of a trade, the withdrawal currency and country policy are not — and pressing on those three only consumes time.

Response expectations

No official document promises a response time for support. What exists in the contract are periods of another kind: those for verification and for withdrawal processing.

This is one of those questions where the honest answer is more useful than an invented number. This guide publishes no average wait because the company publishes none, and because counts put out by third parties have no verifiable origin.

The periods that are written down

• Verification. 10 business days from the company's request, extendable to 30 days, under the Payment Policy.
• Withdrawal processing, in the Public Offer. Three business days, with provision for extension to up to 14 business days.
• Withdrawal processing, in the Payment Policy. Five business days; for a bank transfer, 3 to 45 business days; for electronic methods, "from seconds to days".

The two documents diverge from each other, and that divergence is useful information rather than a detail: it means the correct reference for chasing a delay is the document applicable to your method, and that complaining before the longer period is up weakens the request. Counting the right period is half the way to a well-settled ticket.

Peak periods

A support queue grows when the volume grows — weekends, holidays and episodes of strong market movement are the natural candidates. That is not a stated characteristic of the company, it is the normal behaviour of support operations, and it holds as an expectation rather than an accusation. The practical consequence is simple: a request sent with all the information in the first contact crosses the queue only once.

Support in Portuguese

The Android app listing states localisation in fifteen languages, without listing which. There is an indication of a Portuguese version — the 2021 CVM alert cites the address pocketoption.com/pt — but no official page confirms the current state of that version, nor that human support answers in Portuguese. Treat the language as something to confirm on the company's official pages, and write in English if you want to reduce the risk of noise in the first reply.

There is no response time promised in a document. There are verification periods (10 business days, extendable to 30) and withdrawal periods, divergent between the two documents — and it is by those that a delay is measured.

Getting a faster answer

A well-written message saves rounds: one subject per ticket, facts in chronological order, legible attachments and an explicit request at the end. That is what separates two days from two weeks.

The problems and fixes page lists which information to include. Here the subject is a different one: how to organise that information into a text the agent can settle on a first reading.

The skeleton of a ticket

1. A factual subject line. "Withdrawal requested on 12/03 still processing" works; "URGENT, please help me" says nothing and lands in the same queue.
2. Identification of the account. The registered email, right at the start, so that the search happens before the reading.
3. The facts in order, with dates. What was done, when, by which method, and what the screen showed. No adjectives and no interpretation.
4. What you have already tried. Documents sent, resends, earlier tickets and their reference numbers.
5. An explicit request. Say what you want: the stage of the request, the reason the document was refused, the expected date. A ticket with no question gets a generic reply.

Attachments that work

A legible image settles more than a well-written paragraph. Photograph the whole document on a neutral surface, without flash and without cropping the edges; capture the screen showing the exact message, with the date and time visible; and send everything that was asked for at once, rather than one file a day. A resend in instalments restarts the review and is one of the most common causes of a long wait.

Pressing without getting in the way

Replying inside the same reference number keeps the history together; opening a new ticket every day generates parallel references and the impression, on the other side, that someone else is already handling the case. When the published period for that type of request has already passed, the effective move is to reply in the same thread gathering the chronology into a single message and asking for a position on the outstanding item. Politeness is not a matter of etiquette here: aggressive messages tend to be routed to triage rather than to a solution.

Before you need support

A good part of tickets disappears with preparation: a sign-up consistent with the document from the start, verification completed before the first withdrawal request, a currency chosen with the withdrawal in mind and the mechanics of the platform learned in the demo environment, where a mistake costs nothing.

A factual subject, the account email at the top, a chronology with dates, complete attachments and an explicit request. Press on inside the same reference number, never across three channels at once.

Support verdict

The balance is an honest one: the channels exist, they work inside the product and they settle most operational cases. The ceiling appears when the case stops being operational.

A useful verdict has to say both things — what support delivers and where it ends.

What works

• The channels sit inside the product, reachable from the app and the browser, with no intermediary.
• The most common subjects, access, documents, the progress of a payment, are exactly the ones support has the means to settle.
• The rules that generate most questions are written into a public document and can be checked before opening the ticket.

Where there is room to improve

• There is no published response time, which leaves the user with no yardstick for knowing when to chase.
• The two official documents diverge on the withdrawal period, which passes to the client the work of finding out which one applies.
• There is no official catalogue of channels and no confirmation of support in Portuguese.

The ceiling on support

Here the page needs to be frank, because this is the part that changes decisions. The Public Offer submits the contract to the law of Costa Rica and points to the courts there; the company's legal pages give an address in Costa Rica without naming the operator. There is no confirmed office in Brazil and no local telephone number published. And there is no CVM authorisation: in an alert of 4 October 2021, the regulator stated that Pro Trade LTD, Pocket Option and Gembell Limited had no authorisation to take on clients, and by Ato Declaratório CVM 19.121, of 28 September 2021, it ordered the immediate suspension of the circulation of any public offering to investors resident in Brazil; whether that act remains in force could not be confirmed. Add to that the most concrete fact of all: the company itself states, on its home page, its About Us page and its payment-methods page, that it does not provide service to residents of Brazil.

In practice that means the platform's support is the interlocutor, and after it what remains is documented persistence and public exposure of the account, reputational pressure, which is different from jurisdiction. The escalation route is described in complaints. None of this amounts to fraud, and no primary source in this guide uses that word: it describes an absence of authorisation, a suspension order and a contract governed by foreign law.

All the information, platform data and regulatory statements on this page were checked in September 2026 on Pocket Option's own site and in the alert published by the CVM in 2021; both the platform's terms and a regulator's position may change at any time.

Reachable channels, effective on what is operational, with no published response time and no instance above them: a contract under the law of Costa Rica, no Brazilian office and no channel at the CVM.