BCB Resolution 587, published on September 18, 2026, creates a flag for well-founded suspicion of transactional fraud tied to the payer's CPF (individual taxpayer ID) or CNPJ (corporate taxpayer ID) inside the DICT — the Central Bank's Pix key directory. The flag stays active for five years and follows that person's record across any participating Pix institution. The obligation to reject transactions takes effect on February 1, 2027.
The gap between publication and full effect is a little over four months. For fraud-prevention and product teams, that's enough time to adjust flows. There's no room left to wait.
What the resolution introduces
The rule amends BCB Resolution 1/2020, which regulates Pix, on three fronts: the transactional fraud flag, hybrid billing (a model that lets a single charge offer Pix and a bank slip as alternatives), and Automatic Pix on payroll accounts.
The transactional fraud flag is the most relevant point for fraud-prevention operations. Pix participants can now create, inside the DICT, an "infraction notice" — the formal record of the suspicion — tied to the CPF or CNPJ of a customer involved in a suspicious transaction. The flag crosses institutional boundaries: any participant querying the DICT will see the record.
"The critical point of BCB 587 isn’t the block itself. It’s that the flag follows the CPF — closing the account doesn’t erase the record. That changes how fraud teams need to think about the risk window: it doesn’t end when the customer leaves."
— Sandro Righi, Compliance, Risk and Controls Specialist · Fortface
Situations that typically trigger a flag: an account receiving funds known to have been diverted, a transaction pattern inconsistent with the declared profile, repeated requests through the Special Return Mechanism (MED), and attempts to open an account to operate as a money mule.
What participants are required to do
Starting February 1, 2027, participants that create or accept a well-founded-suspicion flag are required to:
Reject transactions: every Pix operation in which the flagged user appears as payer or recipient must be blocked. The only exception provided for is a refund back to the user.
Block the Pix key: registering a new key and porting an existing key are both refused for flagged CPFs and CNPJs.
Notify the user: the participant that created the flag must inform the account holder of the date of the record, the possibility of review, and the channel for requesting clarification.
Review cancellation requests: the user can request that the flag be canceled. The participant has seven calendar days to review and respond.
These obligations build a new operational cycle: the flag isn't an isolated act of blocking, but the start of a flow with duties of communication, review and response within defined deadlines.
What changes in day-to-day operations
The rule changes the transaction-authorization flow, inserts the DICT into the onboarding journey, and creates communication and deadline obligations that require a defined internal process before February 2027.
Real-time transaction monitoring. The rejection logic requires the DICT query to happen inside the transaction-authorization flow, not in a batch afterward. Product teams that currently run risk analysis post-authorization will need to review their decision architecture to insert the directory query before the transaction is confirmed.
Exposure from accepting transactions from flagged users. Starting in February 2027, processing a transaction from a CPF/CNPJ with an active DICT flag constitutes non-compliance with the rule. The risk isn't just operational — it's regulatory.
Managing cancellation requests. The seven-calendar-day deadline to respond to cancellation requests requires a documented internal flow. Without a defined process, the queue builds up and the deadline is missed.
Incident communication. Starting February 1, 2027, PSPs (Payment Service Providers) that hold accounts are required to notify account holders of any security incident involving personal data related to Pix, regardless of liability or potential harm. This obligation is independent of the fraud flag.
What to ask your technology vendor
The resolution doesn't name specific technologies, but the technical requirements it creates map directly onto product architecture.
Does the DICT query happen before transaction authorization? Vendors that fold the DICT response into the real-time decision flow reduce the risk of processing transactions from flagged users. Batch or asynchronous queries don't meet the logic of the rule.
Does the system log and track the flags it creates? The obligation to respond to cancellation requests within seven days requires a record with the date, channel and status of each flag. Without it, the process is manual and prone to missed deadlines.
Is the user-notification flow automated? The rule requires the participant that created the flag to notify the user within a reasonable timeframe and through an accessible channel. Manual processes don't scale with volume.
How does the system handle blocking the Pix key for flagged users? The restriction on registering and porting keys needs to be built into the KYC and account-opening flow.
When does each obligation under BCB 587 take effect?
- September 18, 2026: publication; the flagging mechanism becomes available in the DICT; immediate disconnection of a participant.
- February 1, 2027: obligation to reject transactions from flagged CPFs/CNPJs; hybrid Pix + bank-slip billing; duty to notify account holders of security incidents.
- July 1, 2027: Automatic Pix on payroll accounts.
To go deeper
- Second biometrics vendor: when it makes sense and how to set it up — how to build operational resilience ahead of a regulatory change
- Fortface solutions for banks and fintechs
