Its rules, by facet
28 Rules, each in its record's own words with its own status. A rule reached only through the authorisation says so; a rule that also applies to another transaction type names it.
Settlement 4
Pix Automatico: when a cycle's day does not exist in the month Corroborated (authoritative primary)
Where a cycle would start on a date the month does not have, such as the 30th in February, the cycle starts on the last date the month does have (the 28th, or the 29th in a leap year). The due date of that cycle's charge is a separate matter that the rulebook leaves to the contract between payer and business: it may fall on the 28th, on 1 March, or on any other day of that cycle, provided the planned settlement date does not run past the cycle's end. Pix Agendado has a different, fixed rule for the same problem.
Rests on rule. Confidence high. pix:rule.automatico-a-cycle-on-a-day-the-month-lacks
Pix Automatico: resending after an error in the settlement flow Corroborated (authoritative primary)
If a payment fails in the settlement flow after the payer's bank has sent it, that bank must tell the payee's bank at once, and the payee's bank must resend the instruction so the payer's bank can try again the same day. The resend must carry the same amount, is still checked against the authorisation, and is accepted only until 21:00 on the original settlement date. Where the failure was the payee's own bank rejecting the payment, resending is at that bank's discretion. This same day resend is the only case in which an instruction for the same charge may be sent on the settlement date itself.
Rests on rule. Confidence high. pix:rule.automatico-a-settlement-error-allows-a-same-day-resend
Pix Automatico: weekly, monthly, quarterly, half-yearly or yearly, and one charge per cycle Corroborated (authoritative primary)
The recurrence period of an authorisation is chosen from a closed list of five: weekly, monthly, quarterly, half-yearly and yearly. The messages carry them as WEEK, MNTH, QURT, MIAN and YEAR. Each period defines a cycle whose start and end follow from the period and the start date of the recurrence, and only one charge may be scheduled per cycle; a second one in the same cycle is refused unless it is a resend after a settlement error or a retry after the due date.
Rests on rule. Confidence high. pix:rule.automatico-five-recurrence-periods
Pix Automatico: the settlement date is the due date, and payments run on any day Corroborated (authoritative primary)
The settlement date in an instruction must be the charge's due date. If the due date is not a business day the business may choose to settle on the next business day instead; it is not obliged to, and payments may fall on any day, business day or not.
Rests on rule. Confidence high. pix:rule.automatico-settlement-date-is-the-due-date
Hours 4
Pix Automatico: a journey 1 request stays open for at most 30 days Corroborated (authoritative primary)
A request sent in journey 1 waits at the payer's bank until one of three things happens: the payer confirms or refuses it, the payee's bank withdraws it, or 30 days pass from the moment the payee's bank sent the permission details. The business may set a shorter life. Once it is withdrawn or has run out, the payer's bank must delete it. On the last day of a still pending request the payer's bank must warn the payer. A payer who refuses must say either that they do not recognise the business or that they do not want Pix Automatico for that payment, and those two answers travel back as pain.012 codes AP13 and AP14.
Rests on rule. Confidence high. pix:rule.automatico-a-pending-request-lapses-after-30-days
Pix Automatico: when a collection instruction may be sent Corroborated (authoritative primary)
The payee's bank sends each cycle's instruction, carrying the charge's details, as a rule between 10 and 2 calendar days before the planned settlement date. The payer's bank refuses an instruction that arrives more than 10 days ahead (pain.014 FCD1) or less than 2 days ahead (FCD2). Late is allowed only as an exception, where the business had trouble producing the instruction: there must still be 2 calendar days between scheduling and settlement, the settlement date must fall before the next cycle starts (or before the recurrence ends, for the last cycle), and the business may charge no late fees for the delay it caused. The payee's bank must send an instruction only if it matches the authorisation, never before the authorisation is confirmed, and must identify the business by its CNPJ as the Federal Revenue registers it.
Rests on rule. Confidence high. pix:rule.automatico-instructions-go-2-to-10-days-ahead
Pix Automatico: retries on later days, at most 3 within 7 days Corroborated (authoritative primary)
If the payment did not go on the settlement date for want of balance, limit or through an operational failure, the business may try again on later days, but only if the authorisation provides for it; the business picks the policy when it creates the recurrence, either no later retries or up to three. Each retry is a new instruction the payee's bank sends by 23:59 on the day before the retry date, for the same amount as the original, on no more than three different dates, within 7 calendar days of the original settlement date and never on or after the start of the next cycle (or the end of the recurrence, for the last one). On each retry date the payer's bank runs the same 00:00 to 08:00 and 18:00 to 21:00 attempts as on the original date. The payer's bank refuses a retry the recurrence does not allow (pain.014 IRNT), a fourth retry (QUNT) and one from the eighth day on (DTNT).
Rests on rule. Confidence high. pix:rule.automatico-retries-on-later-days
Pix Automatico: the settlement window on the day and the same day retry Corroborated (authoritative primary)
On the settlement date the payer's bank sends the payment for settlement between 00:00 and 08:00, provided the account holds enough money and the payer's Pix Automatico limit has room. If it cannot, for want of balance or of limit, or because of an operational failure, it must tell the payer the payment did not go and try at least once more between 18:00 and 21:00 the same day. It may try more often, but the last try must be by 21:00. If the last try fails the payer is told again, and told to pay by other means. The funds test is made on the day and not when the payment is scheduled, so a collection is never refused at scheduling for want of funds.
Rests on rule. Confidence high. pix:rule.automatico-settles-between-00-and-08-with-an-evening-retry
Limits 3
Pix Automatico: a pre-approved credit line may pay what the balance cannot Corroborated (authoritative primary)
A collection need not come only from the balance. Whether a pre-approved credit line, such as an overdraft, may cover a payment the available balance falls short of is one of the parameters of every authorisation, and it is the payer's call. Where the bank offers it, the setting starts switched on, and the payer may switch it off at any time, per authorisation. Nothing in the texts read changes the payment's character when credit funds it: it is still the same Pix Automatico.
Rests on rule. Confidence high. pix:rule.automatico-a-pre-approved-credit-line-may-fund-it
Pix Automatico: who fixes the ceiling on a variable authorisation Corroborated (authoritative primary)
On an authorisation whose amounts vary, the maximum per payment is the payer's to set, and it is optional: by default no maximum is set. The business may set a floor under that maximum, and the payer's bank must tell the payer what it is and accept no maximum below it. On an authorisation with a fixed amount there is no maximum to set; a charge for any other amount is refused. A charge above the payer's maximum is not scheduled, and the payer's bank must tell the payer so; it may add that raising the maximum and contacting the business could still save the payment in that cycle.
Rests on rule. Confidence high. pix:rule.automatico-the-payer-sets-the-maximum-the-business-sets-its-floor
The user can drive the limit in both directions Corroborated (authoritative primary)
Limit control has to live in the same app the customer pays from. It must let the customer move the general Pix limit and each product limit (contactless, Pix Automatico, Pix Agendado, and withdrawal and change), and register particular accounts or payees for a daily ceiling of their own. Both directions are required, and a customer who wants a limit of zero is entitled to it.
Rests on rule. Confidence high. Reached through the authorisation, not linked to the transaction type directly. pix:rule.limits-the-user-can-drive-the-limit-in-both-directions
Recall 3
Pix Automatico: calling off one scheduled payment Corroborated (authoritative primary)
A single scheduled collection can be stopped without touching the authorisation. The payer's bank must cancel it when its customer asks by 23:59 on the day before the settlement date, or when the payee's bank asks by 22:00 on that day before. After those cut-offs the payment runs. On the business's side a recurring charge can be cancelled only up to the day before its first settlement attempt; after that it can only expire. A business that needs to correct a charge cancels it and issues a new one with a new transaction identifier, inside the permitted scheduling window.
Rests on rule. Confidence high. pix:rule.automatico-cancelling-one-scheduled-payment
Pix Automatico: what a cancellation does to payments already scheduled Corroborated (authoritative primary)
Cancelling the authorisation takes every payment already scheduled under it with it, except the one due that same day. If the payer cancels, the bank drops every scheduled payment dated after the day of cancellation. If the business withdraws, the payer's bank drops every scheduled payment dated after the day it hears of it, and if that news arrives between 22:00 and 23:59 the payment due the next day survives too. The payer's app must say before the payer confirms that the cancellation is final and that only today's payment will still run, and when it is the business that cancelled, the bank must tell the payer which scheduled payments go and that no new ones will be scheduled.
Rests on rule. Confidence high. pix:rule.automatico-cancelling-the-authorisation-stops-what-is-scheduled
Pix Automatico: cancelling the authorisation, and the recorded reasons Corroborated (authoritative primary)
Either end user or either bank may cancel a recurrence on its own, and each bank must act on its customer's request and pass the cancellation to the other bank with a pain.011, answered by a pain.012. When the business asks for its permission to be withdrawn, the payer's bank must cancel the authorisation. The pain.011 carries who asked and one of eleven proprietary reasons, among them the payer's own request, the business's request, a closed account, a business that has shut down, the payer's death (DCSD), suspected fraud and a court order. A cancelled authorisation cannot be reinstated; a new one is needed.
Rests on rule. Confidence high. pix:rule.automatico-either-side-may-cancel-the-authorisation
Refund 1
Pix Automatico: the payer's bank refunds a faulty payment within 24 hours Corroborated (authoritative primary)
When a Pix Automatico payment should not have gone through, the MED ground that covers the payer's bank's own error, a missing authorisation or a departure from its terms, the payer's bank must return the whole amount to the payer from its own funds within 24 hours of the payer asking.
Rests on rule. Confidence high. pix:rule.automatico-a-faulty-payment-is-refunded-within-24-hours
Liability 2
Pix Automatico: the payer's bank schedules within two hours or refuses Corroborated (authoritative primary)
The payer's bank has two hours from receiving an instruction to schedule the payment it describes, and must refuse to schedule it instead where it does not fit the authorisation: an amount above the payer's maximum or different from a fixed amount, a date that does not fit the authorisation's date and period, a different business, a breach of the sending windows, no authorisation in force, or any other discrepancy that stands in the way. The refusal travels back on the pain.014. The business may then have its bank send a corrected instruction, up to 2 days before the planned settlement date.
Rests on rule. Confidence high. pix:rule.automatico-the-payers-bank-schedules-within-2-hours-or-refuses
Pix Automatico: the payer's bank pays first Corroborated (authoritative primary)
On this one product the paying bank absorbs the loss up front. It reimburses its own customer in full, from its own money, and then goes to the DICT to try to collect from the other side, where it gets paid only if the funds are still sitting there. The rulebook makes the point explicitly: choosing to offer Pix Automatico is accepting this, whatever the state of the receiving account.
Rests on rule. Confidence high. pix:rule.liability-pix-automatico-the-payers-bank-pays-first
Consumer law 2
Pix Automatico: the parameters every authorisation carries Corroborated (authoritative primary)
At the least, an authorisation names the business allowed to send instructions, states the recurrence period and the planned date of the first payment, says how long it lasts if it has an end date at all (an authorisation without one runs until cancelled), and records two choices of the payer's: whether to cap each payment at a maximum, and whether a pre-approved credit line may cover a payment the balance cannot. Before confirming, the payer's app must also show the payer and debtor, the object of the payment and its contract or customer reference, a fixed amount where there is one, and the business's retry policy for later days, with a warning that paying after the due date may bring interest and a fine on the next charge.
Rests on rule. Confidence high. pix:rule.automatico-what-an-authorisation-must-state
Pix Automatico: what the payer may change on a live authorisation Corroborated (authoritative primary)
The payer may cancel an authorisation at any time and may change it on their own where changes are allowed. What the payer's app must let them change is three settings per authorisation: the maximum per payment (on variable authorisations only), whether a pre-approved credit line may be used, and whether they are notified when a payment is scheduled. A new maximum applies to payments not yet scheduled and not to those already scheduled; if it falls below a payment already scheduled, the bank may offer to cancel that payment. The recurrence terms themselves, such as period, first date, amount and business, are not among the settings the payer can edit, and on the business's side a request already delivered cannot be corrected: a business that got something wrong cancels the recurrence and creates a new one.
Rests on rule. Confidence medium. pix:rule.automatico-what-the-payer-may-edit-and-when-it-bites
Messages 5
Pix Automatico: how the settlement message identifies it Corroborated (authoritative primary)
The pacs.008 for a Pix Automatico payment must carry AUTO in its initiation form field, including when a payment initiator produced the instruction. Where the instruction came from a payment initiator, the receiver's reconciliation identifier on the pacs.008 is left empty (before IN BCB n. 743/2026 it was filled with zeros where no pain.013 was used).
Rests on rule. Confidence medium. pix:rule.automatico-the-pacs008-is-marked-auto
Pix Automatico: the three places a collection can be refused, and who refuses Draft, unchecked
Refusals fall in three families, each on its own message with its own code list, and each code in the domain tables names the side that fills it. The authorisation is refused on the pain.012 (27 reasons in catalog 5.12.1): mostly by the payer's bank (account not found, closed or blocked, salary account, payer does not recognise the business or declines), some by the payee's bank (request expired, first payment not found in journey 3), and four by the SPI. The instruction is refused on the pain.014 (25 errors in 5.12.1): all but five by the payer's bank (amount over the maximum or not the fixed amount, wrong business or payer, bad date, too early or too late, no confirmed recurrence, retry rules broken), the other five by the SPI. The payment itself is refused on the pacs.002 like any Pix, where the receiving bank has UPAY for no valid recurrence and CN01 for one already cancelled. Each list has a catch-all to be used only when no specific code fits: GRER on pain.014, CH16 on pain.012, and OTHS for cancellations. A shortfall of balance or limit on the day is not a refusal code at all; it is a failed attempt the payer is notified of. From catalog 5.13.1, in production on 2026-10-25, the SPI-raised codes leave both lists (pain.012 goes to 23, pain.014 to 20).
Rests on rule. Confidence high. pix:rule.automatico-three-refusal-families-and-who-raises-them
Pix QR codes: static, dynamic and composite Corroborated (authoritative primary)
A static QR code carries everything inside the image: a DICT key, which is compulsory, and optionally a transaction identifier, free text, an amount and a withdrawal facilitator. A dynamic QR code carries the key and a URL at the payee's bank; the charge itself, with amount, identifier and the rest, is fetched from that URL when the code is read, so it can change over time and must be validated and queried after reading. A composite QR code adds a second URL pointing at Pix Automatico recurrence terms, with or without a static or dynamic charge alongside it. All three follow the BR Code layout, and a payer's app that cannot fetch the recurrence part must fall back to paying the rest as it would a plain code.
Rests on rule. Confidence high. Also applies to Pix Cobranca. pix:rule.cobranca-static-dynamic-and-composite-qr-codes
Pix Automatico: authorization messages Corroborated (authoritative primary)
Setting up a recurring authorization uses pain.009 to ask, pain.012 to answer and confirm, and pain.011 to cancel, with a pain.012 acknowledging the cancellation. All of them pass through the SPI, which relays between the two banks rather than acting on them.
Rests on rule. Confidence high. pix:rule.messages-pix-automatico-authorization-messages
Pix Automatico: instruction messages Corroborated (authoritative primary)
Once an authorization exists, the payee's bank sends payment instructions as pain.013 and the payer's bank acknowledges with pain.014. On the due date the payer's bank starts an ordinary scheduled payment. Cancelling an instruction or a charge before it settles is a camt.055 answered by a camt.029, and either side may send it.
Rests on rule. Confidence high. pix:rule.messages-pix-automatico-instruction-messages
Participants 3
Pix Automatico: one authorisation, then collections the payer's bank pushes Corroborated (authoritative primary)
Pix Automatico is a Pix the payer's own bank starts from the payer's account each time the payee's bank sends it a payment instruction. What makes that possible is a single authorisation the payer gives their own bank before the first instruction arrives; after that no instruction needs the payer to authenticate again. The authorisation is also the payer's permission for the payee to keep sending instructions, it must serve one stated purpose, and it may cover several products or services from the same payee as long as they are billed together. The payee's side may be the payee's own account provider or a participant offering payment initiation, in which case the authorisation doubles as the Open Finance consent. Every collection is still an instruction the payee's bank sends and the payer's bank acts on; the authorisation never produces a payment by itself.
Rests on rule. Confidence high. pix:rule.automatico-a-standing-authorisation-not-a-debit-pull
Pix Automatico: the four ways an authorisation is given Corroborated (authoritative primary)
There are four journeys, numbered 1 to 4 in the manuals and carried as AUT1 to AUT4 on the confirming pain.012. In journey 1 the payer agrees terms with the business directly, outside Pix, and the business's bank sends the request (a pain.009) to the payer's bank, where the payer confirms it under Pending authorisations. In journey 2 the payer scans a composite QR code that carries only the recurrence terms. In journey 3 the QR code carries the terms and an immediate first charge, and paying that charge and authorising happen together. In journey 4 the payer pays an ordinary charge by QR code and is then offered Pix Automatico for the payments after it. A fifth route runs under the Open Finance rules. Every account provider serving payers must support journeys 1 to 4 for all its payers, while a payee's bank chooses which of them it offers its business customers. The payer's bank must make the journey 4 offer even when the payer chose to schedule the charge rather than pay it at once.
Rests on rule. Confidence high. pix:rule.automatico-four-journeys-to-an-authorisation
Pix Automatico: every account provider offers it to payers, and only established businesses may collect Corroborated (authoritative primary)
Every participant that holds transactional accounts must offer Pix Automatico to its paying customers, though one serving business customers may ask the BCB to be excused for those customers, and the pain.012 code AP15 marks a request refused on that ground. Offering it to businesses that want to collect is optional, and only a legal person may collect: its CNPJ must have been active for at least six months and it must show no sign of fraud under the bank's own criteria, which must use the DICT's security data where the bank has access to it. The bank must vet the business before it signs up and for as long as the contract runs, weighing at least its registration data, its size and activity, the fit between its business and what it collects for, the DICT data, and its history with the bank. The business talks to its bank through the API Pix or a standardised file, and a salary account cannot be the paying account (pain.012 SA01).
Rests on rule. Confidence high. pix:rule.automatico-who-may-offer-and-who-may-collect
No facet on the record 1
Pix Automatico: in journey 3 the first payment is a condition of the authorisation Corroborated (authoritative primary)
Only journey 3 ties the authorisation to a payment. There the payer confirms an immediate first payment and the authorisation in one step, the app must show that the first payment settling is a condition of the authorisation, and if that payment does not go through for any reason the authorisation is not concluded and the payer must be told at once. The payee's bank refuses such an authorisation with pain.012 code AP08 when it cannot find the first payment. If the payment settles and the authorisation still fails, the payer gets the receipt and is told to contact the business to arrange later payments. In journeys 1, 2 and 4 the authorisation is given before any collection and no first payment activates it.
Rests on rule. Confidence high. pix:rule.automatico-journey-3-needs-the-first-payment-to-settle