Chapter 1. The DICT is a quota, not a phone book.

The DICT (Diretório de Identificadores de Contas Transacionais) maps a Pix key to account details. Integrations that break in production almost never break on that mapping. They break on rationing. The Banco Central do Brasil meters lookups per user and per participant, and refuses service when the counter hits zero. A team that ignores this mechanism until go-live finds out through a spike in HTTP 429 errors.

What the DICT will store, and how much

Five Pix keys per transactional account for a holder registered under a CPF (the individual taxpayer ID), 20 for a holder registered under a CNPJ (the business registration number). The limit applies to the account, however many joint holders it has (Manual Operacional do DICT, version 8.4, Banco Central do Brasil).
One key, one account. The same identifier can never point to two transactional accounts at once.
The DICT generates the random key (chave aleatória); the user does not choose it. It is a UUID in RFC 4122 format, and it cannot be customized.
Storage formats: CPF as 11 digits, CNPJ as 14 alphanumeric characters, both without periods or hyphens; phone numbers in E.164 format; email addresses of up to 77 characters.
The name shown to the payer comes from the Receita Federal, Brazil's federal tax authority. For a legal entity, the Name field carries the registered legal name (razão social) and the TradeName field the trade name (nome fantasia), but only if it appears in the CNPJ registration. For an individual microentrepreneur (microempreendedor individual), TradeName must be left empty.

Every lookup carries the PI-PayerId header. It holds the CPF or CNPJ of the user who will pay, as bare digits, and it must stay the same across all of that user's lookups at a given participant. The DICT uses it to track two counters: lookups that led to no payment order, and lookups on unregistered keys. The second costs 20 times as much as the first.

Bucket	Maximum size	Deduction	Credit	Refill over time
Individual end user	100 tokens per bucket; one bucket for phone and email, another for CPF, CNPJ, and random key	1 token per valid lookup, 20 tokens per invalid lookup	+1 token when the lookup is followed by a payment order received by the SPI, the BCB's instant settlement system	2 tokens per minute, in each bucket
Legal-entity end user	1,000 tokens per bucket, same split	1 token per valid lookup, 20 tokens per invalid lookup	+2 tokens per lookup followed by an order received by the SPI	20 tokens per minute, in each bucket
Participant	From 50,000 down to 50 tokens, depending on the category the BCB assigns	1 token per valid lookup, 3 tokens per invalid lookup	+1 token per lookup followed by an order received by the SPI	Depends on the category

The token bucket applied to the getEntry operation (Manual Operacional do DICT v8.4, Banco Central do Brasil)

Category	Bucket size	Refill per minute
A	50 000	25 000
B	40 000	20 000
C	30 000	15 000
D	16 000	8 000
E	5 000	2 500
F	500	250
G	250	25
H	50	2

The eight participant categories: the BCB assigns them, and it can downgrade a participant it suspects of a scraping attack

⚠️

A missing key costs 20 times as much as a found one

The example comes straight from the manual. An individual user whose bucket holds 5 tokens looks up an unregistered key. The DICT responds NOT FOUND with HTTP 404 and deducts 20 tokens, leaving a balance of −15. At two tokens per minute, that user cannot run another lookup for eight minutes. An empty bucket returns RATE LIMITING with HTTP 429, and a free-text key field with no client-side format validation produces exactly that outcome at scale.

🔑

The standard fix: checkKeys and the existence cache

The manual provides the tool that avoids the penalty. The `checkKeys` operation takes a set of candidate keys and returns the ones registered in the DICT; it is for the participant's internal use only. It feeds a Pix key existence cache, which the participant uses to manage its buckets and to prepare bulk payments. Entries derived from payment-initiation lookups and from portability or claim processes are kept for 30 days. The cache may store only three things: the SHA-256 hash of the key and the two update dates. Not the key in plain text, not the holder's data, not the account data.

🎯 Quick question

A form lets customers type in a Pix key with no format validation. Many entries match no registered key. What is the direct effect at the DICT?

Chapter 2. Losing a key: portability, ownership claims, and blocks.

Two procedures move a Pix key from one institution to another. Portability (portabilidade) covers a holder who switches PSPs and keeps the key. An ownership claim (reivindicação de posse) covers a third party who asserts that they are the rightful owner of the identifier, such as a recycled phone number or a reassigned email address. The two look alike. Yet their default outcomes are opposite, and that is how a collection key gets lost.

	Portability	Ownership claim
Who opens it	The claiming PSP, at the request of the holder switching institutions	The claiming PSP, on behalf of a user who asserts ownership of the identifier
Resolution period	Seven days	Seven days
If the original holder does nothing	The donor PSP must cancel the request. The key stays put.	The donor PSP must confirm the claim. The key is gone.
During resolution	Lookups still return the original account	Lookups return the original account until day seven
After day seven	Process closed, one way or the other	The key is unlinked: lookups return “key does not exist”
Closing period (encerramento)	Not applicable	Seven more days: the original holder can still prove ownership and have the request canceled
Final grace period	Not applicable	On day 30, if the claimant has not proved ownership, the claimant's PSP must cancel to release the key

Two procedures, two outcomes of silence (Manual Operacional do DICT v8.4, Banco Central do Brasil)

D+0

Launch

The DICT sets the request to “Aberto” (open). The key can be neither registered nor deleted until the process closes.

D+0 → D+7

Aguardando Resolução (awaiting resolution)

Lookups still return the original account. Either PSP can cancel if it suspects fraud.

D+7

Resolution period ends

In an ownership claim, with no sign of fraud and no response from the holder, the donor PSP confirms. The key is unlinked.

D+7 → D+14

Encerramento (closing)

The original holder has one last window to prove ownership and have the claim canceled.

D+30

Forced release

If the claimant has not proved ownership, the claimant's PSP must cancel the request so the key becomes available again.

⚠️

In an ownership claim, silence means losing the key, and printed QR codes fail without an error

The manual is unambiguous. After day seven, with no sign of fraud and no consent from the user, the donor PSP must confirm the claim. The key is then unlinked, and lookups return “key does not exist.” A merchant that collects on a phone number or an email address therefore loses its addressing without a single alert from its own systems. Static QR codes already printed, taped to the register, or sent by email stop resolving. The countermeasure is one line of architecture: collect on a random key, which nobody can claim, and keep phone and email keys for contact purposes.

Monitoring is not optional. The manual requires a direct participant to poll the portability service and the claim service at least once a minute, to detect the status changes that affect it as either the claiming or the donor PSP. An integrator that works through a PSP must require that PSP to expose this event. Otherwise, the first sign of a claim is a customer who can no longer pay.

Court-ordered block: when a key is blocked by court order, the DICT returns EntryBlocked with HTTP 400 for lookups, updates, deletions, portability, and claims. The participant must mirror the block in its internal databases.
Irregular registration status, individual: suspensa, cancelada, titular falecido (holder deceased), or nula. The Regulamento do Pix then prohibits keeping the key.
Irregular registration status, legal entity: suspensa, inapta, baixada, or nula. A CNPJ that becomes inapta loses its keys, and with them its Pix collection, without anyone making a business decision.
MEI exception: for the CNPJ of an individual microentrepreneur (microempreendedor individual), “suspensa” status is not treated as irregular when it results from article 1 of Resolução CGSIM nº 36 of May 2, 2016.
The name must match the Receita Federal register word for word. Only a closed set of deviations is tolerated: diacritics from a fixed list, swapping periods, commas, hyphens, apostrophes, and spaces for one another, and replacing the & symbol with the letter E.

🎯 Quick question

A third party opens an ownership claim on the phone number your company uses as its Pix key. Nobody in your organization responds. What happens on day eight?

Chapter 3. Static QR codes, immediate charges, and due-date charges.

Three objects collect a Pix payment, and many teams wire up only one. A static QR code bypasses the API entirely, is generated offline, and can be reused indefinitely. An immediate charge (cob) carries an amount and a short lifetime. A due-date charge (cobv) carries a due date and, above all, financial add-ons the other two lack. Picking the wrong object costs one line of code up front, and makes reconciliation impossible later.

	Static QR code	cob (immediate)	cobv (with due date)
Founded	Outside the API: the BCB states that generating a static QR code is not part of the Pix API	`PUT /cob/{txid}`	`PUT /cobv/{txid}`
Transaction ID	EMV object `62-05`, up to 25 characters, or `***` by convention	`txid` of 26 to 35 strictly alphanumeric characters	`txid` of 26 to 35 characters, same constraints
Number of payments	Unlimited: the same QR code collects every time it is scanned	One	One
Amount	Optional; if omitted, the payer enters it	`valor.original`, never zero	`valor.original`, never zero
Deadline	None	None; only `calendario.expiracao`, in seconds	`calendario.dataDeVencimento` and `validadeAposVencimento`, in days
Multa, juros, desconto, abatimento	No	No	Yes, the only one of the three
Typical use	Fixed checkout counter, printed sign, tips, donations	E-commerce cart, payment at order time	Invoices, installments, rent: anything paid on a set date

Three collection objects, three different contracts

The cobv and its four add-ons, with their exact value ranges

Add-on	Area	Meaning
`multa`	1 or 2	1 = fixed amount, 2 = percentage. The `valorPerc` field is required and must match `\d{1,10}\.\d{2}`.
`juros`	1 to 8	1 = amount per calendar day, 2 = percentage per calendar day, 3 = per month, 4 = per year; 5 to 8 repeat the same series in business days.
`abatimento`	1 or 2	1 = fixed amount, 2 = percentage. An abatimento equal to or greater than the original amount gets the request rejected.
`desconto`	1 to 6	1 and 2 = discount until one or more fixed dates, with at most three `descontoDataFixa` entries; 3 to 6 = early-payment discount, as an amount or a percentage, per calendar day or business day.

`modalidade` value ranges in the `valor` object of a cobv (Pix API specification, Banco Central do Brasil)

A complete cobv: due date, validity after the due date, late fee, interest, early-payment discount

{
  "calendario": {
    "dataDeVencimento": "2026-09-10",
    "validadeAposVencimento": 30
  },
  "loc": { "id": 7891 },
  "devedor": { "cnpj": "12345678000195", "nome": "Empresa de Servicos SA" },
  "valor": {
    "original": "1250.00",
    "multa":      { "modalidade": 2, "valorPerc": "2.00" },
    "juros":      { "modalidade": 3, "valorPerc": "1.00" },
    "abatimento": { "modalidade": 1, "valorPerc": "50.00" },
    "desconto": {
      "modalidade": 1,
      "descontoDataFixa": [
        { "data": "2026-09-01", "valorPerc": "60.00" },
        { "data": "2026-09-08", "valorPerc": "25.00" }
      ]
    }
  },
  "chave": "7d9f0335-8dcc-4054-9bf9-0dbd61d36906"
}

The `loc` is typed. A location created for a cobv cannot carry a cob, and vice versa; the specification explicitly lists both violations. A location already used by another charge is rejected.
Discount dates must precede the due date. A descontoDataFixa entry later than dataDeVencimento gets the creation request rejected.
`validadeAposVencimento` is counted in days and cannot be negative. It keeps the charge payable past the due date, with the multa and juros applied.
`modalidadeAlteracao` is 0 or 1: it determines whether the payer may change the amount and, on a cobv, the due date. At 0, an amount changed in the payer's banking app is rejected.
Only an `ATIVA` charge can be modified. A request that tries to change a charge in any other status is rejected.

⚠️

Removing a charge is a standalone operation

Moving a charge to REMOVIDA_PELO_USUARIO_RECEBEDOR status cannot be combined with any other change in the same request. The specification treats that combination as a violation. Canceling an order therefore takes a dedicated PATCH, never an “update the amount and cancel while we're at it.” The revisao field, incremented with each accepted change, serves as the concurrency marker. Two processes modifying the same charge can detect each other through it.

🎯 Quick question

An invoice must remain payable for up to 30 days after its due date, with a 2% late fee and 1% monthly interest. Which object should you use?

Chapter 4. Pix Automático: wiring into a schedule you don't choose.

Recurring Pix does not work like a recurring card charge. The biller does not order a debit. It sends a payment instruction to the payer's PSP, which schedules and settles it on a calendar set by the rules. All times are Brasília time. The payee must be a legal entity with an active CNPJ; recurring payments are closed to individual payees and to non-periodic billing (FAQ Pix Automático, Banco Central do Brasil).

The lifecycle of a scheduled payment, from instruction to final retry

Payee's PSP

Sends the payment instruction

Between **10 and 2 days** before the scheduled settlement date. No earlier, no later: both limits are set by the rules.

Payer's PSP

Schedules the debit for the due date

The settlement date is the charge's due date, with no advance or delay.

Payer's PSP

First settlement window, midnight to 8 a.m.

May fail for insufficient funds or because the Pix Automático limit has been reached.

Payer's PSP

Notifies the payer at the end of the first window

The message prompts the payer to top up their balance or request a higher limit.

Payer's PSP

Second, mandatory window, 6 p.m. to 9 p.m.

This same-day retry is the payer's PSP's responsibility alone. The payee has nothing to trigger.

Payee's PSP

Post-due-date retries

Up to three new instructions over seven days, if the authorization provides for them. They can be sent until 11:59 p.m. on the day before the target settlement date.

The payee can cancel a charge up to the day before the scheduled settlement date. After that, cancellation is no longer possible, including during the post-due-date retry period.
A retry carries its own `txid`, distinct from that of the original attempt. Attempts appear in the tentativas object of the recurring charge (cobrança recorrente), each with its type (AGND for the scheduled payment, NTAG for a new attempt), its settlement date, its endToEndId, and its status.
Interest and late fees on a late payment are carried over to the next charge. They are not collected on the missed payment.
Canceling an authorization does not void that day's payment. Payments scheduled for the day of cancellation (and for the next day, if the cancellation comes after 10 p.m.) must be accepted.
Error code `UPAY` flags an undue payment: no valid recurrence existed at settlement time. It signals a mismatch between the authorization's status on the payer's side and the recurrence's status in your own system of record.

	Standard Pix limit	Pix Automático limit
Basis	Per period and per transaction, as configured by the participant	Daily, per transactional account
Relationship	–	Independent of the Pix limit: it neither merges with it nor stacks on top of it
Decrease request	Accepted immediately	Accepted immediately
Increase request	Response within 24 to 48 hours	Response within 8 hours at most
Reason for the difference	Protection against coercion and theft	Allowing settlement on the scheduled date, the same day

Two limit regimes, two clocks (Instrução Normativa BCB nº 512 of August 30, 2024)

🔑

Don't build your own same-day retry

A failure in the first window requires no action from the payee. The payer's PSP must retry between 6 p.m. and 9 p.m. the same day, after notifying its customer. A team that schedules its own retry at 9 a.m. gets nowhere: the instruction would fall outside the 10-to-2-day window, and that day's debit already belongs to the payer's PSP. What the biller does control is post-due-date retries, and only if the policy written into the authorization allows them.

You can read the recurrence ID without an API call. It is exactly 29 characters long: a two-letter prefix, the eight-digit ISPB (participant code) of the agent that created it, a yyyyMMdd date, then 11 alphanumeric characters unique for that day. The `RR` prefix marks a recurrence created in Pix that allows post-due-date retries; `RN` marks one that does not. A monitoring system that sorts subscriptions by this prefix knows, without a single query, which ones can be recovered after a failed payment.

🎯 Quick question

A scheduled Pix Automático payment fails at 3 a.m. for insufficient funds. What should the biller's team do that day?

Chapter 5. Devolução and the MED: refunding, contesting, and defending.

Three paths send money back on Pix, and only one belongs to the merchant. A commercial refund is initiated by the payee; the correction of an operational failure, by the payee's PSP. The MED is triggered by a payer who says they were defrauded, and it debits an account without the holder's consent. Mixing up the three leads teams to treat an infraction report like a card dispute, and to give the wrong answer.

	Refund by the payee (devolução)	Refund for operational failure (falha operacional)	MED (Recuperação de Valores)
Who decides	The payee, for any reason	The payee's PSP, at the request of the payer's PSP	The payer's PSP, on its customer's complaint
Settlement time	90 days from the original transaction	Depends on the failure case invoked	Original transaction no older than 80 days; 30 days when the dispute concerns a refund transaction
pacs.004 code	`MD06`	`BE08`	`FR01`
Partial	Yes, multiple times, up to the original amount	Yes, `partially_accepted`	Yes, up to the blocked balance
Payee consent	The payee orders it	Not required	Not required: the customer agreement provides for the block and the debit without prior authorization

The three return paths (Guia de implementação dos procedimentos de devolução no Pix, version 4.3, Banco Central do Brasil)

T+0

Recuperação de Valores (funds recovery) opens

The payer's PSP opens the case with CreateFundsRecovery without examining its merits or requiring a police report. The guide targets 30 minutes at most between the complaint and the opening, in 95% of cases.

Immediate

Block

The DICT notifies the PSPs of the payees identified through fund tracing (rastreamento). Each one immediately blocks the requested amount; if the balance is lower, it blocks everything, plus any credits that arrive afterward.

T+7 calendar days

Analysis

Each payee PSP closes its infraction report with AnalysisResult set to agreed or disagreed. A disagreed causes the DICT to cancel the downstream reports that are now disconnected from the root transaction.

Status: ANALYSED

72 hours

The payer's PSP has three days to initiate the return with RefundFundsRecovery.

6 hours

Execution

Each payee PSP returns the funds within six hours of the request in 99% of cases, as required by the Manual de Tempos do Pix. Requests move sequentially down the chain.

🔑

The good-faith third party defense (terceiro de boa-fé), written into the BCB guide

The text leaves no room for interpretation. Sellers acting in good faith cannot have their accounts debited because the MED exists in Pix. The guide adds that a return based on a well-founded suspicion of fraud is completely different from a chargeback in card schemes. Not recognizing a purchase is not enough; the seller must be shown to have committed the fraud. The MED does not cover commercial disputes (late delivery, a disappointing product, the wrong model), payments sent to the wrong recipient, duplicate Pix payments, or simple buyer's remorse. A merchant that delivered responds disagreed and documents the delivery in AnalysisDetails.

This protection has a limit, and the limit has moved. Version 4.1 of the guide, in force since February 2, 2026, extended the precautionary block (bloqueio cautelar) to legal entities. A merchant account can now be frozen as a precaution for up to 72 hours while its PSP conducts a deeper review. Platforms underestimate a second effect. An infraction report can target a payment intermediary, marketplaces included, even when the intermediary is not the final recipient. The receiving CNPJ accumulates the fraud reputation of its sellers.

`AnalysisResult`: agreed or disagreed. If it agrees, the PSP keeps the funds blocked; if it disagrees, it releases them.
`FraudType`, required whenever AnalysisResult is agreed: application_fraud (account opened with someone else's documents), mule_account (account opened legitimately, then lent out), scammer_account (account in the fraudster's own name), or other. The value other makes AnalysisDetails required.
An accepted report automatically generates a fraud marker against the payee of the transaction concerned. Canceling the report cancels the marker; reversing only your assessment requires CancelFraudMarker.
Grounds for rejecting a return request: no_balance (zero balance), account_closure (customer relationship ended), invalid_request (reserved for operational failure cases), other.
MED triggers on the payer side: account_takeover, fraudulent_access, scam, coercion. A payment authenticated by password or biometrics does not rule out any of them.

⚠️

The devolução ID is your idempotency key, and the rail puts you in charge of it

The refund call is PUT /pix/{e2eid}/devolucao/{id}, where {id} matches the pattern [a-zA-Z0-9]{1,35} and is generated by your system, not by the PSP. Replaying the same request with the same ID does not create a second refund. Derive the ID from your internal refund reference, never from a volatile counter. The transaction type matters too. An ordinary Pix is refunded under code MD06, while a Pix Saque or Pix Troco falls under the RETIRADA or TROCO types and may call for code SL02. The refund cap follows the type, not the total amount collected.

🎯 Quick question

A customer uses the MED to dispute a purchase that was delivered and signed for. Your PSP forwards you the infraction report. What is the compliant response?

Chapter 6. Webhooks and reconciliation: three feeds, one anchor.

The Pix API exposes three webhooks, not one, and each is subscribed to differently. The first tracks incoming Pix payments, key by key. The other two cover recurring payments: one tracks recurrences, the other recurring charges (cobranças recorrentes). An integration that registers only the first sees payments come in but knows nothing about the state of the subscriptions behind them.

Registration	URL called	Reach	OAuth 2 scopes
`PUT /webhook/{chave}`	`{webhookUrl}/pix`	Pix payments received on this key, and related refunds (devoluções). One subscription per key.	`webhook.write`, `webhook.read`
`PUT /webhookrec`	`{webhookUrl}/rec`	Lifecycle of Pix Automático recurrences	`webhookrec.write`, `webhookrec.read`
`PUT /webhookcobr`	`{webhookUrl}/cobr`	Recurring charges: attempts, statuses, closures	`webhookcobr.write`, `webhookcobr.read`

The three Pix API notification subscriptions

Scopes are granular and requested separately: cob.write / cob.read, cobv.write / cobv.read, lotecobv.write / lotecobv.read, cobr, rec, solicrec, pix.write / pix.read, plus the three webhook pairs.
A production token should carry only the scopes it uses. The service that creates charges has no need for pix.write, which controls refunds.
The notification channel is secured with mTLS. The merchant verifies the client certificate, and its rotation should be planned like that of an API secret.
The PSP may batch several Pix payments to the same key into a single call. The consumer therefore processes a list, never a single event, and stays idempotent on each item.

The reconciliation anchor is neither the amount nor the order reference but the `EndToEndId`. It is exactly 32 alphanumeric characters long and travels in pacs.002, pacs.004, and pacs.008 messages. It identifies one settlement, and only one, and it survives refunds, since the devolução is linked to it. The txid, by contrast, is 26 to 35 characters long and unique only per payee CPF or CNPJ, a rule the specification makes the receiving PSP responsible for enforcing.

Querying settled Pix payments in a time window, with the pagination envelope

GET /v2/pix?inicio=2026-09-01T00:00:00Z&fim=2026-09-01T23:59:59Z
          &cnpj=12345678000195
          &paginacao.paginaAtual=0&paginacao.itensPorPagina=100
Authorization: Bearer <pix.read token>

200 OK
{
  "parametros": {
    "inicio": "2026-09-01T00:00:00Z",
    "fim": "2026-09-01T23:59:59Z",
    "paginacao": {
      "paginaAtual": 0,
      "itensPorPagina": 100,
      "quantidadeDePaginas": 4,
      "quantidadeTotalDeItens": 337
    }
  },
  "pix": [
    {
      "endToEndId": "E1234567820260901103100000001234",
      "txid": "655dfdb1a4514b8fbb58254b958913fb",
      "valor": "110.00",
      "horario": "2026-09-01T10:31:00.412Z"
    }
  ]
}

⚠️

A static QR code breaks any txid-based reconciliation

A static QR code collects an unlimited number of payments, and its EMV 62-05 identifier stays the same on every scan. Two customers who pay the same amount from the same printed sign produce two indistinguishable lines if the matching key is the amount-plus-txid pair. The only key that holds up is the EndToEndId. Operationally, the static QR code works for anonymous collection but disqualifies itself as soon as an order has to be released automatically.

That leaves the design of the catch-up loop. The specification lets each PSP set its own service level for triggering callbacks, so a missing webhook is not a breach of contract. The source of truth is GET /pix, polled over overlapping sliding windows and deduplicated on the EndToEndId. Three logs are reconciled at the end of the day: charges issued, Pix payments settled, and refunds executed. The third is the one teams forget, and it explains the cash discrepancies.

🎯 Quick question

Which identifier should the matching key between a Pix payment and an accounting entry be built on?

Chapter 7. Night-time limits and fraud prevention: what the rail decides for you.

Pix limits are not a commercial setting left to the PSP. They are regulatory rules that cut off payments at hours the merchant does not choose. Instrução Normativa BCB nº 512 of August 30, 2024 sets the framework: the night-time period, the caps, and the lead times for changes. A team running a Brazilian checkout without this grid blames its own flow for drop-offs caused by the rail.

Parameter	Rule	Reference
Night-time period	Generally 8 p.m. to 6 a.m.; at the user's request, it can start at 10 p.m.	Art. 3º, § 3º and § 5º
Night-time cap	R$1,000 when the payee is an individual	Art. 3º, § 7º
Individuals and legal entities	The limits for the two categories are independent of each other	Art. 3º, § 11
Limit decrease	Applied immediately	Art. 11
Limit increase	Response within 24 to 48 hours	Art. 12, § 1º
Pix Automático limit increase	8 hours at most	Art. 12, § 2º
Contactless payment	R$500 per transaction; other limits still apply	Art. 16-A, § 1º

The limits framework (Instrução Normativa BCB nº 512 of August 30, 2024, Banco Central do Brasil)

🔑

The night-time cap targets individual payees, not merchants

Foreign teams misread this rule more often than any other. The R$1,000 cap between 8 p.m. and 6 a.m. applies when the payee is an individual; payments collected into a CNPJ fall outside it. The flows actually exposed are therefore payouts to individuals: marketplace payouts to individual sellers, winnings, outgoing refunds, and pay for freelancers. An outgoing payment run scheduled for 9 p.m. crashes into a cap on a flow where the merchant is not even the recipient. The fix is scheduling, not engineering: settle before 8 p.m.

ℹ️

This grid has an expiration date

Instrução Normativa BCB nº 746 of June 16, 2026 was published in the Diário Oficial da União, Brazil's official gazette, on June 17. It amends the provisions of IN BCB nº 512/2024 on value limits, in particular for contactless transactions and for payment initiation without redirection. It also lets users request increases and decreases to the daily Pix Automático limit. The Banco Central says it takes effect on October 1, 2026. Any hard-coded limits table must be reviewed on that date.

Pix fraud prevention: a shared reputation you can check before paying

The DICT does more than resolve keys. It keeps a history of infractions that participants can query, called Estatísticas. Two operations provide access: getEntryStatistics queries a key, and getPersonStatistics a CPF or CNPJ. Only the participant may initiate these queries. The manual prohibits exposing the feature to end users. The data lags by at most 12 hours, and the date of the most recent event appears in the watermark field.

Counter	What it measures
`Settlements`	Number of settlements received through the SPI for this key or holder
`ApplicationFrauds`	Confirmed fraud of the falsidade ideológica type: an account opened with someone else's documents
`MuleAccounts`	Confirmed fraud of the conta laranja (mule account) type: an account opened legitimately, then lent out
`ScammerAccounts`	Confirmed fraud where the account is in the fraudster's own name
`OtherFrauds` and `UnknownFrauds`	Confirmed fraud classified as “other,” and untyped reports that predate version 2 of the API
`TotalFraudTransactionAmount`	Cumulative amount of confirmed reports
`DistinctFraudReporters`	Number of distinct participants that have confirmed at least one report: the most discriminating signal
`OpenReports` and `OpenReportsDistinctReporters`	Reports still open at the time of the query, and the number of distinct reporters
`RejectedReports`	Rejected reports, including those with no fraud type
`RegisteredAccounts`	Accounts linked to the CPF or CNPJ; for a key, the number of distinct accounts it has been linked to

Counters returned by the DICT's Estatísticas (Manual Operacional do DICT v8.4)

Three time windows are returned: the last 90 days, the last 12 months, and the last 60 months, the latter two excluding the current month.
Querying a key returns two sets: one for the key and one for the CPF or CNPJ linked to it. A fraudster who switches keys does not switch holders.
Deleting a key erases nothing. The manual states that deletions, updates, portability, and claims neither remove nor invalidate infraction report data.
A re-registered key inherits the history whenever its key and user data are identical to those of the deleted key.
The transactional fraud marker (marcação de fraude transacional) exists outside the MED: a PSP can flag a customer as a fraudster via CreateFraudMarker, including for a Pix settled outside the SPI or rejected, and it can remove the flag whenever it chooses.

⚠️

This registry scores you too

A payment intermediary can receive an infraction report even when it is not the final recipient of the funds. The DICT manual explicitly names domestic and international marketplaces, collection agents, and intermediaries that receive funds into a pooled account (conta bolsão). Every report a PSP accepts against them feeds the DistinctFraudReporters counter of the platform's CNPJ. Lax seller onboarding is therefore paid for in collection reputation, measured by a metric every other participant can read before paying.

🎯 Quick question

A platform pays out its individual sellers' earnings by Pix every evening at 9 p.m. Transfers above R$1,000 fail. Why?

Pix in depth: integration and operations. 7 chapters and a final quiz.

Chapter 1. The DICT is a quota, not a phone book.

What the DICT will store, and how much