Every Pix participant can check whether your CPF carries a fraud flag. You can't.

Update, September 18, 2026. Resolution BCB No. 587, released on this date, changed part of what this piece describes. A flagged person can now request cancellation of the flag and must get an answer within seven days; the institution must cancel it if the grounds no longer hold, and must keep a record of its reasoning; and the five-year duration is now written into the Pix Regulation. A duty to notify the flagged person was created, but it only takes effect on February 1, 2027, and the minimum content of the notice does not include the reason. What did not change: the reviewer is the same institution that placed the flag, and the user still cannot query the directory. The passages below on the absence of notice, of a deadline to contest and of safeguards describe the rules as they stood until September 17, 2026. What changed, and what was left out.

Inside the Diretório de Identificadores de Contas Transacionais there is a record stating how many times your CPF has been flagged as involved in fraud, of what type, for what amount, and by how many different institutions. It stays available for up to five years.

Any Pix participant can query that record. The person it refers to cannot — and that is not an oversight in the system, it is a written rule.

As for the standard that authorizes the flag, the Banco Central itself wrote, in September 2025, that the Regulamento do Pix "does not establish objective criteria" and that the resulting subjectivity "has led to heterogeneous conduct among participants".

This article describes the mechanism on the basis of the Manual Operacional do DICT, Resolução BCB nº 506 of 2025, and the board votes underpinning that rule. Everything cited is a public document.

Three different things under one name

Coverage of this subject tends to compress into one three things the rule treats separately. It is worth unpacking them first, because almost every misunderstanding about "being flagged in the DICT" starts here.

The first is the duty of the institution that created the flag. Whoever flags, or whoever accepts an infraction report, is required to stop transacting with that customer. It is a legal obligation, and it reaches only that institution.

The second is the risk decision made by everyone else. They read the same statistics, with no published yardstick, and reach different conclusions about the same person. Nothing compels them to act, and nothing stops them. This is where the practical effect happens.

The third is the restriction on receiving funds, and it is the only part visible from outside. When the payee's account is restricted for involvement in fraud, the DICT key lookup returns that fact, and the would-be payer's app is required to state the reason — in wording drafted by the Banco Central itself. It is also the only one of the three that came with a duty to notify anyone.

Two doors to the same flag

The first is automatic, and almost no one realizes it is automatic. When a PSP accepts an infraction report opened to request a refund, the manual is blunt: acceptance "automatically generates a fraud flag for the user who received the transaction". It is not a second act of will. Accepting is flagging.

The second is standalone, and it sits in section 10.2. It exists for when the PSP "merely wishes to flag the CPF or CNPJ of a user who is its customer and who is involved in some fraud episode". It does not depend on a refund, does not depend on the Recuperação de Valores mechanism, does not depend on anyone having asked for money back.

It can be created, in the manual's words, "by any PSP involved in a given Pix transaction". Including the payer's PSP, to flag its own customer — the manual lists that scenario: when it "merely wishes to flag its own user, with no intention of recovering the funds".

Whenever the Pix key is known, it is reported as well, and the key is flagged along with the tax ID.

A flag nobody has to review

Of the standalone flag, the manual says it "need only be created by the Pix participant through the CreateFraudMarker endpoint".

The official FAQ page for version 2 of the DICT API is even more explicit: this endpoint "works without any need for analysis by the other PSP". The flag is born and closed in a single act, by the decision of one institution, with no review by anyone.

There is no counterparty to agree, no third party to verify, no window to contest. And, as we will see, no notice to the person flagged.

Two vocabularies the public debate mixes up

Here is the most common confusion, and it matters because the two fields do different things.

Whoever opens the report declares the SituationType — what is alleged to have happened on the paying side. Whoever accepts it declares the FraudType, and that is the one stamped on the payee.

FraudType is mandatory whenever the outcome of the analysis is "accepted". In other words: there is no accepting without classifying, and no classifying without flagging.

Note what mule_account describes: an account legitimately opened, by the person themselves, that received fraud proceeds. It is the category most likely to catch people who neither opened an account with forged documents nor are the fraudster.

One point about dates, to avoid misreading any sample: the FraudType field has existed only since version 2 of the DICT API, in production from 5 November 2023. Flags created before that date appear in the statistics as UnknownFrauds, with no type — and the manual explains, in a footnote, that this category comprises "reports opened in versions prior to version 2.0 of the DICT API". It is a migration artifact, not a sign of sloppy analysis.

The standard the rule uses and does not define

The field identifying the flagged party is described this way: "CPF or CNPJ of the user under well-founded suspicion of fraud".

Two paragraphs above, in the same section, the instruction to the PSP is different: "The PSP creating the flag must be certain that its customer is a fraudster".

Well-founded suspicion and certainty are not the same standard. The manual defines neither, and the section devoted to the well-founded-suspicion-of-fraud flow — 17.2 — does not define the term either: it describes where the flow fits and refers back to chapter 20.

This is not outside criticism. It is the regulator's own diagnosis, in writing. Voto 128/2025 of the Banco Central, which underpinned Resolução 506, states:

The Regulamento do Pix, however, does not establish objective criteria for Pix participants to deem a transaction to carry "well-founded suspicion of fraud" or "suspicion of fraud". (...) introducing subjectivity into the assessment (...). Indeed, this subjectivity has led to heterogeneous conduct among participants.

To fix this, Resolução 506 inserted art. 39-C into the Regulamento do Pix, under which participants must adopt "at a minimum, the criteria indicated by the Banco Central do Brasil, to be published in a specific document". The vote adds that the matter is complex and will be regulated "after broad debate with the Grupo Estratégico de Segurança do Pix".

As of the closing of this article, nearly a year later, that specific document could not be found as published. And that is not our reading: at the 28th plenary meeting of the Fórum Pix, on 26 March 2026, the item appears among the actions planned for the second half of the year, with progress described as "initial discussions".

A distinction is needed here that the article cannot blur, because it changes the scope of the promise. What art. 39-C directs the Banco Central to define are criteria for classifying a transaction — the Fórum Pix itself describes the item as "specification of the minimum criteria participants must observe in classifying a transaction as carrying suspicion of fraud or well-founded suspicion of fraud". The flag under section 10.2 falls on a person. These are two neighboring regulatory acts using the same undefined term for different objects, and what has been promised covers only one of them.

And there is a detail the Banco Central's vote makes explicit without meaning to. The stated concern with subjectivity is that it leads "to the non-rejection of transactions and the non-application of precautionary blocks on transactions with evident fraud characteristics". The regulator is worried about blocking too little. The error in the opposite direction — flagging someone who should not be flagged — does not appear in the diagnosis, even though it stems from exactly the same missing yardstick.

Sixteen days before Resolução 506, moreover, the Banco Central issued Resolução BCB nº 501, which inserted art. 2º-A into Resolução BCB nº 142 of 2021. Paragraph 2 of that article says the opposite of what art. 39-C promises: "The assessment of well-founded suspicion of involvement in fraud must include factors at each institution's discretion".

What the rule requires of whoever flagged

Here we need to undo a reading that circulates widely, including in texts by people who know the subject.

Art. 89, § 2, of the Regulamento do Pix, as amended by Resolução 506, provides that "the participant that accepts an infraction report or that creates an infraction report for transactional fraud flagging must reject all Pix transactions in which the user named in the report is the payer or the payee", except refunds.

Read quickly, it looks like a ban from Pix. It is not. The subject of the duty is that participant — the one that flagged or accepted. It is the institution that must stop transacting with the person it itself flagged. Someone flagged by one institution goes on transacting normally at the others, as far as this article is concerned.

The vote that proposed the change confirms this reading when it explains the problem being solved: the previous rule "does not prevent the user from opening another account at the same institution, redirecting the Pix key involved in fraudulent transactions to that new account". It was an internal-perimeter inconsistency, not a systemic ban.

Along the same lines, Resolução 506 determined that a participant must reject a key registration request, and must not process portability or claim of ownership, for a user it has itself flagged — arts. 56, § 3; 68, § 2; and 70, § 2.

It is worth noting what art. 78-HA represents. It was this article that, in September 2025, wrote transactional fraud flagging into the Regulamento do Pix. The vote explains why: the functionality "is not explicit in the Regulamento do Pix, despite already being available to participants" and provided for in the operational manual. In other words, a mechanism capable of restricting a person's access to payment services operated for years on the basis of a technical document, before gaining express footing in the rule.

The system warns the would-be payer, and drafts the words

There is one part of the mechanism that shows up on screen. It shows up for the wrong person.

The Manual de Requisitos Mínimos para a Experiência do Usuário, which forms part of the Regulamento do Pix and defines what apps are required to display, gained a new item in October 2025. It is in chapter 3, page 13:

Where a key is sent to the DICT and the response indicates an account or user restricted from receiving Pix transactions due to involvement in fraud, the paying user must be informed of this and of the impossibility of completing the transaction for that reason.

The message is mandatory, and the manual drafts the examples:

Account or payee involved in a transaction with well-founded suspicion of fraud. This Pix cannot be made.

This Pix key cannot be queried. Payee involved in a transaction with well-founded suspicion of fraud.

The same duty was added to chapters 6 and 7, for QR Code payments.

Three things to note.

The first is that the restriction comes back in the DICT lookup. It is not a conclusion the payer's app reaches on its own: the directory returns it, and the app is required to display it.

The second is the date. The item entered version 7.2 of the manual, in October 2025 — the month after the two September resolutions that created duties to reject transactions on well-founded suspicion.

The third is the perimeter, and it takes the edge off the alarm. The Fórum Pix records the measure as an action already completed, under the heading "restriction of the DICT's return of data on users associated with fraud flags", and describes its scope: restrictions applied "to the lookup, registration, portability and claim of ownership of Pix keys from participants that created the fraud flag".

Those are precisely the four operations Resolução 506 had already barred to the flagging participant — registration in art. 56, portability in art. 68, claim of ownership in art. 70 — plus the lookup. The directory began to enforce, on the technical side, the duty the rule imposed on the institution that flagged. It is not the whole system shutting the door: it is that institution's door, shut by the directory rather than by the bank.

It is worth saying where the rule is not: neither version 8.4 nor 8.5 of the Manual Operacional do DICT describes this return value.

And this is where the design closes. The Banco Central drafted the exact sentence a stranger reads when trying to pay — "payee involved in a transaction with well-founded suspicion of fraud". Across 164 pages, the manual that specifies everything a Pix app must show the user does not use the word "flag" even once, and provides for no message whatsoever to the person that sentence is about.

The flag reaches those who merely passed the money along

This is the point of greatest interest to payments operators, and it sits in the middle of section 10.1.

An infraction report "may be opened and accepted including in cases where the receiving user acts as a payment intermediary and the ultimate recipient of the transaction is not necessarily that intermediary".

The footnote defines payment intermediary broadly: anyone maintaining an account in its own name to receive funds from a payer for the benefit of a final recipient, expressly including "domestic and international marketplaces, collection agents (or billing agents or receipting agents), payment intermediaries". This is the arrangement the market usually calls a payment gateway, and the account those funds pass through, a pooled account.

A vocabulary warning is in order, because it gets in the way: "conta bolsão" circulates with more than one meaning, and not all of them match what the manual describes here. In this text the term is the footnote's — the intermediary's account that receives funds to pass on to the final recipient. The confusion between the senses deserves its own article, and it will get one.

The party flagged is the holder of the receiving account — and, in an intermediation architecture, that holder is the intermediary, not the ultimate beneficiary.

What the flag feeds

Section 18 describes the security-information lookup. A participant queries by Pix key, with getEntryStatistics, or by person, with getPersonStatistics.

The obvious moment for that lookup is account opening. That is where it feeds antifraud and compliance, and becomes an input to a decision on whether to accept the customer. It also serves relationship maintenance, when an institution reassesses someone who already holds an account.

What comes back is not a yes or no. It is a dashboard: number of settlements as payee; confirmed reports and flags created, broken down into ApplicationFrauds, MuleAccounts, ScammerAccounts, OtherFrauds and UnknownFrauds; the total amount of confirmed reports; how many reports remain open; how many were rejected.

And one field that says more than the rest: DistinctFraudReporters, the number of distinct participants that have confirmed at least one report against that CPF, CNPJ or key. It is what separates an isolated episode from a pattern — and it is the piece of information that weighs on a decision to open or terminate a relationship.

The data are updated with a maximum lag of twelve hours from the last event. The figures come back in three windows: the last 90 days, the last 12 months and the last 60 months, the latter two excluding the month of the query. Five years is the reach of the longest window.

Deleting the key erases nothing. The manual is express: "any action that may result in modifications to keys (deletion, alteration, portability or claim of ownership) neither removes nor invalidates infraction report information". And if the same key is registered again by the same user, the information "will be inherited by the new registration".

The manual delivers the number and stops there

What it does not do is say what the number means. It sets no threshold, does not grade by severity, does not distinguish a recent flag from an old one, and does not require anyone to disclose that they ran the query.

The manual goes so far as to spell this out: security information "is to be used by each Pix participant, at its own discretion, in its internal risk management processes".

That is the third appearance of the same formula — in the manual, in art. 2º-A of Resolução 142, and in the vote's own admission. The reading rests entirely with each institution, and that is where the matter stops being technical. For one compliance team, a single flag may be enough to refuse an account opening. For another, the same record is noise. The same DistinctFraudReporters supports both decisions, and neither breaches any rule.

The practical effect is familiar to anyone working in the sector, and appears in no rule at all: the refusal reaches the applicant as a generic message — we were unable to proceed, we are improving our systems. The person never learns that they were queried, or what the query returned, or that there was anything to contest.

And the flagged person cannot see it

This is not an inference. It is two provisions.

The first is in section 18:

Access to the endpoint must be made exclusively at the participant's own initiative; making the functionality available to end users is prohibited.

The second is in section 8.1, which exhaustively lists what may be displayed to a user running a key lookup: name or corporate name, trade name, masked CPF, the key queried and, optionally, the name of the payee's PSP. Security information is not on the list.

It is not that a channel is missing. It is that the rule forbids exposing the functionality to the very person the record describes.

The notice that exists in one rule and is missing from the other

The most eloquent comparison on this subject comes from two rules issued in the same month.

Art. 2º-A of Resolução BCB nº 142, inserted by Resolução 501, requires an institution to reject transactions destined for an account under well-founded suspicion of fraud. And § 3 of the same article provides: "The institution receiving the funds must inform the account holder that the measure has been applied".

Rejecting an incoming transaction requires notifying the holder. Flagging the holder in the DICT does not. And, as seen above, the would-be payer is notified with wording written by the regulator.

On flagging, the only duty to inform in all of Resolução 506 is in art. 56, § 3: on rejecting a Pix key registration request from a user it has flagged, the participant must "inform the user of the reason for the rejection". The notice arrives when the person tries to register a key — not when they are flagged.

And the gap between the two tracks widens on reading Comunicado BCB nº 44.253, of 19 November 2025, which clarifies art. 2º-A in Q&A form. It answers, without hedging, the question Resolução 506 left open:

Are there minimum criteria or any standardization to be adopted for assessing well-founded suspicion of involvement in fraud? (...) There are no minimum requirements or standards; this is left to each institution.

The same communiqué, however, hedges that discretion with three things the DICT flag does not have. The institution "must keep a record of the information and documents underpinning the identification of well-founded suspicion". It must inform the holder "in a timely manner". And, asked whether there should be a channel for the customer to request review of the assessment, the Banco Central answers yes — the institution "must make customer service channels available (...) so that its customers may seek assistance regarding operations and services provided".

A record of the grounds, notice to the holder, and a review channel. It is the same undefined standard, with safeguards on one side and none on the other.

One caveat is due, because the communiqué also opens a gap: if the rejecting party is the sending institution, "the receiving institution's obligation to inform the customer account holder is set aside". In that case the holder may not be notified by anyone.

Due process appears once, and not for the flagged person

Resolução 506 devotes much of its text to the procedure for investigating non-compliance with the Regulamento do Pix. There you find notification through a formal channel, challenge within five business days, appeal within five business days, an action plan, a request for extension, and an express guarantee in art. 94:

In the non-compliance investigation procedure (...) the Banco Central do Brasil shall observe the participant's right to adversarial proceedings and full defense.

The participant is the institution. That whole structure protects the bank before the regulator.

For the flagged person, the same rule provides no notification, no deadline, no challenge and no appeal. The phrase "full defense" appears once in the text, and it is not theirs.

Who can undo it

Always an institution. Never the person flagged.

An infraction report may be cancelled only by the participant that opened it. If a report already closed is cancelled, the flag it generated falls away with it, automatically. A flag generated automatically may be cancelled by the participant that closed the report. And the standalone flag under section 10.2 may be cancelled at any time — by whoever created it.

There is an unintended symmetry in this design: the flag is born by the unilateral decision of an institution and dies only by the unilateral decision of an institution.

What this demands of operators

Three things, none of them opinion.

If accepting an infraction report flags the customer, then analysing that report is a decision about someone's financial life, not a back-office task measured by response time. The FraudType chosen there is what the rest of the system will read, for up to five years.

If mule_account describes a legitimately opened account, then the difference between scam victim and scheme participant lives in the analyst's judgement — and that is the line the institution must later be able to demonstrate.

And if the flag reaches intermediaries, then anyone running a marketplace, sub-acquiring operation or pooled account carries a risk that is not its own business's, but that of the flow passing through it.

What this article does not claim

We do not claim that institutions flag people improperly, nor how often that happens. There is no public data on this, and without data there is no claim.

Nor do we claim that the minimum criteria under art. 39-C do not exist. We claim that we could not find them published, which is a different thing.

Nor do we claim which rule produces the restriction response in the DICT. That it exists is documented twice — in the user experience manual and in the Fórum Pix, which records it as a completed action and describes its scope. Neither names the provision, and the Manual Operacional do DICT does not describe the field. We verified the effect and the perimeter; the rule number, no.

What is documented is something else, and it is enough: the flag can be created by the decision of a single institution, with no review by another participant; the objective standard promised by the regulator covers the classification of the transaction, not the flagging of the person, and the Banco Central has stated in writing that it does not yet exist; the reach extends to those who merely intermediated; the record circulates for up to five years among every institution; and access to the endpoint that exposes it is barred to the end user.

And we do not claim there is no path at all for the flagged person. What does not exist, as far as we have verified, is an official channel created for that purpose — which is different from saying there is no way out. Registrato and the Sistema de Registro de Demandas do Cidadão (RDR), under Resolução BCB nº 222 of 2022, do exist, and the question is what each of them reaches.

That is the next article, and it requires opening both at the source before writing a line — because a great deal of second-hand information circulates on the subject, including claims of a lookup that may not exist.

Sources

Manual Operacional do DICT, versão 8.5, by the Banco Central, part of the Regulamento do Pix — sections 8 and 8.1 (data returned in a key lookup and data permitted for display to the user), 10.1 (infraction report for refund requests, the SituationType and FraudType domains, and the payment intermediary caveat), 10.2 (infraction report for transactional fraud flagging), 17.2 (well-founded-suspicion-of-fraud flow) and 18 (security information lookup, windows, and the footnote on UnknownFrauds). Quoted passages come from there.

Voto 128/2025-BCB, of 26 September 2025 — underpins Resolução BCB nº 506. It is the source of the admission that the Regulamento sets no objective criteria, the diagnosis of heterogeneous conduct, the rationale for art. 89, and the finding that transactional fraud flagging was already operating without express footing in the Regulamento.

Voto 116/2025-BCB, of 10 September 2025 — underpins Resolução BCB nº 501 and contains the proposed text of art. 2º-A of Resolução BCB nº 142, with the assessment of well-founded suspicion "at each institution's discretion" and the duty to inform the account holder.

Resolução BCB nº 506, of 26 September 2025 — amends the Regulamento do Pix, annexed to Resolução BCB nº 1 of 2020. Arts. 39-C, 56, 68, 70, 78-HA, 89 and 94.

Resolução BCB nº 501, of 11 September 2025 — inserts art. 2º-A into Resolução BCB nº 142 of 2021.

Dúvidas comuns da API v2 do DICT, by the Banco Central — version cut-over dates and confirmation that creating a transactional fraud flag requires no analysis by the other PSP.

Manual de Requisitos Mínimos para a Experiência do Usuário, versão 7.3, by the Banco Central, part of the Regulamento do Pix — chapter 3, item 06, and the equivalent items in chapters 6 and 7, on the mandatory message to the payer when the DICT returns an account or user restricted for involvement in fraud. The version history dates the addition to October 2025, in version 7.2.

Comunicado BCB nº 44.253, of 19 November 2025 — clarifies art. 2º-A of Resolução BCB nº 142 in Q&A form. It is the source of the answer that there are no minimum requirements, the duty to keep a record of the grounds for the assessment, the duty to inform the holder, and the duty to provide a channel for review requests.

Fórum Pix — 28ª Reunião Plenária, of 26 March 2026, by the Banco Central — places the minimum criteria among the actions planned for the second half of the year, at "initial discussions", describes the item as criteria for classifying a transaction, and records as already completed the restriction on the DICT's return of data on users associated with fraud flags, with its respective scope.

Instrução Normativa BCB nº 766, of 27 July 2026 — publishes version 8.5 of the manual.