Pix Automático Operations: Mandates, Retries, Refunds, Reconciliation

Pix Automático has been live since 16 June 2025. Most published material still explains what it is: a pull-debit layer on Brazil's instant rail, cheap relative to cards, reaching consumers who never had a credit card. That framing is correct and, fourteen months in, no longer the useful part.

The useful part is how it behaves when a collection fails, when a payer disputes, and when you have to reconcile a month of mandates against a month of settlements. Those mechanics are specified in detail — the Banco Central do Brasil publishes a 51-page implementation guide, currently at v1.3 dated 19 August 2026 — and they contain at least three decisions an operator makes once, at integration time, that cannot be undone afterwards.

This is the operational reference. For how Pix Automático compares against card-on-file, SEPA Direct Debit, UPI AutoPay and eGIRO as a rail choice, see subscription rails compared. For Pix itself, see the Brazil Pix operator guide.

Every mandate is two objects, not one

This is the model that makes the rest coherent, and it is the thing summaries flatten.

A Pix Automático mandate exists as two linked records held by two different institutions:

• recorrência — created by the receiver's PSP. It carries the commercial terms: who is collecting, fixed or variable amount, frequency, and the retry policy.
• autorização — granted by the payer to the payer's own PSP. It exists only while a confirmed recorrência backs it.

They move through their own statuses. The API exposes the recurrence as CRIADA → ENVIADA → RECEBIDA → then APROVADA, REJEITADA or CANCELADA. The messaging layer uses a different status vocabulary from the API by design — the BCB's guide footnotes this explicitly, and an integration that assumes one set of names applies everywhere will misread its own webhooks.

The operational consequence: cancelling either object cancels the other. Both the payer and the receiver can cancel unilaterally. There is no state in which a receiver holds a live mandate that the payer's institution does not also recognise, which is a meaningful difference from card-on-file, where a merchant can hold a token the issuer will decline indefinitely without telling the merchant why.

Four authorisation journeys, and they run in parallel

The scheme defines four payer-side journeys (jornadas), and a receiver may operate more than one concurrently:

1. No QR — the recurrence is pushed and the payer approves via a notification in their banking app.
2. QR for the recurrence only — the payer scans, and authorises the mandate without paying anything at that moment.
3. QR with an immediate first payment — mandate plus first collection in one action.
4. QR after a payment offer — the mandate is established following a completed payment.

For a subscription business the third is usually what you want at checkout, because it collapses activation and first billing. For a utility or insurer migrating an existing book off boleto, the first is usually what you want, because there is no checkout moment to attach to.

Scheduling: the 2-to-10-day window

A collection must be scheduled no fewer than 2 and no more than 10 days before the due date. Miss the window in either direction and the scheduling message is rejected.

Only one instruction per cycle is permitted. An attempt to schedule a second collection for the same cycle is rejected, which forecloses the card-world habit of splitting a failed charge into smaller partial attempts.

Amounts: a floor the receiver sets, a ceiling the payer sets

A recurrence is either fixed-value or variable-value. For variable amounts:

• the receiver may set a minimum (piso)
• the payer sets a maximum (valor máximo), which cannot be set below the receiver's floor

The ceiling is checked at scheduling time, not at settlement. A payer who lowers their ceiling after a collection has already been scheduled does not retroactively kill that collection. This is a small rule with a real reconciliation consequence: a debit can legitimately settle at an amount above the payer's current ceiling, and that is not a defect.

Retries: two obligations, and only one is optional

This is the single most important operational rule, and the one most likely to be got wrong.

There are two entirely separate retry mechanisms, governed by different rules.

Insufficient funds or breached limit

The first collection attempt runs in the 00:00–08:00 window.

If it fails because the payer lacks funds or has breached a limit:

1. The payer is notified at 08:00.
2. The payer's PSP must make at least one further attempt between 18:00 and 21:00 the same day. This obligation is unconditional — it does not depend on the recurrence's retry policy. The guide leaves the number to the PSP's discretion — it may make as many attempts as it wishes across the course of the day, and requires only that the last one falls between 18:00 and 21:00.
3. Only if the receiver set politicaRetentativa to PERMITE_3R_7D on the recurrence may attempts continue on later dates — at most three different dates, within seven calendar days counted from the settlement date in the original payment instruction, not from the date of failure. The alternative value is NAO_PERMITE, under which nothing runs after 21:00 on the due date and the payer must settle by other means.

Each post-due-date attempt is for the same amount and is issued as a fresh pain.013 carrying finalidadeDoAgendamento = NTAG. The payer cannot cancel a collection scheduled as an NTAG retry.

Do not add these into a single number. The guide never totals them, the two mechanisms are defined separately in its own terminology section, and the evening window's internal attempts are explicitly uncounted. Published summaries that quote a tidy ceiling have performed that addition themselves, and at least one source consulted while researching this article did exactly that — asserting a ceiling that its own described sequence did not add up to.

What is a one-way decision is the flag. politicaRetentativa is fixed when the recurrence is created; it is not a per-collection choice and not something a dunning system can escalate to on the day. A merchant that ships with the wrong default has no recovery path on any mandate already created under it — those recurrences have to be recreated, which means re-obtaining payer authorisation.

Operational failure after the instruction was sent

If the instruction was already sent and something downstream failed — the SPI or the receiver's PSP being unavailable — a different mechanism applies. The instruction can be cancelled with a camt.055 carrying reason FAIL and resent as a new pain.013 with finalidadeDoAgendamento = RIFL and a fresh end-to-end identifier. Resends of this kind run until 21:00 and are not limited by the recurrence's retry-policy flag.

So "how many retries do I get?" has two answers depending on why the collection failed, and only one of them is capped by the flag you set months earlier.

Cancellation: two clocks

• Payer may cancel until 23:59 on the day before settlement.
• Receiver must have its cancellation reach the payer's PSP by 22:00 on the day before.

The receiver's deadline is the earlier of the two. A merchant that processes end-of-day cancellations in a nightly batch after 22:00 will find some cancellations land a day late and a debit settles that should not have.

Rejections and the codes you will see

pain.014 rejections are triggered by, among others:

• amount above the payer's ceiling, or not matching the fixed value
• a date outside the 2-to-10-day window
• more than one instruction in a cycle
• receiver mismatch — the guide documents error AB10 as an interim workaround here
• no active authorisation

Payer-side recurrence rejections carry human reasons rather than codes: the payer does not recognise the receiver, or has no interest in Pix Automático with that receiver. Cancellations via camt.055 carry reason CCLD.

At the API layer, PSP documentation shows the ordinary HTTP shape — 400 for an invalid operation, 403 for access denied, 404 for not found, 503 for service unavailable. These are documented by PSPs rather than in the BCB guide, so confirm the exact set against your own provider.

Refunds: MED has two tracks and they are not the same

Brazil's MED (Mecanismo Especial de Devolução) is widely described as the fraud-reversal mechanism for Pix. For Pix Automático it carries two distinct tracks, and conflating them is the misconception most likely to produce a wrong operational model.

Track one — fraud. Identical to any other Pix transaction. Pix Automático changes nothing here.

Track two — a Pix Automático refund category. This covers an authorisation mismatch, a debit taken with no active authorisation, or an operational error by the payer's own PSP. None of these is fraud. On this track the payer's PSP must refund the payer in full, from its own funds, within 24 hours of the request, and only afterwards seek reimbursement (ressarcimento) from the receiver's PSP.

Both tracks surface to the consumer through the same self-service screens in their banking app, which is exactly why they get conflated. Analytically they are different: one is a fraud claim against a transaction, the other is a claim that the mandate did not authorise the debit — and on the second, the payer is made whole first and the institutions settle afterwards.

An operator modelling Pix Automático disputes as if they were card chargebacks will misjudge both the timing and the order in which parties are out of pocket.

Notifications: mostly not optional

The payer must be notified:

• immediately when a collection is scheduled
• when it settles
• at 08:00 when it fails for insufficient funds
• before the 18:00–21:00 retry
• on final failure

Only the scheduling-success notification can be switched off by the user. Failure, cancellation-by-receiver and pending-authorisation notifications are mandatory and stay on.

This is a materially different environment from card recurring billing, where the merchant largely controls customer communication. In Pix Automático the payer's bank is talking to your customer about your failed collection, at 08:00, before your dunning email goes out. Sequence your own messaging accordingly.

Reconciliation: two layers and a structured identifier

Ordinary Pix gives you endToEndId and txid. Pix Automático adds idRec, a 29-character structured recurrence identifier that encodes real information rather than being opaque: whether the recurrence was created inside the Pix arrangement or through Open Finance, whether retries are permitted, the creating institution, the creation date, and a sequence number.

That structure is useful — you can tell from the identifier alone whether a mandate permits retries, without joining back to your own recurrence table.

The message set:

Settlement runs on what the BCB calls the secondary channel, in the 00:00–08:00 window.

Reconciliation therefore has two layers that must be reconciled separately: the mandate estate (how many live recurrences, in what state) and the collection ledger (what settled, what failed, what retried). A single flat transaction report will not tell you that 400 mandates silently moved to CANCELADA last month.

Open Finance is the exception, not the rule

PaymentBrief's own glossary previously said Pix Automático consent is established through the Open Finance infrastructure and that integration uses the Open Finance Brasil APIs. That is wrong as a general statement, and it is a common enough error to be worth correcting explicitly.

The BCB's implementation guide states that models where the service is provided to the receiver by a payment initiator follow specifications defined within Open Finance, and that its own treatment of them is not exhaustive — it carries a dedicated section on payment-initiator considerations but directs readers to the Open Finance specifications for the rest. The default mechanism — covering all four authorisation journeys above — runs directly between the payer's PSP and the receiver's PSP, entirely inside the Pix arrangement.

Open Finance enters only where the receiver has separately contracted a payment initiator (PSI) to run the relationship. Open Finance Brasil's own developer documentation confirms this by scoping its guide specifically to Pix Automático via Open Finance — one route among several.

For an operator scoping an integration, the practical consequence is direct: you do not need an Open Finance consent journey to accept Pix Automático unless you have deliberately chosen the initiator model. Budgeting for one because a summary said consent runs on Open Finance is budgeting for the exception.

Who has to support it

Payer side: mandatory. Every Pix participant offering transactional accounts must support Pix Automático as a payer-side capability, and must implement all four authorisation journeys. Institutions providing only corporate accounts may request an opt-out from the BCB.

Receiver side: optional. Whether a PSP lets merchants collect through Pix Automático is its own commercial decision, and it may support some journeys and not others.

The asymmetry is the thing to plan around. Payer reach is effectively universal, so the constraint on your rollout is not consumer availability — it is which journeys your chosen collecting PSP has actually built.

Where adoption actually is

Honest caveat first: the BCB's statistics pages sit behind a JavaScript shell that does not return content to ordinary retrieval, so the figures below are industry-reported and were not confirmed against a BCB primary page. That is a limitation of what could be retrieved, not a statement that the BCB has not published data.

On that basis: a Brazilian processor reported Pix Automático volume growing 182% between Q4 2025 and Q1 2026. Absolute monthly transaction counts circulate in Brazilian trade press but differ between outlets and could not be tied to a source that actually carries them, so none is quoted here.

Read that the way you would read any early-rail number. A large percentage increase on a small base is still a small base. Fourteen months in, Pix Automático is real, specified in depth, and mandatory on the payer side — but the public evidence does not show it carrying volume comparable to Pix as a whole. An operator's decision to integrate should rest on the cost and reach case, not on an assumption that the volume is already there.

The regulatory stack, briefly

Pix Automático sits on Resolução BCB nº 1 (the Pix regulation, as amended), with Resolução BCB nº 402/2024 establishing its operating rules and nº 403/2024 amending security mechanisms. The operational layer runs through Instruções Normativas — IN BCB 513 carries the operational procedures, amended by IN BCB 614 (May 2025, effective at launch) and again by IN BCB 743 (June 2026). IN BCB 511, amended by IN BCB 613, governs participation and opt-out.

The user-experience layer is specified separately in the BCB's minimum user-experience requirements, now at v7.1 — which is worth knowing exists, because it constrains what the payer's app must show and therefore what your customer sees when your collection fails.

What to take from this

Three decisions are made once and are expensive to reverse:

1. politicaRetentativa at recurrence creation decides whether you get any post-due-date retries at all, for the life of the mandate. Default it wrong and fixing it means re-authorising customers.
2. Which authorisation journeys your collecting PSP supports determines whether you can activate at checkout or only by push.
3. Whether you build on the direct Pix path or the Open Finance initiator path — the first is the default and the simpler integration; the second is a deliberate choice, not a requirement.

Everything else — windows, deadlines, notification timing, the two MED tracks — is behaviour you design your dunning and support around rather than choose.