1 • Manual of Flows of the Pix Execution Process Internal Manual of Flows of the Pix Execution Process Version 2.1 Access version 2.2 here, effective from 01/02/2027

2 • Manual of Flows of the Pix Execution Process Internal
Table of Contents

INTRODUCTION..............................................................................................................................................4
PAYMENT ORDER GENERATION FLOWS BY THE PAYING USER...........................................5
2.1. PAYMENT ORDER GENERATION BY MANUAL DATA ENTRY OR VIA PIX KEY........................5
2.1.1. Payer’s PSP with direct access to the Directory of Transactional Account Identifiers (DICT)
2.1.2. Payer’s PSP with indirect access to DICT............................................................................ 7
2.1.3. Payment Transaction Initiation Service Provider, with direct access to DICT........ 9
2.2. PAYMENT ORDER GENERATION VIA STATIC QR CODE.........................................................................11
2.3. PAYMENT ORDER GENERATION VIA DYNAMIC QR CODE .......................................................................13
2.3.1. Pix Invoice for immediate payment................................................................................. 13
2.3.2. Pix Invoice for payment with due date ..................................................................... 15
2.4. PAYMENT ORDER GENERATION FOR A SINGLE OR RECURRING SCHEDULED PIX BY MANUAL DATA ENTRY OR VIA PIX KEY ..................................................................................................................................18
2.4.1. Payer’s PSP with direct access to DICT ............................................................................ 18
2.4.2. Payer’s PSP with indirect access to DICT.......................................................................... 20
2.5. PAYMENT ORDER GENERATION VIA PAYMENT TRANSACTION INITIATION SERVICE, IN CASES WHERE THE PARTICIPANT HAS ALL THE INFORMATION OF THE RECEIVING USER .........................................................................23
2.6. PAYMENT ORDER GENERATION VIA INITIATION BY PROXIMITY OF A DEVICE ENABLED WITH NEAR FIELD COMMUNICATION (NFC) TECHNOLOGY TO ANOTHER DEVICE WITH THE SAME TECHNOLOGY .....................................24
2.6.1. Transaction initiated by the payer’s PSP ................................................................................ 24
2.6.2 Transaction initiated by the payment transaction initiation service provider........... 26
PIX EXECUTION FLOW .................................................................................................................29
3.1. TRANSACTION FLOWS BETWEEN DIRECT PARTICIPANTS ...................................................................................29
3.1.1. Flow with immediate settlement of the payment order ........................................................ 30
3.1.2. Flow with scheduled settlement of the payment order (Scheduled Pix, Recurring Scheduled Pix and Pix Invoice with due date)............................................................................................ 32
3.2. TRANSACTION FLOWS BETWEEN INDIRECT PARTICIPANTS .................................................................................34
3.2.1. Flow with immediate settlement of the payment order ........................................................ 35
3.2.2. Flow with scheduled settlement of the payment order (Scheduled Pix, Recurring Scheduled Pix and Pix Invoice with due date)............................................................................................ 38
3.3. TRANSACTION FLOWS IN THE PSP’S LEDGERS.................................................................................................41
3.3.1. Flow with immediate settlement of the payment order ........................................................ 42
3.3.2. Flow with scheduled settlement of the payment order (Scheduled Pix, Recurring Scheduled Pix and Pix Invoice with due date)............................................................................................ 43
3.4. TRANSACTION FLOWS BETWEEN INDIRECT PARTICIPANTS WITH THE SAME CLEARING HOUSE ...............................................45
3.4.1. Flow with immediate settlement of the payment order ........................................................ 46
3.4.2. Flow with scheduled settlement of the payment order (Scheduled Pix and Recurring Scheduled Pix and Pix Invoice with due date)............................................................................................ 48
PIX RETURN FLOW .................................................................................................................50
4.1. RETURN FLOW BETWEEN DIRECT PARTICIPANTS ....................................................................................51
4.2. RETURN FLOW BETWEEN INDIRECT PARTICIPANTS..................................................................................54
AUTOMATIC PIX FLOWS..................................................................................................................57
5.1. AUTHORIZATION FLOWS ........................................................................................................................57

3 • Manual of Flows of the Pix Execution Process Internal
5.1.1. Journey 1 – Paying user chooses Automatic Pix as a payment method (interaction external to the ecosystem) ......................................................................................................................... 57
5.1.2. Journey 2 – Paying user enrolls via the payer’s PSP (reading of QR Code containing recurrence data) ......................................................................................................... 63
5.1.3. Journey 3 – Paying user enrolls by reading QR Code with first immediate payment .............................................................................................................................. 68
5.1.4. Journey 4 – User pays via QR Code and receives proposal to enable Automatic Pix for future recurring invoice payments .............................................................. 76
5.1.5. Cancellation of authorization by the paying user .............................................................. 84
5.1.6. Cancellation of recurrence by the receiving user............................................................. 87
5.2. DEBIT SCHEDULING FLOWS........................................................................................................90
5.2.1. Scheduling of the debit......................................................................................................... 90
5.2.2. New intraday attempts due to error in the settlement flow ....................................................... 93
5.2.3. Cancellation by the paying user of a scheduled debit................................................. 96
5.2.4. Cancellation by the receiving user of a scheduled debit .............................................. 99

4 • Manual of Flows of the Pix Execution Process Internal

Introduction
The Pix execution process consists of 3 types of flows, which will be described in the specific sections of this Manual:

Section 2: payment order generation flows, which corresponds to the procedures executed, from the start of the transaction by the paying user, by the payer’s payment service provider (PSP) to identify the receiving user;
Section 3: Pix execution flows, initiated by the payer’s payment service provider (PSP), after the generation of the payment order by the paying user;
Section 4: transaction return flows, where the receiving PSP (or sender) operationalizes the return of values, based on a request from the payer’s PSP (or recipient), or on its own initiative.
Section 5 consists of the flows that describe the processes related to Automatic Pix:
Authorization flows: from which the paying user allows the sending of recurring charges by the receiving user and authorizes payments by its payment service provider (PSP). The flows for cancellation of authorization by the paying user and cancellation of permission, on the initiative of the receiving user, are also described;
Debit scheduling flows: description of how payment instructions must be sent by the receiving user, as agreed in the authorization. Additionally, the processes for cancellation of a scheduled debit by the paying user or by the receiving user are described.

5 • Manual of Flows of the Pix Execution Process Internal
2. Payment order generation flows by the paying user
2.1. Payment order generation by manual data entry or via Pix key
2.1.1. Payer’s PSP with direct access to the Directory of Transactional Account Identifiers (DICT)

Layer Type Description

1 Paying user Action
Start of the process. Paying user accesses payment channel (app or internet banking) to perform a payment transaction and enters the data necessary to perform the payment (Pix key or bank data of the recipient). 2 Paying user Communication Data entered by the paying user is forwarded to the payer’s PSP. 3 Payer’s PSP Communication Payer’s PSP receives the payment data informed by the paying user. 4 Payer’s PSP Decision If the paying user has informed the recipient’s Pix key in step 1, the flow proceeds to step 5. If the paying user has entered the recipient’s bank data, consultation of the DICT for validation of these information is not necessary, and one should proceed directly to step 10. 5 Payer’s PSP Communication Payer’s PSP sends message to DICT to consult the identification information of the receiving user based on the key informed by the paying user. 6 DICT Communication DICT receives the query for data about the receiving user. 7 DICT Action DICT consults the received key, performs validation and returns the found identification data. 8 DICT Communication DICT sends communication to the payer’s PSP with the identification data of the receiving user. 9 Payer’s PSP Communication Payer’s PSP receives communication from DICT with the identification data of the receiving user. 10 Payer’s PSP Action Payer’s PSP validates the data of the receiving user entered manually. 11 Payer’s PSP Communication Payer’s PSP sends communication to the paying user with the data of the receiving user, requesting confirmation. 12 Paying user Communication Paying user receives communication with data about the receiving user, requesting confirmation to start the payment execution process. 13 Paying user Action Paying user checks the data of the receiving user and confirms the transaction, generating the payment order. End of process.

7 • Manual of Flows of the Pix Execution Process Internal
2.1.2. Payer’s PSP with indirect access to DICT

Layer Type Description

8 • Manual of Flows of the Pix Execution Process Internal 4 Payer’s PSP Decision If the paying user has informed the recipient’s Pix key in step 1, the flow proceeds to step 5. If the paying user has entered the recipient’s bank data, consultation of the DICT for validation of these information is not necessary, and one should proceed directly to step 14. 5 Payer’s PSP Communication Payer’s PSP communicates with the participant with direct access to DICT to consult the identification information of the receiving user. Participant with direct access to DICT Communication Participant with direct access to DICT receives the payment data forwarded by the payer’s PSP. Participant with direct access to DICT Communication Participant with direct access communicates with DICT to consult the identification information of the receiving user. 8 DICT Communication DICT receives the query for data about the receiving user. 9 DICT Action DICT consults the received key, performs validation and returns the found identification data. 10 DICT Communication DICT sends communication to the participant with direct access to DICT, informing the identification data of the receiving user. Participant with direct access to DICT Communication Participant with direct access to DICT receives communication with the identification data of the receiving user. Participant with direct access to DICT Communication Participant with direct access to DICT communicates with the payer’s PSP, informing the data of the receiving user. 13 Payer’s PSP Communication Payer’s PSP receives communication from the participant with direct access to DICT with the identification data of the receiving user. 14 Payer’s PSP Action Payer’s PSP validates the data of the receiving user entered manually. 15 Payer’s PSP Communication Payer’s PSP sends communication to the paying user with the data of the receiving user, requesting confirmation. 16 Paying user Communication Paying user receives communication with the data of the receiving user, requesting confirmation to start the payment execution process. 17 Paying user Action Paying user checks the data of the receiving user and confirms the transaction, generating the payment order. End of process.

9 • Manual of Flows of the Pix Execution Process Internal
2.1.3. Payment Transaction Initiation Service Provider, with direct access to DICT

Layer Type Description

1 Paying user Action
Start of the process. Paying user accesses PSI channel to perform a payment transaction and enters the data necessary to perform the payment. 2 Paying user Communication Data entered by the paying user is forwarded to the PSI. 3 PSI Communication PSI receives the payment data entered by the paying user.

10 • Manual of Flows of the Pix Execution Process Internal 4 PSI Decision If the paying user has informed the recipient’s Pix key in step 1, the flow proceeds to step 5. If the paying user has entered the recipient’s bank data, consultation of the DICT for validation of these information by the PSI is not necessary, and one should proceed directly to step 10. 5 PSI Communication PSI sends message to DICT to consult the identification information of the receiving user based on the key informed by the paying user. 6 DICT Communication DICT receives query for data about receiving user. 7 DICT Action DICT consults the received key, performs validation and returns the found identification data. 8 DICT Communication DICT sends communication to PSI with the identification data of the receiving user. 9 PSI Communication PSI receives communication from DICT with the identification data of the receiving user. 10 PSI Action PSI validates the data of the receiving user entered manually. 11 PSI Communication PSI sends communication to the paying user with the data of the receiving user, requesting consent to start the transaction. 12 Paying user Communication Paying user receives consent request with the receiving user’s information. 13 Paying user Action Paying user checks the data and gives consent for the transaction to be initiated by the PSI. 14 Paying user Communication Paying user sends consent for the transaction to be initiated. 15 PSI Communication PSI receives consent from the paying user for the transaction to be initiated. 16 PSI Communication PSI sends transaction data to the payer’s PSP, via the Open Finance API. 17 Payer’s PSP Communication Payer’s PSP receives the transaction data. 18 Payer’s PSP Communication Payer’s PSP sends communication to the paying user with the data of the receiving user, requesting authentication and confirmation for the payment. 19 Paying user Communication Paying user receives communication with the data of the receiving user, requesting authentication and confirmation to start the payment execution process. 20 Paying user Action Paying user checks the received information and confirms the transaction, generating the payment order. End of process

11 • Manual of Flows of the Pix Execution Process Internal
2.2. Payment order generation via static QR Code

Layer Type Description

1 Paying user Action
Start of the process. Paying user reads the QR Code or enters the “Pix Copy and Paste” provided by the receiving user, in the payer’s PSP app. 2 Paying user Communication Data read from QR Code or entered via “Pix Copy and Paste” is forwarded to the payer’s PSP. 3 Payer’s PSP Communication Payer’s PSP receives data from QR Code or “Pix Copy and Paste”. 4 Payer’s PSP Action Payer’s PSP interprets the QR Code or “Pix Copy and Paste”. 5 Payer’s PSP Communication Payer’s PSP sends message to DICT to consult the identification information of the receiving user, according to information contained in the QR Code or “Pix Copy and Paste”. 6 DICT Communication DICT receives the query for data about the receiving user. 7 DICT Action DICT consults the received data, performs validation and returns the found identification data. 8 DICT Communication DICT sends communication to the payer’s PSP with the identification data of the receiving user. 9 Payer’s PSP Communication Payer’s PSP receives communication from DICT with the identification data of the receiving user.

12 • Manual of Flows of the Pix Execution Process Internal 10 Payer’s PSP Communication Payer’s PSP sends communication to the paying user with the data of the receiving user, requesting confirmation to execute the payment order. 11 Paying user Communication Paying user receives communication with data about the receiving user, requesting confirmation to start the payment execution process 12 Paying user Action Paying user checks the received information and confirms the transaction, generating the payment order. End of process. End of process. If the payer’s PSP has indirect access to DICT, the flow follows the same logic as the flow described in section 2.1.2, with respect to the actions taken by the PSP with direct access and its communication with the DICT.

13 • Manual of Flows of the Pix Execution Process Internal
2.3. Payment order generation via dynamic QR Code
2.3.1. Pix Invoice for immediate payment

Layer Type Description

14 • Manual of Flows of the Pix Execution Process Internal 5 Payer’s PSP Communication Payer’s PSP sends location query to the recipient’s PSP. 6 Recipient’s PSP Communication Recipient’s PSP receives the query request sent by the payer’s PSP. 7 Recipient’s PSP Action Recipient’s PSP loads the invoice data into the payload. 8 Recipient’s PSP Communication Recipient’s PSP transmits the payload with the invoice data to the payer’s PSP. 9 Payer’s PSP Communication Payer’s PSP receives the payload with the invoice data. 10 Payer’s PSP Communication Payer’s PSP sends message to DICT to consult the identification information of the receiving user, according to information contained in the QR Code or in the “Pix Copy and Paste”. 11 DICT Communication DICT receives the query for data about the receiving user. 12 DICT Action DICT consults the received data, performs validation and returns the found identification data. 13 DICT Communication DICT sends communication to the payer’s PSP with the identification data of the receiving user. 14 Payer’s PSP Communication Payer’s PSP receives communication from DICT with the identification data of the receiving user. 15 Payer’s PSP Communication Payer’s PSP sends communication to the paying user with the data of the receiving user and the payload, requesting confirmation to execute the payment order. 16 Paying user Communication Paying user receives communication with data of the receiving user and the payload, requesting confirmation to execute the payment. 17 Paying user Action Paying user checks the received information and confirms the transaction, generating the payment order. End of process. If the payer’s PSP has indirect access to DICT, the flow follows the same logic as the flow described in section 2.1.2, with respect to the actions taken by the PSP with direct access and its communication with the DICT.

15 • Manual of Flows of the Pix Execution Process Internal
2.3.2. Pix Invoice for payment with due date

Layer Type Description

16 • Manual of Flows for the Pix Execution Process Internal

4 Payer's PSP Action The payer's PSP interprets the QR Code or "Pix Copy and Paste" and identifies the location contained within it. 5 Payer's PSP Communication The payer's PSP sends a location query to the payee's PSP. 6 Payee's PSP Communication The payee's PSP receives the query request sent by the payer's PSP. 7 Payee's PSP Action The payee's PSP loads the billing data into the payload. 8 Payee's PSP Communication The payee's PSP transmits the payload with the billing data to the payer's PSP. 9 Payer's PSP Communication The payer's PSP receives the payload with the billing data. 10 Payer's PSP Communication The payer's PSP forwards a query regarding the data of the payee's Pix key to the DICT, according to the information contained in the QR Code. 11 DICT Communication The DICT receives the query for data about the payee user. 12 DICT Action The DICT consults the received data, performs validation, and returns the identification data found. 13 DICT Communication The DICT sends communication to the payer's PSP with the identification data of the payee user. 14 Payer's PSP Communication The payer's PSP receives communication from the DICT with the identification data of the payee user. 15 Payer's PSP Communication The payer's PSP sends communication to the payer user with the data of the payee user and the payload, requesting confirmation to execute the payment order. 16 Payer User Communication The payer user receives communication with the payee user's data, the billing amount, and the suggested payment date, requesting confirmation to execute the payment. 17 Payer User Decision If the payer user chooses not to alter the suggested payment date and this date is equal to the "current date", the flow proceeds to step 28. If the payer user decides to alter the suggested payment date and insert a desired payment date (DPP), the flow proceeds to step 18. 18 Payer User Action The payer user inserts the desired payment date (DPP) into the payer's PSP app. 19 Payer User Communication The payer user sends a request to the payer's PSP to change the suggested payment date to the DPP. 20 Payer's PSP Communication The payer's PSP receives the query with the DPP informed by the payer user. 21 Payer's PSP Communication The payer's PSP sends the payment data request with the DPP to the payee's PSP. 22 Payee's PSP Communication The payee's PSP receives the request for billing data for the informed DPP.

17 • Manual of Flows for the Pix Execution Process Internal

23 Payee's PSP Action The payee's PSP loads the billing data and the discount, interest, and/or penalty calculations based on the DPP informed into the payload. 24 Payee's PSP Communication The payee's PSP sends the payload with the billing data for the informed DPP to the payer's PSP. 25 Payer's PSP Communication The payer's PSP receives the payload with the billing data for the informed DPP. 26 Payer's PSP Communication The payer's PSP sends the payload with the billing data for the informed DPP to the payer user, requesting confirmation to execute the payment. 27 Payer User Communication The payer user receives, in the payer's PSP app, the billing information, starting from the informed DPP: payee user, the payment date, and the amount to be paid, with information about principal, penalty, interest, discounts, and/or abatements. 28 Payer User Action The payer user checks the received information and confirms the transaction, generating the payment order. End of process. If the payer's PSP has indirect access to the DICT, the flow follows the same logic as the flow described in section 2.1.2, with regard to the actions taken by the PSP with direct access and its communication with the DICT.

18 • Manual of Flows for the Pix Execution Process Internal

2.4. Generation of the payment order for a Scheduled Pix, single or recurring, by manual data entry or by means of a Pix key
2.4.1. Payer's PSP with direct access to the DICT

Layer	Type	Description
1	Payer User Action	Start of the process. Payer user accesses payment channel (app or internet banking) to perform a payment transaction and inserts the data necessary to perform the payment (Pix key or bank data of the payee). The scheduling date can be requested at this stage, or alternatively, it can be requested at step 12, already with the availability of the payee user's data and before confirming the transaction.
2	Payer User Communication	Data inserted by the payer user is forwarded to the payer's PSP.
3	Payer's PSP Communication	The payer's PSP receives the payment data informed by the payer user.
4	Payer's PSP Decision	If the payer user has informed the payee's Pix key at step 1, the flow proceeds to step 5. If the payer user has inserted the payee's bank data, the query to the DICT for validation of this information is not necessary, and one should proceed directly to step 10.

19 • Manual of Flows for the Pix Execution Process Internal

5 Payer's PSP Communication If the payer user has inserted a Pix key, the payer's PSP sends a message to the DICT to query the identification information of the payee user. The EndToEndId generated at this stage is used only for the query to the DICT. 6 DICT Communication The DICT receives the query for data about the payee user. 7 DICT Action The DICT consults the received key, performs validation, and returns the identification data found. 8 DICT Communication The DICT sends communication to the payer's PSP with the identification data of the payee user. 9 Payer's PSP Communication The payer's PSP receives communication from the DICT with the identification data of the payee user. 10 Payer's PSP Action The payer's PSP validates the data of the payee user informed by manual entry. 11 Payer's PSP Communication The payer's PSP sends communication to the payer user with the data of the payee user, requesting confirmation. 12 Payer User Communication The payer user receives communication with data about the payee user, requesting confirmation to start the payment execution process. If the scheduling date was not requested at step 1, it must be requested at this stage, before confirming the transaction. 13 Payer User Action The payer user checks the payee user's information and confirms the transaction, generating the payment order. End of process.

20 • Manual of Flows for the Pix Execution Process Internal

2.4.2. Payer's PSP with indirect access to the DICT

21 • Manual of Flows for the Pix Execution Process Internal

Layer	Type	Description
1	Payer User Action	Start of the process. Payer user accesses payment channel (app or internet banking) to perform a payment transaction and inserts the data necessary to perform the payment (Pix key or bank data of the payee). The scheduling date can be requested at this stage, or alternatively, it can be requested at step 16, already with the availability of the payee user's data and before confirming the transaction.
2	Payer User Communication	Data inserted by the payer user is forwarded to the payer's PSP.
3	Payer's PSP Communication	The payer's PSP receives the payment data informed by the payer user.
4	Payer's PSP Decision	If the payer user has informed the payee's Pix key at step 1, the flow proceeds to step 5. If the payer user has inserted the payee's bank data, the query to the DICT for validation of this information is not necessary, and one should proceed directly to step 14.
5	Payer's PSP Communication	The payer's PSP communicates with the participant with direct access to the DICT to query the identification information of the payee user.
Direct Access Participant to DICT	Communication	The participant with direct access to the DICT receives the payment data forwarded by the payer's PSP.
Direct Access Participant to DICT	Communication	The participant with direct access communicates with the DICT to query the identification information of the payee user. The EndToEndId generated at this stage is used only for the query to the DICT.
8	DICT Communication	The DICT receives the query for data about the payee user.
9	DICT Action	The DICT consults the received key, performs validation, and returns the identification data found.
10	DICT Communication	The DICT sends communication to the participant with direct access, informing the identification data of the payee user.
Direct Access Participant to DICT	Communication	The participant with direct access to the DICT receives communication with the identification data of the payee user.

22 • Manual of Flows for the Pix Execution Process Internal

Direct Access Participant to DICT	Communication	The participant with direct access to the DICT communicates with the payer's PSP, informing the data of the payee user.
13	Payer's PSP Communication	The payer's PSP receives communication from the participant with direct access with the identification data of the payee user.
14	Payer's PSP Action	The payer's PSP validates the data of the payee user informed by manual entry.
15	Payer's PSP Communication	The payer's PSP sends communication to the payer user with the data of the payee user, requesting confirmation.
16	Payer User Communication	The payer user receives communication with data about the payee user, requesting confirmation to start the payment execution process. If the scheduling date was not requested at step 1, it must be requested at this stage, before confirming the transaction.
17	Payer User Action	The payer user checks the payee user's information and confirms the transaction, generating the payment order. End of process.

23 • Manual of Flows for the Pix Execution Process Internal

2.5. Generation of the payment order by the payment transaction initiation service, in cases where the participant has all the information of the payee user

Layer	Type	Description
1	PSI Action	Start of the process. PSI generates the information for the billing with the payee's data.
2	PSI Communication	PSI sends the payment data to the payer user.
3	Payer User Communication	The payer user receives the payment data.
4	Payer User Action	Checks the data and gives consent for the transaction to be initiated by the PSI.
5	Payer User Communication	The payer user sends the consent to the PSI so that the transaction is initiated.
6	PSI Communication	PSI receives consent from the payer user.
7	PSI Communication	PSI sends the transaction data to the payer's PSP, via the Open Finance API.
8	Payer's PSP Communication	The payer's PSP receives the transaction data.
9	Payer's PSP Communication	The payer's PSP sends communication to the payer user with the data of the payee user, requesting authentication and confirmation.

24 • Manual of Flows for the Pix Execution Process Internal

10 Payer User Communication The payer user receives communication with data about the payee user, requesting authentication and confirmation to start the payment execution process. 11 Payer User Action The payer user checks the payee user's information and confirms the transaction, generating a payment order. The flows of payment transaction initiation journeys are detailed in the Open Finance regulatory framework.

2.6. Generation of the payment order by initiation via proximity of a device enabled with Near Field Communication (NFC) technology to another device with the same technology
2.6.1. Transaction initiated by the payer's PSP

25 • Manual of Flows for the Pix Execution Process Internal

Layer	Type	Description
1	Payer User Action	Start of the process. Payer user obtains payment data by bringing a device close to a compatible terminal, using NFC technology.
2	Payer User Communication	The payment data is forwarded to the payer's PSP.
3	Payer's PSP Communication	The payer's PSP receives the payment data.
4	Payer's PSP Action	The payer's PSP interprets the payment data and identifies the location contained within them.
5	Payer's PSP Communication	The payer's PSP sends a location query to the payee's PSP.

26 • Manual of Flows for the Pix Execution Process Internal

6 Payee's PSP Communication The payee's PSP receives the query request sent by the payer's PSP.
7 Payee's PSP Action The payee's PSP loads the billing data into the payload.
8 Payee's PSP Communication The payee's PSP transmits the payload with the billing data to the payer's PSP.
9 Payer's PSP Communication The payer's PSP receives the payload with the billing data.
10 Payer's PSP Communication The payer's PSP sends a message to the DICT to query the identification information of the payee user, according to the information contained in the payment data. 11 DICT Communication The DICT receives the query for data about the payee user. 12 DICT Action The DICT consults the received data, performs validation, and returns the identification data found. 13 DICT Communication The DICT sends communication to the payer's PSP with the identification data of the payee user. 14 Payer's PSP Communication The payer's PSP receives communication from the DICT with the identification data of the payee user. 15 Payer's PSP Communication The payer's PSP sends communication to the payer user with the data of the payee user and the payload, requesting confirmation to execute the payment order. 16 Payer User Communication The payer user receives communication with the data of the payee user and the payload, requesting confirmation to execute the payment. 17 Payer User Action The payer user checks the received information and confirms the transaction, generating the payment order. End of process. The flowchart of this subsection reflects the payment process associated with an immediate dynamic QR Code, which is the most common model in retail. However, the process can also be carried out using billing associated with a dynamic QR Code with maturity or a static QR Code. If the payer's PSP has indirect access to the DICT, the flow follows the same logic as the flow described in section 2.1.2, with regard to the actions taken by the PSP with direct access and its communication with the DICT.

2.6.2 Transaction initiated by the payment transaction initiation service provider

27 • Manual of Flows for the Pix Execution Process Internal

Layer	Type	Description
1	Payer User Action	Start of the process. Payer user obtains payment data by bringing a device close to a compatible terminal, using NFC technology.
2	Payer User Communication	The payment data is forwarded to the PSI.
3	PSI Communication	PSI receives the payment data.
4	PSI Action	PSI interprets the payment data and identifies the location contained within them.
5	PSI Communication	PSI sends a location query to the payee's PSP.

28 • Manual of Flows for the Pix Execution Process Internal

6 Payee's PSP Communication The payee's PSP receives the query request sent by the PSI.
7 Payee's PSP Action The payee's PSP loads the billing data into the payload.
8 Payee's PSP Communication The payee's PSP transmits the payload with the billing data to the PSI.
9 PSI Communication PSI receives the payload with the billing data.
10 PSI Communication PSI sends a message to the DICT to query the identification information of the payee user, according to the information contained in the payment data. 11 DICT Communication The DICT receives the query for data about the payee user. 12 DICT Action The DICT consults the received data, performs validation, and returns the identification data found. 13 DICT Communication The DICT sends communication to the PSI with the identification data of the payee user. 14 PSI Communication PSI receives communication from the DICT with the identification data of the payee user. 15 PSI Communication PSI sends communication to the payer user with the data of the payee user and the payload, requesting confirmation to execute the payment order. 16 Payer User Communication The payer user receives communication with the data of the payee user and the payload, requesting confirmation to execute the payment. 17 Payer User Action The payer user checks the received information and confirms the transaction, generating the payment order. End of process. The flowchart of this subsection reflects the payment process associated with an immediate dynamic QR Code, which is the most common model in retail. However, the process can also be carried out using billing associated with a dynamic QR Code with maturity or a static QR Code. The flows of payment transaction initiation journeys involving a PSI are detailed in the Open Finance regulatory framework. To send the payment order to the payer's PSP, the PSI must use the Open Finance APIs.

29 • Manual of Flows for the Pix Execution Process Internal

Pix Execution Flow
3.1. Flow of transactions between direct participants
This section presents the flow of orders sent to the primary message transmission channel or to the secondary message transmission channel of the Instant Payment System (SPI), in accordance with the SFN Service Catalog and the Communication Interfaces Manual, in the case where both the payment service provider (PSP) of the payer and the payee are direct participants of the SPI. Payment orders regarding Automatic Pix, Scheduled Pix, Recurring Scheduled Pix, and Billing Pix for payments with maturity, when scheduled, must be sent to the secondary message transmission channel. These orders correspond to pacs.008 messages filled with "NORM" in the "prioridadePagamento" field and with "PAGAGD" in the "tipoPrioridadePagamento" field, as well as all messages of their settlement cycle (the other pacs.008 and pacs.002 related to a payment order initiated in the secondary message transmission channel, as well as any admi.002 messages derived from these pacs.008 and pacs.002) 1. The flows regarding the scheduling of the payment instruction and the settlement of Automatic Pix also travel through the secondary message channel. All other payment orders must be sent to the primary message transmission channel. The table after the flow details each step of the process. More detailed information regarding messages is available in the SFN Service Catalog, available at https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados.

30 • Manual of Flows for the Pix Execution Process Internal

3.1.1. Flow with immediate settlement of the payment order

31 • Manual of Flows for the Pix Execution Process Internal

Layer	Type	Description
1	Payer's PSP Communication	Start of the process. Payer's PSP receives the payment order.
2	Payer's PSP Action	The payer's PSP blocks the payment value in the payer user's account.
3	Payer's PSP Message	The payer's PSP sends a message to the SPI, requesting the transfer of resources from the PI account in the amount of the payment in question to proceed with the payment.
4	SPI Message	The SPI receives the message sent by the payer's PSP, requesting the transfer of resources in the PI Account to proceed with the payment.
5	SPI Action	The SPI executes the block in the payer's PSP's PI Account in the amount of the payment in question.
6	SPI Message	The SPI sends a message to the payee's PSP, informing the data for the transfer.
7	Payee's PSP Message	The payee's PSP receives the message with the transfer data.
8	Payee's PSP Action	The payee's PSP validates the payee user's account and makes a provisional credit entry in this account.
9	Payee's PSP Message	The payee's PSP sends a message to the SPI, requesting the continuation of the payment.
10	SPI Message	The SPI receives the message sent by the payee's PSP, requesting the continuation of the payment.
11	SPI Action	The SPI executes the transfer of resources in the PI accounts: decreases the balance of the payer's PSP's PI Account by the value of the payment in question, and increases the balance of the payee's PSP's PI Account by the same amount.
12	SPI Message	The SPI sends a message confirming the completion of the transaction to the payee's PSP.
13	Payee's PSP Message	The payee's PSP receives the message confirming the completion of the transaction.
14	Payee's PSP Action	The payee's PSP executes the credit in the payee user's account, in the value of the transaction.
15	Payee's PSP Communication	The payee's PSP sends communication confirming the completion of the transaction to the payee user.
16	Payee User Communication	The payee user receives communication, informing the completion of the transaction.
17	SPI Message	The SPI sends a message confirming the completion of the transaction to the payer's PSP.

32 • Manual of Flows for the Pix Execution Process Internal

18 Payer's PSP Message The payer's PSP receives the message confirming the completion of the transaction.
19 Payer's PSP Action The payer's PSP executes the debit in the payer user's account, in the value of the transaction.
20 Payer's PSP Communication The payer's PSP sends communication confirming the completion of the transaction to the payer user. 21 Payer User Communication The payer user receives the communication, informing the completion of the transaction. End of process.

3.1.2. Flow with scheduled settlement of the payment order (Scheduled Pix, Recurring Scheduled Pix, and Billing Pix with maturity)

Layer	Type	Description
1	Payer's PSP Communication	Start of the process. If the payer user has informed a Pix key at the time of scheduling the transaction, the payer's PSP forwards, previously to the date scheduled for the

33 • Manual de Flows of the Pix Settlement Process Internal settlement, message to DICT for new query of the payer's user identification information. The EndToEndId of the transaction generated in this step must be informed in the PACS.008 so that there is replenishment of tokens in bucket 2.

2 DICT Communication
DICT receives query of data about the payee user.

3 DICT Action
DICT queries the received key, performs validation and returns the identification data found.

4 DICT Communication
DICT sends communication to the payer's PSP with the identification data of the payee user.

5 Payer's PSP Communication
Payer's PSP receives communication from DICT with the identification data of the payee user.

6 Payer's PSP Decision
Payer's PSP verifies the existence of the informed Pix key and whether the ownership of the account linked to it remains the same as the query performed at the time of scheduling. If the result is positive, the flow proceeds to step 7. If the Pix key is verified as non-existent, or the ownership is different from that obtained in the query to DICT performed at the time of scheduling, the flow proceeds to step 8.

7 Payer's PSP Action
Payer's PSP executes the settlement of the payment order, according to the flows described in sections 3.1.1, 3.2.1, 3.3.1 and 3.4.1, depending on the condition of the PSPs involved. End of process.

8 Payer's PSP Action
Payer's PSP cancels the scheduled payment order in its internal systems.

9 Payer's PSP Communication
Payer's PSP sends notification of failure in the settlement of the scheduled payment order to the payer user.

10 Payer User Communication
Payer user receives notification of failure in the settlement of the scheduled payment order, sent by the payer PSP. End of process.

If the payer user has inserted the payee user's banking data at the time of scheduling the transaction, the new query to DICT is not necessary, and one should skip directly to step 7 and proceed with the payment, according to the flow described in section 3.1.1 of this Manual. Information related to the mechanisms adopted for prevention of reading attacks on DICT can be found in more detail in section 13 of the DICT Operational Manual.

34 • Manual of Flows of the Pix Settlement Process Internal

3.2. Flow of transactions between indirect participants
This section presents the flows of orders sent to the primary message transmission channel or to the secondary message transmission channel of the SPI, in accordance with the SFN Service Catalog and the Communication Interfaces Manual, in the case where both the payer's PSP and the payee's PSP are indirect participants of the SPI.

Payment orders related to Scheduled Pix, Recurring Scheduled Pix and Pix Collection for payments with maturity, when scheduled, must be sent to the secondary message transmission channel. These orders correspond to pacs.008 messages filled with “NORM” in the “prioridadePagamento” field and with “PAGAGD” in the “tipoPrioridadePagamento” field, as well as all messages of their settlement cycle (the other pacs.008 and pacs.002 related to a payment order initiated in the secondary message transmission channel, as well as any admi.002 messages derived from these pacs.008 and pacs.002) 3.

The flows related to the scheduling of the payment instruction and settlement of Automatic Pix also travel on the secondary message channel. All other payment orders must be sent to the primary message transmission channel. The table after the flow details each step of the process. More detailed information regarding messages is available in the SFN Service Catalog, available at https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados.

35 • Manual of Flows of the Pix Settlement Process Internal

3.2.1. Flow with immediate settlement of the payment order

36 • Manual of Flows of the Pix Settlement Process Internal

Layer Type Description

1 Payer's PSP Communication Start of process. Payer's PSP receives payment order.
2 Payer's PSP Action Payer's PSP blocks the payment value in the payer user's account.
3 Payer's PSP Communication Payer's PSP sends communication to its clearing agent, requesting transfer of funds from the PI account in the amount of the payment in question to proceed with the payment. Clearing Agent of Payer's PSP Communication Clearing Agent of Payer's PSP receives communication, requesting transfer of funds in the PI Account to proceed with the payment. Clearing Agent of Payer's PSP Message Clearing Agent of Payer's PSP sends message to SPI, requesting transfer of funds in the PI Account to proceed with the payment. 6 SPI Message SPI receives message sent by the clearing agent of the payer's PSP, requesting transfer of funds in the PI Account to proceed with the payment. 7 SPI Action SPI executes the block in the PI Account of the clearing agent of the payer's PSP in the amount of the payment in question. 8 SPI Message SPI sends message to the clearing agent of the payee's PSP, informing the transfer data. Clearing Agent of Payee's PSP Message Clearing Agent of Payee's PSP receives message with the transfer data. Clearing Agent of Payee's PSP Communication Clearing Agent of Payee's PSP sends communication to the payee's PSP with the transfer data. 11 Payee's PSP Communication Payee's PSP receives communication with the transfer data. 12 Payee's PSP Action Payee's PSP validates the payee user's account and makes a provisional credit entry in this account. 13 Payee's PSP Communication Payee's PSP sends communication to its clearing agent, requesting the continuation of the payment. Clearing Agent of Payee's PSP Communication Clearing Agent of Payee's PSP receives communication sent by the payee's PSP, requesting the continuation of the payment. Clearing Agent of Payee's PSP Message Clearing Agent of Payee's PSP sends message to SPI, requesting the continuation of the payment. 16 SPI Message SPI receives message sent by the clearing agent of the payee's PSP, requesting the continuation of the payment.

37 • Manual of Flows of the Pix Settlement Process Internal

17 SPI Action SPI executes the balance exchange in the PI accounts: decreases the balance of the PI Account of the clearing agent of the payer's PSP by the value of the payment in question and increases the balance of the PI Account of the clearing agent of the payee's PSP by the same amount. 18 SPI Message SPI sends confirmation of transaction completion to the clearing agent of the payee's PSP. 19 Clearing Agent of Payee's PSP Message Clearing Agent of Payee's PSP receives message of confirmation of transaction completion sent by SPI. Clearing Agent of Payee's PSP Communication Clearing Agent of Payee's PSP sends communication of confirmation of transaction completion to the payee's PSP. 21 Payee's PSP Communication Payee's PSP receives communication of confirmation of transaction completion. 22 Payee's PSP Action Payee's PSP executes the credit in the payee user's account, in the value of the transaction. 23 Payee's PSP Communication Payee's PSP sends communication of confirmation of transaction completion to the payee user. 24 Payee User Communication Payee user receives the communication informing the completion of the transaction. End of process. 25 SPI Message SPI sends confirmation of transaction completion to the clearing agent of the payer's PSP. Clearing Agent of Payer's PSP Message Clearing Agent of Payer's PSP receives message of confirmation of transaction completion sent by SPI. Clearing Agent of Payer's PSP Communication Clearing Agent of Payer's PSP sends communication of confirmation of transaction completion to the payer's PSP. 28 Payer's PSP Communication Payer's PSP receives communication of confirmation of transaction completion. 29 Payer's PSP Action Payer's PSP executes the debit in the payer user's account in the value of the transaction. 30 Payer's PSP Communication Payer's PSP sends communication of confirmation of transaction completion to the payer user. 31 Payer User Communication Payer user receives the communication, informing the completion of the transaction.

38 • Manual of Flows of the Pix Settlement Process Internal

3.2.2. Flow with scheduled settlement of the payment order (Scheduled Pix, Recurring Scheduled Pix and Pix Collection with maturity)

Layer Type Description

1 Payer's PSP Communication Start of process. If the payer user has informed a Pix key at the time of scheduling the transaction, the payer's PSP sends, previously to the date scheduled for settlement, a message to the participant with direct access to DICT for a new query of the identification information of the payee user.

39 • Manual of Flows of the Pix Settlement Process Internal Participant with direct access to DICT Communication The participant with direct access to DICT receives the payment data forwarded by the payer's PSP. Participant with direct access to DICT Communication Participant with direct access communicates with DICT to query the identification information of the payee user. The EndToEndId of the transaction generated in this step must be informed in the PACS.008 so that there is replenishment of tokens in bucket 4.

4 DICT Communication DICT receives query of data about payee user.

5 DICT Action DICT queries the received key, performs validation and returns the identification data found.

6 DICT Communication DICT sends communication to the participant with direct access, informing the identification data of the payee user. Participant with direct access to DICT Communication Participant with direct access to DICT receives communication with the identification data of the payee user. Participant with direct access to DICT Communication Participant with direct access to DICT communicates with the payer's PSP, informing the payee user data.

9 Payer's PSP Communication Payer's PSP receives communication from the participant with direct access with the identification data of the payee user.

10 Payer's PSP Decision Payer's PSP verifies the existence of the informed Pix key and whether the ownership of the account linked to it remains the same as the query performed at the time of scheduling. If the result is positive, the flow proceeds to step 11. If the Pix key is verified as non-existent, or the ownership is different from that obtained in the query to DICT performed at the time of scheduling, the flow proceeds to step 12.

11 Payer's PSP Action Payer's PSP executes the settlement of the payment order, according to the flows described in sections 3.1.1, 3.2.1, 3.3.1 and Information related to the mechanisms adopted for prevention of reading attacks on DICT can be found in more detail in section 13 of the DICT Operational Manual.

40 • Manual of Flows of the Pix Settlement Process Internal

3.4.1, depending on the condition of the PSPs involved. End of process.

12 Payer's PSP Action Payer's PSP cancels the scheduled payment order in its internal systems.

13 Payer's PSP Communication Payer's PSP sends notification of failure in the settlement of the scheduled payment order to the payer user.

14 Payer User Communication Payer user receives notification of failure in the settlement of the scheduled payment order, sent by the payer PSP. End of process.

If the payer user has inserted the payee user's banking data at the time of scheduling the transaction, the new query to DICT is not necessary, and one should skip directly to step 11 and proceed with the payment, according to the flow described in section 3.2.1 of this Manual.

41 • Manual of Flows of the Pix Settlement Process Internal

3.3. Flow of transactions in the PSP's books
This section presents the flows of orders sent for settlement, in the case where the payer's PSP and the payee's PSP are the same institution, regardless of whether the PSP is a direct or indirect participant of the SPI. The table after the flow details each step of the process.

42 • Manual of Flows of the Pix Settlement Process Internal

3.3.1. Flow with immediate settlement of the payment order

Layer Type Description

1 PSP Communication Start of process. PSP receives payment order.
2 PSP Action PSP verifies if there is balance in the payer user's account and validates the payee user's account.
3 PSP Action If the balance and account checks are positive, PSP debits the payer user's account and credits the payee user's account, executing the transaction in its books. 4 PSP Communication PSP sends notification of confirmation of transaction completion to the payee user. 5 Payee User Communication Payee user receives the notification, informing the completion of the transaction. 6 PSP Communication PSP sends notification of confirmation of transaction completion to the payer user. 7 Payer User Communication Payer user receives the communication informing the completion of the transaction.

43 • Manual of Flows of the Pix Settlement Process Internal

3.3.2. Flow with scheduled settlement of the payment order (Scheduled Pix, Recurring Scheduled Pix and Pix Collection with maturity)

Layer Type Description

1 PSP Action Start of process. If the payer user has informed a Pix key at the time of scheduling the transaction, on the date scheduled for settlement, the PSP verifies if there is balance in the payer user's account and validates the payee user's account. 2 PSP Decision PSP verifies if the Pix key informed at the time of scheduling remains registered in the institution. If the result is positive, flow proceeds to step 8. If there was portability or reclamation of the Pix key and it is no longer registered in the PSP, flow proceeds to step 3.

44 • Manual of Flows of the Pix Settlement Process Internal

3 PSP Communication PSP communicates with DICT to query the identification information of the payee user.

4 DICT Communication DICT receives query of data about payee user.

5 DICT Action DICT queries the received key, performs validation and returns the identification data found.

6 DICT Communication DICT sends communication to the PSP, informing the identification data of the payee user.

7 PSP Communication PSP receives communication with the identification data of the payee user.

8 PSP Decision PSP verifies the existence of the informed Pix key and whether the ownership of the account linked to it remains the same as the query performed at the time of scheduling. If the result is positive, flow proceeds to step 9. If the ownership is different from that obtained in the query to DICT performed at the time of scheduling, flow proceeds to step 10.

9 PSP Action Payer's PSP executes the settlement of the payment order, according to the flows described in sections 3.1.1, 3.2.1, 3.3.1 and 3.4.1, depending on the condition of the PSPs involved. End of process.

10 PSP Action PSP cancels the scheduled payment order in its internal systems.

11 PSP Communication Payer's PSP sends notification of failure in the settlement of the scheduled payment order to the payer user.

12 Payer User Communication Payer user receives notification of failure in the settlement of the scheduled payment order, sent by the payer PSP. End of process.

45 • Manual of Flows of the Pix Settlement Process Internal

3.4. Flow of transactions between indirect participants with the same clearing agent
This section presents the flow of orders sent for settlement, in the case where the payer's PSP and the payee's PSP are indirect participants of the SPI and maintain a relationship with the same clearing agent. The table after the flow details each step of the process.

46 • Manual of Flows of the Pix Settlement Process Internal

3.4.1. Flow with immediate settlement of the payment order

Layer Type Description

47 • Manual of Flows of the Pix Settlement Process Internal

4 Clearing Agent Communication Clearing Agent receives request for balance exchange in the PI Account, sent by the payer's PSP, to proceed with the payment.

5 Clearing Agent Communication Clearing Agent, upon identifying that it is also the clearing agent of the payee's PSP, sends communication to the payee's PSP informing the transfer data.

6 Payee's PSP Communication Payee's PSP receives communication with the transfer data.

7 Payee's PSP Action Payee's PSP validates the payee user's account and makes a provisional credit entry in this account.

8 Payee's PSP Communication Payee's PSP sends communication to the clearing agent, requesting the continuation of the payment.

9 Clearing Agent Communication Clearing Agent receives communication sent by the payee's PSP, requesting the continuation of the payment.

10 Clearing Agent Action Clearing Agent executes adjustment in internal balance control: decreases the balance of the internal account of the payer's PSP by the value of the payment in question, and increases the balance of the internal account of the payee's PSP by the same amount.

11 Clearing Agent Communication Clearing Agent sends confirmation of transaction completion to the payee's PSP.

12 Payee's PSP Communication Payee's PSP receives communication of confirmation of transaction completion.

13 Payee's PSP Action Payee's PSP executes the credit in the payee user's account.

14 Payee's PSP Communication Payee's PSP sends communication of confirmation of transaction completion to the payee user.

15 Payee User Communication Payee user receives the communication informing the completion of the transaction.

16 Clearing Agent Communication Clearing Agent sends confirmation of transaction completion to the payer's PSP.

17 Payer's PSP Communication Payer's PSP receives communication of confirmation of transaction completion.

18 Payer's PSP Action Payer's PSP executes the debit in the payer user's account in the value of the transaction.

19 Payer's PSP Communication Payer's PSP sends communication of confirmation of transaction completion to the payer user.

20 Payer User Communication Payer user receives the communication, informing the completion of the transaction.

48 • Manual of Flows of the Pix Settlement Process Internal

3.4.2. Flow with scheduled settlement of the payment order (Scheduled Pix and Recurring Scheduled Pix and Pix Collection with maturity)

Layer Type Description

1 Payer's PSP Communication Start of process. If the payer user has informed a Pix key at the time of scheduling the transaction, the payer's PSP sends, previously to the date scheduled for settlement, a message to DICT for a new query of the identification information of the payee user. The EndToEndId of the transaction generated in this step must be informed in the PACS.008, so that there is replenishment of tokens in bucket 5.

2 DICT Communication DICT receives query of data about payee user.
Information related to the mechanisms adopted for prevention of reading attacks on DICT can be found in more detail in section 13 of the DICT Operational Manual.

49 • Manual of Flows of the Pix Settlement Process Internal

3 DICT Action DICT queries the received key, performs validation and returns the identification data found.

4 DICT Communication DICT sends communication to the payer's PSP with the identification data of the payee user.

5 Payer's PSP Communication Payer's PSP receives communication from DICT with the identification data of the payee user.

6 Payer's PSP Action Payer's PSP verifies the existence of the informed Pix key and whether the ownership of the account linked to it remains the same as the query performed at the time of scheduling. If the result is positive, flow proceeds to step 7. If the Pix key is verified as non-existent, or the ownership is different from that obtained in the query to DICT performed at the time of scheduling, flow proceeds to step 8.

7 Payer's PSP Action Payer's PSP executes the settlement of the payment order, according to the flows described in sections 3.1.1, 3.2.1, 3.3.1 and 3.4.1, depending on the condition of the PSPs involved. End of process.

8 Payer's PSP Action Payer's PSP cancels the scheduled payment order in its internal systems.

9 Payer's PSP Communication Payer's PSP sends notification of failure in the settlement of the scheduled payment order to the payer user.

10 Payer User Communication Payer user receives notification of failure in the settlement of the scheduled payment order, sent by the payer PSP. End of process.

50 • Manual of Flows of the Pix Settlement Process Internal

Pix Return Flow
In return flows, the payee user of the original transaction is identified as the sender user and the payer user of the original transaction is identified as the recipient user.

51 • Manual of Flows of the Pix Settlement Process Internal

4.1. Return flow between direct participants

52 • Manual de Flows of the Pix Settlement Process Internal

Layer Type Description

Sender PSP
Communication
Start of the process. Sender PSP receives the return order.
Sender PSP
Action
Sender PSP blocks the return amount in the sender user's account.
Sender PSP
Message
Sender PSP sends a message to the SPI, requesting a balance exchange in the PI Account to proceed with the return.
4 SPI Message
SPI receives the message sent by the Sender PSP, requesting a balance exchange in the PI Account to proceed with the return. 5 SPI Action SPI performs the block in the Sender PSP's PI Account for the amount of the return in question. 6 SPI Message SPI sends a message to the Recipient PSP, informing the return data. Recipient PSP Message Recipient PSP receives the message with the return data. Recipient PSP Action Recipient PSP of the return retrieves, based on the EndToEndId, the payment date, the transaction amount, and the data of the recipient user's transactional account. Recipient PSP Action Recipient PSP validates the return: checks if it meets the ninety-day deadline, if the recipient is its client, if the amount is adequate, and if the recipient user's account is active. 10 Recipient PSP Action Recipient PSP makes a provisional credit entry in the recipient user's account. 11 Recipient PSP Message Recipient PSP sends a message to the SPI, requesting the continuation of the return. 12 SPI Message SPI receives the message sent by the Recipient PSP, requesting the continuation of the return. 13 SPI Action SPI finalizes the balance exchange in the PI accounts: decreases the balance of the Sender PSP's PI Account by the value of the return in question and increases the balance of the Recipient PSP's PI Account by the same amount. 14 SPI Message SPI sends a message, confirming the completion of the transaction to the Recipient PSP. 15 Recipient PSP Message Recipient PSP receives the confirmation message of the completion of the return. 16 Recipient PSP Action Recipient PSP finalizes the credit in the recipient user's account. 17 Recipient PSP Communication Recipient PSP sends a communication confirming the completion of the return to the recipient user. 18 Recipient User Communication Recipient user receives the communication informing the completion of the return. 19 SPI Message SPI sends a message, confirming the completion of the transaction to the Sender PSP.

53 • Manual of Flows of the Pix Settlement Process Internal

20 Sender PSP
Message
Sender PSP receives the confirmation message of the completion of the return.
21 Sender PSP
Action
Sender PSP finalizes the debit in the sender user's account for the value of the return.
22 Sender PSP
Communication
Sender PSP sends a communication confirming the completion of the return to the sender user.
23 Sender User
Communication
Sender user receives the communication informing the completion of the return.

54 • Manual of Flows of the Pix Settlement Process Internal

4.2. Return flow between indirect participants

55 • Manual of Flows of the Pix Settlement Process Internal

Layer Type Description

Sender PSP
Communication
Start of the process. Sender PSP receives the return order.
Sender PSP
Action
Sender PSP blocks the return amount in the sender user's account.
Sender PSP
Communication
Sender PSP sends a communication to its clearing house, requesting a balance exchange in the PI Account to proceed with the return. Clearing House of Sender PSP Communication Clearing House of Sender PSP receives the communication, requesting a balance exchange in the PI Account to proceed with the return. Clearing House of Sender PSP Message Clearing House of Sender PSP sends a message to the SPI, requesting a balance exchange in the PI Account to proceed with the return. 6 SPI Message SPI receives the message, requesting a balance exchange in the PI Account to proceed with the return. 7 SPI Action SPI performs the block in the Clearing House of Sender PSP's PI Account for the amount of the return in question. 8 SPI Message SPI sends a message to the Clearing House of Recipient PSP, informing the return data. Clearing House of Recipient PSP Message Clearing House of Recipient PSP receives the message with the return data. Clearing House of Recipient PSP Communication Clearing House of Recipient PSP sends a communication to the Recipient PSP with the return data. 11 Recipient PSP Communication Recipient PSP receives the communication with the return data. 12 Recipient PSP Action Recipient PSP of the return retrieves, based on the EndToEndId, the payment date, the transaction amount, and the data of the recipient user's transactional account. 13 Recipient PSP Action Recipient PSP validates the return: checks if it meets the ninety-day deadline, if the recipient is its client, if the amount is adequate, and if the recipient user's account is active. 14 Recipient PSP Action Recipient PSP makes a provisional credit entry in the recipient user's account. 15 Recipient PSP Communication Recipient PSP sends a communication to the Clearing House of Recipient PSP, requesting the continuation of the return. Clearing House of Recipient PSP Communication Clearing House of Recipient PSP receives the communication sent by the Recipient PSP, requesting the continuation of the return. Clearing House of Recipient PSP Message Clearing House of Recipient PSP sends a message to the SPI, requesting the continuation of the return.

56 • Manual of Flows of the Pix Settlement Process Internal

18 SPI Message
SPI receives the message sent by the Clearing House of Recipient PSP requesting the continuation of the return 19 SPI Action SPI finalizes the balance exchange in the PI accounts: decreases the balance of the Clearing House of Sender PSP's PI Account by the value of the return in question and increases the balance of the Clearing House of Recipient PSP's PI Account by the same amount. 20 SPI Message SPI sends confirmation of the completion of the return to the Clearing House of Recipient PSP. Clearing House of Recipient PSP Message Clearing House of Recipient PSP receives the confirmation message of the completion of the return sent by the SPI. Clearing House of Recipient PSP Communication Clearing House of Recipient PSP sends a communication confirming the completion of the return to the Recipient PSP. 23 Recipient PSP Communication Recipient PSP receives the communication confirming the completion of the return. 24 Recipient PSP Action Recipient PSP finalizes the credit in the recipient user's account 25 Recipient PSP Communication Recipient PSP sends a communication confirming the completion of the return to the recipient user. 26 Recipient User Communication Recipient user receives the communication informing the completion of the return. 27 SPI Message SPI sends confirmation of the completion of the return to the Clearing House of Sender PSP. Clearing House of Sender PSP Message Clearing House of Sender PSP receives the confirmation message of the completion of the return sent by the SPI. Clearing House of Sender PSP Communication Clearing House of Sender PSP sends a communication confirming the completion of the return to the Sender PSP. 30 Sender PSP Communication Sender PSP receives the communication confirming the completion of the return. Sender PSP Action Sender PSP finalizes the debit in the sender user's account for the value of the return. Sender PSP Communication Sender PSP sends a communication confirming the completion of the return to the sender user. Sender User Communication Sender user receives the communication informing the completion of the return.

57 • Manual of Flows of the Pix Settlement Process Internal

Pix Automatic Flows
This section presents the authorization flows, granted in the payer PSP environment by the payer user, for the realization of recurring charge payments, the flows for scheduling recurring payments, and the flows for canceling both already scheduled payments and the recurrence itself. The flows related to the authorization and cancellation of authorization journeys (corresponding to messages PAIN.009, PAIN.011, and PAIN.012), as well as those related to the cancellation of schedules (corresponding to messages CAMT.029 and CAMT.055) occur via the primary message channel. Meanwhile, the flows related to the scheduling of the payment instruction (corresponding to messages PAIN.013 and PAIN.014) and settlement (messages PACS.008 and PACS.002) of Pix Automatic occur in the secondary message channel.

5.1. Authorization Flows

5.1.1. Journey 1 – Payer user chooses Pix Automatic as a payment method (interaction external to the ecosystem)

5.1.1.1. When the Payer PSP and the Payee PSP are different institutions
Step in which the payee user creates a recurrence with their PSP and requests confirmation from the payer user:

58 • Manual of Flows of the Pix Settlement Process Internal

Layer Type Description

1 Payee User
Communication
Start of the process. Payee user sends the recurrence data to the Payee PSP.
2 Payee PSP
Communication
Payee PSP receives the recurrence data sent by the payee user.
3 Payee PSP
Action
Payee PSP stores the recurrence data in its internal systems.
4 Payee PSP
Message
Payee PSP sends message PAIN.009 with the recurrence data.
5 ICOM
Message
ICOM receives message PAIN.009 with the recurrence data.
6 ICOM
Message
ICOM retransmits message PAIN.009 to the Payer PSP.
7 Payer PSP
Message
Payer PSP receives message PAIN.009 with the recurrence data.

59 • Manual of Flows of the Pix Settlement Process Internal

8 Payer PSP
Action
Payer PSP stores the recurrence data in its internal systems.
9 Payer PSP
Message
Payer PSP sends message PAIN.012, in response to message PAIN.009.
10 ICOM
Message
ICOM receives message PAIN.012, in response to message PAIN.009.
11 ICOM
Message
ICOM retransmits message PAIN.012 to the Payee PSP.
12 Payee PSP
Message
Payee PSP receives message PAIN.012, in response to message PAIN.009.
13 Payer PSP
Communication
Payer PSP sends a notification to the payer user, requesting authorization for payment of future recurring charges via Pix Automatic. 14 Payer User Communication Payer user receives the authorization request from the PSP for payment of future recurring charges via Pix Automatic. End of process.

60 • Manual of Flows of the Pix Settlement Process Internal

Step of recurrence confirmation by the payer user:

Layer Type Description

1 Payer User
Action
Start of the process. Payer user checks the recurrence data and authorizes Pix Automatic as a payment method for future recurring charges. 2 Payer User Communication Payer user sends the confirmation of the Pix Automatic authorization to the Payer PSP. 3 Payer PSP Communication Payer PSP receives the confirmation of the Pix Automatic authorization for payment of future recurring charges. 4 Payer PSP Action Payer PSP updates the status of the recurrence in its internal systems.

61 • Manual of Flows of the Pix Settlement Process Internal

5 Payer PSP
Message
Payer PSP sends message PAIN.012 confirming the recurrence.
6 ICOM
Message
ICOM receives message PAIN.012 confirming the recurrence.
7 ICOM
Message
ICOM retransmits message PAIN.012 confirming the recurrence to the Payee PSP.
8 Payee PSP
Message
Payee PSP receives message PAIN.012 confirming the recurrence.
9 Payee PSP
Action
Payee PSP updates the status of the recurrence in its internal systems.
10 Payee PSP
Communication
Payee PSP sends to the payee user the notification of confirmation of Pix Automatic as a payment method for future recurring charges. 11 Payee User Communication Payee user receives the notification of confirmation of Pix Automatic as a payment method for future recurring charges. 12 Payee PSP Message Payee PSP sends message PAIN.012 in response to the message PAIN.012 confirming the recurrence. 13 ICOM Message ICOM receives message PAIN.012. 14 ICOM Message ICOM retransmits message PAIN.012 to the Payer PSP. 15 Payer PSP Message Payer PSP receives message PAIN.012 in response to the message PAIN.012 confirming the recurrence. 16 Payer PSP Communication Payer PSP sends a notification to the payer user, confirming the authorization for the payment of future recurring charges to be made via Pix Automatic. 17 Payer User Communication Payer user receives the confirmation that the authorization for Pix Automatic was completed successfully. End of process.

62 • Manual of Flows of the Pix Settlement Process Internal

5.1.1.2. When the Payer PSP and the Payee PSP are the same institution

Layer Type Description

1 Payee User
Communication
Start of the process. Payee user sends the recurrence data to the PSP.
2 PSP
Communication
PSP receives the recurrence data sent by the payee user.
3 PSP
Action
PSP stores the recurrence data in its internal systems.
4 PSP
Communication
PSP sends a notification to the payer user, requesting authorization for payment of future recurring charges via Pix Automatic. 5 Payer User Communication Payer user receives the authorization request from the PSP for payment of future recurring charges via Pix Automatic. 6 Payer User Action Payer user checks the recurrence data and authorizes Pix Automatic as a payment method for future recurring charges. 7 Payer User Communication Payer user sends the confirmation of the Pix Automatic authorization to the PSP. 8 PSP Communication PSP receives the confirmation of the Pix Automatic authorization for payment of future recurring charges. 9 PSP Action PSP updates the status of the recurrence in its internal systems.

63 • Manual of Flows of the Pix Settlement Process Internal

10 PSP
Communication
PSP sends to the payee user the notification of confirmation of Pix Automatic as a payment method for future recurring charges. 11 Payee User Communication Payee user receives the notification of confirmation of Pix Automatic as a payment method for future recurring charges. 12 PSP Communication PSP sends a notification to the payer user, confirming the authorization for the payment of future recurring charges to be made via Pix Automatic. 13 Payer User Communication Payer user receives the confirmation that the authorization for Pix Automatic was completed successfully. End of process.

5.1.2. Journey 2 – Payer user joins via the Payer PSP (reading of QR Code containing recurrence data)

5.1.2.1. When the Payer PSP and the Payee PSP are different institutions
Step of sending the recurrence data by the payee user to the payer user:

Layer Type Description

1 Payee User
Action
Start of the process. Payee user generates the QR Code with the recurrence data.
2 Payee User
Communication
Payee user sends, outside the Pix ecosystem, the QR Code with the recurrence data to the payer user.
3 Payer User
Communication
Payer user receives the QR Code for reading in the Payer PSP app. End of process.

64 • Manual of Flows of the Pix Settlement Process Internal

Step of recurrence confirmation by the payer user:

65 • Manual of Flows of the Pix Settlement Process Internal

Layer Type Description

1 Payer User
Action
Start of the process. Payer user reads the QR Code provided by the payee user outside the Pix ecosystem.
2 Payer User
Communication
Data read from the QR Code are forwarded to the Payer PSP.
3 Payer PSP
Communication
Payer PSP receives the QR Code data.
4 Payer PSP
Action
Payer PSP interprets the QR Code and identifies the location contained in it.
5 Payer PSP
Communication
Payer PSP sends the location query to the Payee PSP.
6 Payee PSP
Communication
Payee PSP receives the query request sent by the Payer PSP.
7 Payee PSP
Action
Payee PSP loads the recurrence data into the payload.
8 Payee PSP
Communication
Payee PSP transmits the payload with the recurrence data to the Payer PSP.
9 Payer PSP
Communication
Payer PSP receives the payload with the recurrence data.
10 Payer PSP
Communication
Payer PSP sends the recurrence data to the payer user, for confirmation.
11 Payer User
Communication
Payer user receives the recurrence data for confirmation, in the Payer PSP app.
12 Payer User
Action
Payer user checks the recurrence data and authorizes Pix Automatic as a payment method for future recurring charges.
13 Payer User
Communication
Payer user sends the confirmation of the Pix Automatic authorization to the Payer PSP.
14 Payer PSP
Communication
Payer PSP receives the confirmation of the Pix Automatic authorization for payment of future recurring charges.
15 Payer PSP
Action
Payer PSP updates the status of the recurrence in its internal systems.
16 Payer PSP
Communication
Payer PSP sends message PAIN.012 confirming the recurrence.
17 ICOM
Message
ICOM receives message PAIN.012 confirming the recurrence.
18 ICOM
Message
ICOM retransmits message PAIN.012 confirming the recurrence to the Payee PSP.
19 Payee PSP
Message
Payee PSP receives message PAIN.012 confirming the recurrence.
20 Payee PSP
Action
Payee PSP updates the status of the recurrence in its internal systems.
21 Payee PSP
Communication
Payee PSP sends to the payee user the notification of confirmation of Pix Automatic as a payment method for future recurring charges.

66 • Manual of Flows of the Pix Settlement Process Internal

22 Payee User
Communication
Payee user receives the notification of confirmation of Pix Automatic as a payment method for future recurring charges.
23 Payee PSP
Message
Payee PSP sends message PAIN.012 in response to the message PAIN.012 confirming the recurrence.
24 ICOM
Message
ICOM receives message PAIN.012.
25 ICOM
Message
ICOM retransmits message PAIN.012 to the Payer PSP.
26 Payer PSP
Message
Payer PSP receives message PAIN.012 in response to the message PAIN.012 confirming the recurrence.
27 Payer PSP
Communication
Payer PSP sends a notification to the payer user, confirming the authorization for the payment of future recurring charges to be made via Pix Automatic. 28 Payer User Communication Payer user receives the confirmation that the authorization for Pix Automatic was completed successfully. End of process.

5.1.2.2. When the Payer PSP and the Payee PSP are the same institution
Step of sending the recurrence data by the payee user to the payer user:

Layer Type Description

67 • Manual of Flows of the Pix Settlement Process Internal

Step of recurrence confirmation by the payer user:

Layer Type Description

1 Payer User
Action
Start of the process. Payer user reads the QR Code provided by the payee user outside the Pix ecosystem.
2 Payer User
Communication
Data read from the QR Code are forwarded to the PSP.
3 PSP
Communication
PSP receives the QR Code data.
4 PSP
Action
PSP loads the recurrence data.
5 PSP
Communication
PSP sends the recurrence data to the payer user, for confirmation.
6 Payer User
Communication
Payer user receives the recurrence data for confirmation, in the PSP app.
7 Payer User
Action
Payer user checks the recurrence data and authorizes Pix Automatic as a payment method for future recurring charges.
8 Payer User
Communication
Payer user sends the confirmation of the Pix Automatic authorization to the PSP.

68 • Manual of Flows of the Pix Settlement Process Internal

9 PSP
Communication
PSP receives the confirmation of the Pix Automatic authorization for payment of future recurring charges.
10 PSP
Action
PSP updates the status of the recurrence in its internal systems.
11 PSP
Communication
PSP sends to the payee user the notification of confirmation of Pix Automatic as a payment method for future recurring charges. 12 Payee User Communication Payee user receives the notification of confirmation of Pix Automatic as a payment method for future recurring charges. 13 PSP Communication PSP sends a notification to the payer user, confirming the authorization for the payment of future recurring charges to be made via Pix Automatic. 14 Payer User Communication Payer user receives the confirmation that the authorization for Pix Automatic was completed successfully. End of process.

5.1.3. Journey 3 – Payer user joins via reading of QR Code with first immediate payment

5.1.3.1. When the Payer PSP and the Payee PSP are different institutions
Step of sending the recurrence data by the payee user to the payer user:

Layer Type Description

1 Payee User
Action
Start of the process. Payee user generates the QR Code with the data of the immediate charge and the recurrence.
2 Payee User
Communication
Payee user sends, outside the Pix ecosystem, the QR Code with the data of the immediate charge and the recurrence to the payer user. 3 Payer User Communication Payer user receives the QR Code for reading in the Payer PSP app. End of process.

69 • Manual of Flows of the Pix Settlement Process Internal

Step of payment of the first charge and authorization of the recurrence by the payer user:

Pix Execution Process Flows Manual

Internal

Layer	Type	Description
1	Payer User	Action<br>Start of the process. The Payer User reads the QR Code provided by the Payee User outside the Pix ecosystem.
2	Payer User	Communication<br>Data read from the QR Code is forwarded to the Payer's PSP.
3	Payer's PSP	Communication<br>The Payer's PSP receives the QR Code data.
4	Payer's PSP	Action<br>The Payer's PSP interprets the QR Code and identifies the locations contained within it.
5	Payer's PSP	Communication<br>The Payer's PSP sends location queries to the Payee's PSP.
6	Payee's PSP	Communication<br>The Payee's PSP receives the query requests sent by the Payer's PSP.
7	Payee's PSP	Action<br>The Payee's PSP loads the immediate charge and recurrence data into the payloads.
8	Payee's PSP	Communication<br>The Payee's PSP transmits the payloads with the immediate charge and recurrence data to the Payer's PSP.
9	Payer's PSP	Communication<br>The Payer's PSP receives the payloads with the immediate charge and recurrence data.
10	Payer's PSP	Communication<br>The Payer's PSP presents a simultaneous journey for the immediate payment of a charge and the authorization of future recurring charge payments via Pix Automatic.
11	Payer User	Communication<br>The Payer User receives a request for authorization from the Payer's PSP to make future recurring charge payments via Pix Automatic, according to the data contained in the recurrence, with notice that the first payment will occur immediately after authorization.
12	Payer User	Action<br>The Payer User checks the recurrence data and authorizes Pix Automatic as a form of payment for future recurring charges, simultaneously confirming the payment of the first charge.
13	Payer User	Communication<br>The Payer User sends the confirmation of the Pix Automatic authorization to the Payer's PSP, along with the confirmation of the immediate payment of the first charge.
14	Payer's PSP	Communication<br>The Payer's PSP receives the confirmation of the Pix Automatic authorization for future recurring charge payments, along with the confirmation of the immediate payment of the first charge.
15	Payer's PSP	Action<br>The Payer's PSP proceeds with the payment of the first charge, which follows the usual flow for the execution of a Pix, as described in section 3 of this Manual. The notification of payment confirmation to the Payer User may be sent in step 32, along with the authorization confirmation. The payment order is immediate and must proceed through the primary message transmission channel of the SPI.
16	Payer's PSP	Decision<br>The Payer's PSP verifies whether the payment of the first charge was completed successfully. If the result is positive, the flow proceeds to step 20. If the payment of the first charge did not materialize, the flow proceeds to step 17.
17	Payer's PSP	Action<br>The Payer's PSP interrupts the authorization process.
18	Payer's PSP	Communication<br>The Payer's PSP sends a notification to the Payer User, informing that the first payment of the charge and the authorization for future recurring charge payments to be made via Pix Automatic were not effected.
19	Payer User	Communication<br>The Payer User receives the notification, informing that the first payment of the charge and the authorization for future recurring charge payments to be made via Pix Automatic were not effected. End of process.
20	Payer's PSP	Action<br>The Payer's PSP updates the status of the recurrence in its internal systems.
21	Payer's PSP	Communication<br>The Payer's PSP sends the PAIN.012 message confirming the recurrence.
22	ICOM	Message<br>ICOM receives the PAIN.012 message confirming the recurrence.
23	ICOM	Message<br>ICOM retransmits the PAIN.012 message confirming the recurrence to the Payee's PSP.
24	Payee's PSP	Message<br>The Payee's PSP receives the PAIN.012 message confirming the recurrence.
25	Payee's PSP	Action<br>The Payee's PSP updates the status of the recurrence in its internal systems. It is noted that the Payee's PSP must wait for the completion of the settlement flow of the first immediate payment before proceeding with this step.
26	Payee's PSP	Communication<br>The Payee's PSP sends the Payee User a notification confirming Pix Automatic as a form of payment for future recurring charges. The confirmation of the immediate payment of the first charge follows the flow described in section 3 of this Manual.
27	Payee User	Communication<br>The Payee User receives the notification confirming Pix Automatic as a form of payment for future recurring charges. The notification of confirmation of the immediate payment of the first charge follows the flow described in section 3 of this Manual.
28	Payee's PSP	Message<br>The Payee's PSP sends the PAIN.012 message in response to the PAIN.012 message confirming the recurrence.
29	ICOM	Message<br>ICOM receives the PAIN.012 message.
30	ICOM	Message<br>ICOM retransmits the PAIN.012 message to the Payer's PSP.
31	Payer's PSP	Message<br>The Payer's PSP receives the PAIN.012 message in response to the PAIN.012 message confirming the recurrence.
32	Payer's PSP	Communication<br>The Payer's PSP sends a notification to the Payer User, confirming the authorization for future recurring charge payments to be made via Pix Automatic.
33	Payer User	Communication<br>The Payer User receives the payment confirmation notification (if it was not sent in step 15) and that the authorization for Pix Automatic was completed successfully. End of process.

5.1.3.2. When the Payer's PSP and the Payee's PSP are the same institution

Step of sending the recurrence data by the Payee User to the Payer User:

Layer	Type	Description
1	Payee User	Action<br>Start of the process. The Payee User generates the QR Code with the data of the immediate charge and the recurrence.
2	Payee User	Communication<br>The Payee User sends, outside the Pix ecosystem, the QR Code with the data of the immediate charge and the recurrence to the Payer User.
3	Payer User	Communication<br>The Payer User receives the QR Code for reading in the PSP app. End of process.

Step of payment of the 1st charge and authorization of the recurrence by the Payer User:

Layer	Type	Description
1	Payer User	Action<br>Start of the process. The Payer User reads the QR Code provided by the Payee User outside the Pix ecosystem.
2	Payer User	Communication<br>Data read from the QR Code is forwarded to the PSP.
3	PSP	Communication<br>The PSP receives the QR Code data.
4	PSP	Action<br>The PSP loads the data of the immediate charge and the recurrence.
5	PSP	Communication<br>The PSP presents a simultaneous journey for the immediate payment of a charge and the authorization of future recurring charge payments via Pix Automatic.
6	Payer User	Communication<br>The Payer User receives a request for authorization from the PSP to make future recurring charge payments via Pix Automatic, according to the data contained in the recurrence, with notice that the first payment will occur immediately after authorization.
7	Payer User	Action<br>The Payer User checks the recurrence data and authorizes Pix Automatic as a form of payment for future recurring charges, simultaneously confirming the payment of the first charge.
8	Payer User	Communication<br>The Payer User sends the confirmation of the Pix Automatic authorization to the PSP, along with the confirmation of the immediate payment of the first charge.
9	PSP	Communication<br>The PSP receives the confirmation of the Pix Automatic authorization for future recurring charge payments, along with the confirmation of the immediate payment of the first charge.
10	PSP	Action<br>The PSP proceeds with the immediate payment of the first charge, which follows the usual flow for the execution of a Pix, as described in section 3.3 of this Manual. The sending of the payment confirmation notification to the Payer User may be done in step 18, along with the authorization confirmation.
11	PSP	Decision<br>The PSP verifies whether the payment of the first charge was completed successfully. If the result is positive, the flow proceeds to step 15. If the payment of the first charge did not materialize, the flow proceeds to step 12.
12	PSP	Action<br>The PSP interrupts the authorization process.
13	PSP	Communication<br>The PSP sends a notification to the Payer User, informing that the first payment of the charge and the authorization for future recurring charge payments to be made via Pix Automatic were not effected.
14	Payer User	Communication<br>The Payer User receives the notification, informing that the first payment of the charge and the authorization for future recurring charge payments to be made via Pix Automatic were not effected. End of process.
15	PSP	Action<br>The PSP updates the status of the recurrence in its internal systems.
16	PSP	Communication<br>The PSP sends the Payee User a notification confirming Pix Automatic as a form of payment for future recurring charges. The confirmation of the immediate payment of the first charge follows the flow described in section 3.3 of this Manual.
17	Payee User	Communication<br>The Payee User receives the notification confirming Pix Automatic as a form of payment for future recurring charges. The notification of confirmation of the immediate payment of the first charge follows the flow described in section 3.3 of this Manual.
18	PSP	Communication<br>The PSP sends a notification to the Payer User, confirming the authorization for future recurring charge payments to be made via Pix Automatic.
19	Payer User	Communication<br>The Payer User receives the payment confirmation notification (if it was not sent in step 10) and that the authorization for Pix Automatic was completed successfully. End of process.

5.1.4. Journey 4 – User pays via QR Code and receives a proposal to enable Pix Automatic for future recurring charge payments

5.1.4.1. When the Payer's PSP and the Payee's PSP are different institutions

Step of sending the recurrence data by the Payee User to the Payer User:

Layer	Type	Description
1	Payee User	Action<br>Start of the process. The Payee User generates the QR Code with the data of the charge and the recurrence.
2	Payee User	Communication<br>The Payee User sends, outside the Pix ecosystem, the QR Code with the data of the charge and the recurrence to the Payer User.
3	Payer User	Communication<br>The Payer User receives the QR Code for reading in the Payer's PSP app. End of process.

Step of payment of the charge and confirmation of the recurrence by the Payer User:

Layer	Type	Description
1	Payer User	Action<br>Start of the process. The Payer User reads the QR Code provided by the Payee User outside the Pix ecosystem.
2	Payer User	Communication<br>Data read from the QR Code is forwarded to the Payer's PSP.
3	Payer's PSP	Communication<br>The Payer's PSP receives the QR Code data.
4	Payer's PSP	Action<br>The Payer's PSP interprets the QR Code 6 and identifies the locations contained within it.
5	Payer's PSP	Communication<br>The Payer's PSP sends location queries to the Payee's PSP.
6	Payee's PSP	Communication<br>The Payee's PSP receives the query requests sent by the Payer's PSP.
7	Payee's PSP	Action<br>The Payee's PSP loads the data of the charge and the recurrence into the payloads.
8	Payee's PSP	Communication<br>The Payee's PSP transmits the payloads with the data of the charge and the recurrence to the Payer's PSP.
9	Payer's PSP	Communication<br>The Payer's PSP receives the payloads with the data of the charge and the recurrence.
10	Payer's PSP	Communication<br>The Payer's PSP sends a payment/scheduling request for the charge to the Payer User.
11	Payer User	Communication<br>The Payer User receives the payment/scheduling request for the charge via the Payer's PSP app.
12	Payer User	Action<br>The Payer User confirms the payment/scheduling of the charge.
13	Payer User	Communication<br>The Payer User sends the confirmation of the payment/scheduling of the charge to the Payer's PSP.
14	Payer's PSP	Communication<br>The Payer's PSP receives the confirmation of the payment/scheduling of the charge.
15	Payer's PSP	Decision<br>If the Payer User has opted for immediate settlement of the charge, the flow proceeds to step 16. If they have chosen to schedule the payment of the charge, proceed to step 17.
16	Payer's PSP	Action<br>The Payer's PSP proceeds with the payment of the charge, which follows the usual flow for the execution of a Pix, as per section 3 of this Manual.
17	Payer's PSP	Action<br>The Payer's PSP schedules the payment of the charge for the date chosen by the Payer User at the time of scheduling confirmation, which must follow the usual flow for the execution of a Scheduled Pix, as per section 3 of this Manual.
18	Payer's PSP	Communication<br>The Payer's PSP sends a notification confirming the payment of the charge (or scheduling of the charge) and offers Pix Automatic as a form of payment for future recurring charges.
19	Payer User	Communication<br>The Payer User receives the notification and the offer of Pix Automatic as a form of payment for future recurring charges.
20	Payer User	Action<br>The Payer User expresses interest in Pix Automatic as a form of payment for future recurring charges.
21	Payer User	Communication<br>The Payer User sends the expression of interest in Pix Automatic to the Payer's PSP.
22	Payer's PSP	Communication<br>The Payer's PSP receives the expression of interest in Pix Automatic sent by the Payer User.
23	Payer's PSP	Communication<br>The Payer's PSP sends the recurrence data to the Payer User for confirmation.
24	Payer User	Communication<br>The Payer User receives the recurrence data for confirmation in the Payer's PSP app.
25	Payer User	Action<br>The Payer User checks the recurrence data and authorizes Pix Automatic as a form of payment for future recurring charges.
26	Payer User	Communication<br>The Payer User sends the confirmation of the Pix Automatic authorization to the Payer's PSP.
27	Payer's PSP	Communication<br>The Payer's PSP receives the confirmation of the Pix Automatic authorization for future recurring charge payments.
28	Payer's PSP	Action<br>The Payer's PSP updates the status of the recurrence in its internal systems.
29	Payer's PSP	Communication<br>The Payer's PSP sends the PAIN.012 message confirming the recurrence.
30	ICOM	Message<br>ICOM receives the PAIN.012 message confirming the recurrence.
31	ICOM	Message<br>ICOM retransmits the PAIN.012 message confirming the recurrence to the Payee's PSP.
32	Payee's PSP	Message<br>The Payee's PSP receives the PAIN.012 message confirming the recurrence.
33	Payee's PSP	Action<br>The Payee's PSP updates the status of the recurrence in its internal systems.
34	Payee's PSP	Communication<br>The Payee's PSP sends the Payee User a notification confirming Pix Automatic as a form of payment for future recurring charges.
35	Payee User	Communication<br>The Payee User receives the notification confirming Pix Automatic as a form of payment for future recurring charges.
36	Payee's PSP	Message<br>The Payee's PSP sends the PAIN.012 message in response to the PAIN.012 message confirming the recurrence.
37	ICOM	Message<br>ICOM receives the PAIN.012 message.
38	ICOM	Message<br>ICOM retransmits the PAIN.012 message to the Payer's PSP.
39	Payer's PSP	Message<br>The Payer's PSP receives the PAIN.012 message in response to the PAIN.012 message confirming the recurrence.
40	Payer's PSP	Communication<br>The Payer's PSP sends a notification to the Payer User, confirming the authorization for future recurring charge payments to be made via Pix Automatic.
41	Payer User	Communication<br>The Payer User receives confirmation that the authorization for Pix Automatic was completed successfully. End of process.

5.1.4.2. When the Payer's PSP and the Payee's PSP are the same institution

Step of sending the recurrence data by the Payee User to the Payer User:

Layer	Type	Description
1	Payee User	Action<br>Start of the process. The Payee User generates the QR Code with the data of the charge and the recurrence.
2	Payee User	Communication<br>The Payee User sends, outside the Pix ecosystem, the QR Code with the data of the charge and the recurrence to the Payer User.
3	Payer User	Communication<br>The Payer User receives the QR Code for reading in the PSP app. End of process.

Step of payment of the charge and confirmation of the recurrence by the Payer User:

Layer	Type	Description
1	Payer User	Action<br>Start of the process. The Payer User reads the QR Code 7 provided by the Payee User outside the Pix ecosystem.
2	Payer User	Communication<br>Data read from the QR Code is forwarded to the PSP.
3	PSP	Communication<br>The PSP receives the QR Code data.
4	PSP	Action<br>The PSP loads the data of the charge and the recurrence.
5	PSP	Communication<br>The PSP sends a payment/scheduling request for the charge to the Payer User.
6	Payer User	Communication<br>The Payer User receives the payment/scheduling request for the charge via the PSP app.
7	Payer User	Action<br>The Payer User confirms the payment/scheduling of the charge.
8	Payer User	Communication<br>The Payer User sends the confirmation of the payment/scheduling of the charge to the PSP.
9	PSP	Communication<br>The PSP receives the confirmation of the payment of the charge.
10	PSP	Decision<br>If the Payer User has opted for immediate settlement of the charge, the flow proceeds to step 11. If they have chosen to schedule the payment of the charge, proceed to step 12.
11	PSP	Action<br>The PSP proceeds with the payment/scheduling of the charge, which follows the usual flow for the execution of a Pix, as per section 3.3 of this Manual.
12	PSP	Action<br>The PSP schedules the payment of the charge for the date chosen by the Payer User at the time of scheduling confirmation, which must follow the usual flow for the execution of a Scheduled Pix, as per section 3 of this Manual.
13	PSP	Communication<br>The PSP sends a notification confirming the payment/scheduling of the charge and offers Pix Automatic as a form of payment for future recurring charges.
14	Payer User	Communication<br>The Payer User receives the payment confirmation notification and the offer of Pix Automatic as a form of payment for future recurring charges.
15	Payer User	Action<br>The Payer User expresses interest in Pix Automatic as a form of payment for future recurring charges.
16	Payer User	Communication<br>The Payer User sends the expression of interest in Pix Automatic to the PSP.
17	PSP	Communication<br>The PSP receives the expression of interest in Pix Automatic sent by the Payer User.
18	PSP	Communication<br>The PSP sends the recurrence data to the Payer User for confirmation.
19	Payer User	Communication<br>The Payer User receives the recurrence data for confirmation in the PSP app.
20	Payer User	Action<br>The Payer User checks the recurrence data and authorizes Pix Automatic as a form of payment for future recurring charges.
21	Payer User	Communication<br>The Payer User sends the confirmation of the Pix Automatic authorization to the PSP.
22	PSP	Communication<br>The PSP receives the confirmation of the Pix Automatic authorization for future recurring charge payments.
23	PSP	Action<br>The PSP updates the status of the recurrence in its internal systems.
24	PSP	Communication<br>The PSP sends the Payee User a notification confirming Pix Automatic as a form of payment for future recurring charges.
25	Payee User	Communication<br>The Payee User receives the notification confirming Pix Automatic as a form of payment for future recurring charges.
26	PSP	Communication<br>The PSP sends a notification to the Payer User, confirming the authorization for future recurring charge payments to be made via Pix Automatic.
27	Payer User	Communication<br>The Payer User receives confirmation that the authorization for Pix Automatic was completed successfully. End of process.

5.1.5. Cancellation of authorization by the Payer User

5.1.5.1. When the Payer's PSP and the Payee's PSP are different institutions

Layer	Type	Description
1	Payer User	Communication<br>Start of the process. The Payer User requests the cancellation of the authorization to the Payer's PSP.
2	Payer's PSP	Communication<br>The Payer's PSP receives the cancellation request of the authorization from the Payer User.
3	Payer's PSP	Action<br>The Payer's PSP cancels the authorization in its internal systems.
4	Payer's PSP	Communication<br>The Payer's PSP sends a notification to the Payer User, confirming the cancellation of the authorization.

6 The flow represents the case where the QR Code contains two locations: one with the charge data and another with the recurrence data. If the charge data is contained in the QR Code itself (dynamic similar to static QR Code), only the recurrence data should be obtained using the QR Code location to access the payload provided by the Payee's PSP.

7 The flow represents the case where the QR Code contains two locations: one with the charge data and another with the recurrence data. If the charge data is contained in the QR Code itself (dynamic similar to static QR Code), only the recurrence data should be obtained using the QR Code location to access the Payee's PSP internal systems.

85 • Manual of Flows for the Pix Execution Process Internal

5 Payer User Communication Payer User receives notification of confirmation of the cancellation of the authorization.
6 Payer PSP Message Payer PSP sends PAIN.011 message to inform the cancellation of the recurring transaction associated with the cancelled authorization. 7 ICOM Message ICOM receives PAIN.011 message informing the cancellation of the recurring transaction. 8 ICOM Message ICOM retransmits the PAIN.011 message to the Payee PSP. 9 Payee PSP Message Payee PSP receives the PAIN.011 message informing the cancellation of the recurring transaction. 10 Payee PSP Action Payee PSP registers the cancellation in its internal systems and updates the status of the recurring transaction. 11 Payee PSP Message Payee PSP sends PAIN.012 message, in response to the PAIN.011 message. 12 ICOM Message ICOM receives PAIN.012 message, in response to the PAIN.011 message. 13 ICOM Message ICOM retransmits the PAIN.012 message to the Payer PSP. 14 Payer PSP Message Payer PSP receives PAIN.012 message, in response to the PAIN.011 message. 15 Payee PSP Communication Payee PSP sends notification of the cancellation of the recurring transaction to the Payee User. 16 Payee User Communication Payee User receives notification of the cancellation of the recurring transaction. End of process.

After the cancellation of the recurring transaction, if there are pending schedules to be cancelled, the flow to be followed from step 3 is the flow for cancelling a scheduled debit by the Payer User, described in section 5.2.3 of this Manual.

86 • Manual of Flows for the Pix Execution Process Internal

5.1.5.2. When the Payer PSP and the Payee PSP are the same institution

#	Layer	Type	Description
1	Payer User	Communication	Start of process. Payer User requests the cancellation of the authorization to the PSP.
2	PSP	Communication	PSP receives the cancellation of the authorization request from the Payer User.
3	PSP	Action	PSP cancels the authorization in its internal systems and updates the status of the recurring transaction.
4	PSP	Communication	PSP sends notification to the Payer User, confirming the cancellation of the authorization.
5	Payer User	Communication	Payer User receives notification of confirmation of the cancellation of the authorization.
6	PSP	Communication	PSP sends notification of the cancellation of the recurring transaction to the Payee User.
7	Payee User	Communication	Payee User receives notification of the cancellation of the recurring transaction. End of process.

87 • Manual of Flows for the Pix Execution Process Internal

5.1.6. Cancellation of the recurring transaction by the Payee User

5.1.6.1. When the Payer PSP and the Payee PSP are different institutions

88 • Manual of Flows for the Pix Execution Process Internal

#	Layer	Type	Description
1	Payee User	Communication	Start of process. Payee User requests the cancellation of the recurring transaction to the Payee PSP.
2	Payee PSP	Communication	Payee PSP receives the cancellation of the recurring transaction request from the Payee User.
3	Payee PSP	Action	Payee PSP cancels the recurring transaction in its internal systems.
4	Payee PSP	Communication	Payee PSP sends notification to the Payee User, confirming the cancellation of the recurring transaction.
5	Payee User	Communication	Payee User receives notification of confirmation of the cancellation of the recurring transaction.
6	Payee PSP	Message	Payee PSP sends PAIN.011 message to inform the cancellation of the recurring transaction.
7	ICOM	Message	ICOM receives PAIN.011 message informing the cancellation of the recurring transaction.
8	ICOM	Message	ICOM retransmits the PAIN.011 message to the Payer PSP.
9	Payer PSP	Message	Payer PSP receives the PAIN.011 message informing the cancellation of the recurring transaction.
10	Payer PSP	Action	Payer PSP registers the cancellation in its internal systems and updates the status of the recurring transaction.
11	Payer PSP	Message	Payer PSP sends PAIN.012 message, in response to the PAIN.011 message.
12	ICOM	Message	ICOM receives PAIN.012 message, in response to the PAIN.011 message.
13	ICOM	Message	ICOM retransmits the PAIN.012 message to the Payee PSP.
14	Payer PSP	Message	Payee PSP receives PAIN.012 message, in response to the PAIN.011 message.
15	Payer PSP	Communication	Payer PSP sends notification of the cancellation of the authorization associated with the cancelled recurring transaction to the Payer User.
16	Payer User	Communication	Payer User receives notification of the cancellation of the authorization associated with the cancelled recurring transaction. End of process.

This flow must also be used in the event that the Payee User and/or the Payee PSP identify the need to cancel a recurring transaction request sent via Journey 1 that is still pending response from the Payer User, such as in the case where the recurring transaction request has already been accepted in parallel by the Payer User via another journey.

89 • Manual of Flows for the Pix Execution Process Internal

5.1.6.2. When the Payer PSP and the Payee PSP are the same institution

#	Layer	Type	Description
1	Payee User	Communication	Start of process. Payee User requests the cancellation of the recurring transaction to the PSP.
2	PSP	Communication	PSP receives the cancellation of the recurring transaction request from the Payee User.
3	PSP	Action	PSP updates the status of the recurring transaction and cancels the respective authorization in its internal systems.
4	PSP	Communication	PSP sends notification to the Payee User, confirming the cancellation of the recurring transaction.
5	Payee User	Communication	Payee User receives notification of confirmation of the cancellation of the recurring transaction.
6	PSP	Communication	PSP sends notification of the cancellation of the authorization associated with the cancelled recurring transaction to the Payer User.
7	Payer User	Communication	Payer User receives notification of the cancellation of the authorization associated with the cancelled recurring transaction. End of process.

90 • Manual of Flows for the Pix Execution Process Internal

5.2. Debit Scheduling Flows

5.2.1. Debit Scheduling

5.2.1.1. When the Payer PSP and the Payee PSP are different institutions

91 • Manual of Flows for the Pix Execution Process Internal

#	Layer	Type	Description
1	Payee User	Communication	Start of process. Payee User sends the billing data to the Payee PSP.
2	Payee PSP	Communication	Payee PSP receives the billing data sent by the Payee User.
3	Payee PSP	Action	Payee PSP validates the billing data with the recurring information stored in its internal systems.
4	Payee PSP	Message	Payee PSP sends PAIN.013 message containing the billing data.
5	ICOM	Message	ICOM receives PAIN.013 message with the billing data.
6	ICOM	Message	ICOM retransmits the PAIN.013 message to the Payer PSP.
7	Payer PSP	Message	Payer PSP receives the PAIN.013 message with the billing data.
8	Payer PSP	Action	Payer PSP compares the billing data with the information of the granted authorization and schedules the payment order for the scheduled date.
9	Payer PSP	Message	Payer PSP sends PAIN.014 message, in response to the PAIN.013 message.
10	ICOM	Message	ICOM receives PAIN.014 message, in response to the PAIN.013 message.
11	ICOM	Message	ICOM retransmits the PAIN.014 message to the Payee PSP.
12	Payee PSP	Message	Payee PSP receives the PAIN.014 message, in response to the PAIN.013 message.
13	Payee PSP	Action	Payee PSP stores the scheduling information in its internal systems.
14	Payee PSP	Communication	Payee PSP notifies the Payee User that the scheduling was successful.
15	Payee User	Communication	Payee User receives notification about the success of the scheduling.
16	Payer PSP	Communication	Payer PSP sends notification of the debit scheduling to the Payer User 8.
17	Payer User	Communication	Payer User receives notification of the debit scheduling. End of process.

8 The Payer User may, at any time, disable the scheduling notification option, as provided for in the Minimum Requirements for User Experience Manual. In this case, steps 16 and 17 of the flow should not be carried out.

92 • Manual of Flows for the Pix Execution Process Internal

5.2.1.2. When the Payer PSP and the Payee PSP are the same institution

#	Layer	Type	Description
1	Payee User	Communication	Start of process. Payee User sends the billing data to the PSP.
2	PSP	Communication	PSP receives the billing data sent by the Payee User.
3	PSP	Action	PSP compares the billing data with the information of the granted authorization and schedules the payment order for the scheduled date.
4	PSP	Communication	PSP notifies the Payee User that the scheduling was successful.
5	Payee User	Communication	Payee User receives notification about the success of the scheduling.
6	PSP	Communication	PSP sends notification of the debit scheduling to the Payer User 9.
7	Payer User	Communication	Payer User receives notification of the debit scheduling. End of process.

9 The Payer User may, at any time, disable the scheduling notification option, as provided for in the Minimum Requirements for User Experience Manual. In this case, steps 6 and 7 of the flow should not be carried out.

93 • Manual of Flows for the Pix Execution Process Internal

5.2.2. New Intraday Attempts Due to Error in the Settlement Flow

5.2.2.1. When the Payer PSP and the Payee PSP are different institutions

#	Layer	Type	Description
1	Payer PSP	Action	Start of process. Payer PSP identifies that the settlement of the payment order did not occur due to an error in the settlement flow.
2	Payer PSP	Action	Payer PSP registers that the payment order was not settled in its internal systems.
3	Payer PSP	Message	Payer PSP sends CAMT.055 message cancelling the payment instruction, the settlement of which did not occur.
4	ICOM	Message	ICOM receives CAMT.055 message cancelling the payment instruction.

94 • Manual of Flows for the Pix Execution Process Internal

5 | ICOM | Message | ICOM retransmits the CAMT.055 message cancelling the payment instruction. |

6	Payee PSP	Message	Payee PSP receives the CAMT.055 message cancelling the payment instruction.
7	Payee PSP	Action	Payee PSP registers the cancellation of the payment instruction in its internal systems.
8	Payee PSP	Message	Payee PSP sends CAMT.029 message, in response to the CAMT.055 message.
9	ICOM	Message	ICOM receives CAMT.029 message, in response to the CAMT.055 message.
10	ICOM	Message	ICOM retransmits the CAMT.029 message to the Payer PSP.
11	Payer PSP	Message	Payer PSP receives the CAMT.029 message, in response to the CAMT.055 message.
12	Payer PSP	Action	Payer PSP stores the cancellation of the payment instruction in its internal systems.
13	Payee PSP	Action	Payee PSP validates the billing data again with the recurring information stored in its internal systems.
14	Payee PSP	Communication	Payee PSP sends PAIN.013 message containing the billing data.
15	ICOM	Communication	Payee PSP sends PAIN.013 message containing the billing data.
16	ICOM	Communication	ICOM retransmits the PAIN.013 message to the Payer PSP.
17	Payer PSP	Communication	Payer PSP receives the PAIN.013 message with the billing data.
18	Payer PSP	Action	Payer PSP compares the billing data with the information of the granted authorization and schedules a new payment order for the same day.
19	Payer PSP	Message	Payer PSP sends PAIN.014 message, in response to the PAIN.013 message.
20	ICOM	Message	ICOM receives PAIN.014 message, in response to the PAIN.013 message.
21	ICOM	Message	ICOM retransmits the PAIN.014 message to the Payee PSP.
22	Payee PSP	Message	Payee PSP receives the PAIN.014 message, in response to the PAIN.013 message.
23	Payee PSP	Action	Payee PSP stores the scheduling information in its internal systems. End of process.

When a transaction originating from a previously sent payment instruction is not settled (e.g., due to SPI unavailability, or the Payee PSP's unavailability, or even rejection of the PACS.008 by the SPI or by the Payee PSP), the E2EId of that message cannot be used again. Thus, it is first necessary for the Payer PSP to cancel the original PAIN.013 message as described in item 5.2.3 of this Manual (in this case, the notification steps to the Payer User do not apply), that is, by sending a CAMT.055 message to the Payee PSP, which, upon receiving it, must confirm the cancellation of the scheduling by sending a CAMT.029 message to the Payer PSP. Subsequently, the Payee PSP must send a new PAIN.013 to the Payer PSP, with the billing data, so that the Payer PSP can generate a new PACS.008 with the new E2EID, to be settled on the same date.

For the process of new attempts after maturity (in this case, due to insufficient balance on the date scheduled for the billing settlement, for example), the Payee PSP that does not identify the settlement of the scheduling on the scheduled date sends a new PAIN.013 to the Payer PSP, so that it can reschedule and make the payment.

5.2.2.2. When the Payer PSP and the Payee PSP are the same institution

#	Layer	Type	Description
1	PSP	Action	Start of process. Payer PSP identifies that the settlement of the payment order did not occur due to an error in the settlement flow.
2	PSP	Action	Payer PSP registers that the payment order was not settled in its internal systems.
3	PSP	Action	Payer PSP compares the billing data with the information of the granted authorization and schedules a new payment order for the same day. End of process.

95 • Manual of Flows for the Pix Execution Process Internal

5.2.3. Cancellation by the Payer User of a Scheduled Debit

5.2.3.1. When the Payer PSP and the Payee PSP are different institutions

96 • Manual of Flows for the Pix Execution Process Internal

#	Layer	Type	Description
1	Payer User	Communication	Start of process. Payer User requests the cancellation of the scheduled debit to the Payer PSP.
2	Payer PSP	Communication	Payer PSP receives the cancellation request of the scheduled debit.
3	Payer PSP	Action	Payer PSP cancels the scheduled debit in its internal systems.
4	Payer PSP	Communication	Payer PSP sends notification to the Payer User, confirming the cancellation of the scheduled debit.
5	Payer User	Communication	Payer User receives notification of confirmation of the cancellation of the scheduled debit.
6	Payer PSP	Message	Payer PSP sends CAMT.055 message to inform the cancellation of the scheduled debit.
7	ICOM	Message	ICOM receives CAMT.055 message informing the cancellation of the scheduled debit.
8	ICOM	Message	ICOM retransmits the CAMT.055 message to the Payee PSP.
9	Payee PSP	Message	Payee PSP receives the CAMT.055 message informing the cancellation of the scheduled debit.
10	Payee PSP	Action	Payee PSP registers the cancellation of the debit scheduling in its internal systems.
11	Payee PSP	Message	Payee PSP sends CAMT.029 message, in response to the CAMT.055 message.
12	ICOM	Message	ICOM receives CAMT.029 message, in response to the CAMT.055 message.
13	ICOM	Message	ICOM retransmits the CAMT.029 message to the Payer PSP.
14	Payer PSP	Message	Payer PSP receives the CAMT.029 message, in response to the CAMT.055 message.
15	Payee PSP	Communication	Payee PSP communicates the cancellation of the scheduled debit to the Payee User.
16	Payee User	Communication	Payee User receives notification of the cancellation of the scheduled debit. End of process.

97 • Manual of Flows for the Pix Execution Process Internal

5.2.3.2. When the Payer PSP and the Payee PSP are the same institution

#	Layer	Type	Description
1	Payer User	Communication	Start of process. Payer User requests the cancellation of the scheduled debit to the PSP.
2	PSP	Communication	PSP receives the cancellation request of the scheduled debit.
3	PSP	Action	PSP cancels the scheduled debit in its internal systems.
4	PSP	Communication	PSP sends notification to the Payer User, confirming the cancellation of the scheduled debit.
5	Payer User	Communication	Payer User receives notification of confirmation of the cancellation of the scheduled debit.
6	PSP	Communication	PSP communicates the cancellation of the scheduled debit to the Payee User.
7	Payee User	Communication	Payee User receives notification of the cancellation of the scheduled debit. End of process.

98 • Manual of Flows for the Pix Execution Process Internal

5.2.4. Cancellation by the Payee User of a Scheduled Debit

5.2.4.1. When the Payer PSP and the Payee PSP are different institutions

99 • Manual of Flows for the Pix Execution Process Internal

#	Layer	Type	Description
1	Payee User	Communication	Start of process. Payee User requests the cancellation of the billing to the Payee PSP.
2	Payee PSP	Communication	Payee PSP receives the cancellation request of the billing.
3	Payee PSP	Action	If the billing data for scheduling has not yet been sent to the Payer PSP, proceed to step 4. If it has already been sent, proceed to step 7.
4	Payee PSP	Action	Payee PSP cancels the billing in its internal systems.
5	Payee PSP	Communication	Payee PSP sends notification to the Payee User, confirming the cancellation of the billing.
6	Payee User	Communication	Payee User receives notification of confirmation of the cancellation of the billing. End of process.
7	Payee PSP	Message	If the billing data has already been sent, Payee PSP sends CAMT.055 message to inform the cancellation of the billing.
8	ICOM	Message	ICOM receives CAMT.055 message informing the cancellation of the billing.
9	ICOM	Message	ICOM retransmits the CAMT.055 message to the Payer PSP.
10	Payer PSP	Message	Payer PSP receives the CAMT.055 message informing the cancellation of the billing.
11	Payer PSP	Action	Payer PSP cancels the debit scheduling regarding the cancelled billing in its internal systems.
12	Payer PSP	Communication	Payer PSP communicates the cancellation of the scheduled debit to the Payer User.
13	Payer User	Communication	Payer User receives notification of the cancellation of the scheduled debit. End of process.
14	Payer PSP	Message	Payer PSP sends CAMT.029 message, in response to the CAMT.055 message.
15	ICOM	Message	ICOM receives CAMT.029 message, in response to the CAMT.055 message.
16	ICOM	Message	ICOM retransmits the CAMT.029 message to the Payee PSP.
17	Payee PSP	Message	Payee PSP receives the CAMT.029 message, in response to the CAMT.055 message, confirming the cancellation of the debit scheduling regarding the cancelled billing.
18	Payee PSP	Action	Payee PSP cancels the billing in its internal systems.
19	Payee PSP	Communication	Payee PSP sends notification to the Payee User, confirming the cancellation of the billing.
20	Payee User	Communication	Payee User receives notification of confirmation of the cancellation of the billing. End of process.

100 • Manual of Flows for the Pix Execution Process Internal

5.2.4.2. When the Payer PSP and the Payee PSP are the same institution

#	Layer	Type	Description
1	Payee User	Communication	Start of process. Payee User requests the cancellation of the billing to the PSP.
2	PSP	Communication	PSP receives the cancellation request of the billing.
3	PSP	Action	PSP cancels the billing and the respective scheduled debit in its internal systems.
4	PSP	Communication	PSP sends notification to the Payee User, confirming the cancellation of the billing.
5	Payee User	Communication	Payee User receives notification of confirmation of the cancellation of the billing.
6	PSP	Communication	PSP communicates the cancellation of the scheduled debit to the Payer User.
7	Payer User	Communication	Payer User receives notification of the cancellation of the scheduled debit. End of process.

101 • Manual of Flows for the Pix Execution Process Internal

Revision History

Date	Version	Description of Changes
11/8/2020	1.0	Initial version.
10/9/2020	1.1	Adjustment in flow 2.3, regarding the generation of the payment order by dynamic QR Code. The flow is exactly the same as the flow for generating the payment order by static QR Code. After the Payer User reads the dynamic QR Code, Payer PSP sends the key contained in the QR payload to the DICT. After the DICT returns, Payer PSP presents the payload information and the Payee User information to the Payer User, requesting payment confirmation.
22/7/2021	1.2	Structure: insertion of subsection 2.1.3 “Payment Transaction Initiation Service Provider, with direct access to the DICT”. Structure: insertion of subsection 2.4 “Generation of the payment order by the Payment Transaction Initiation Service Provider, in cases where the participant has all the information of the Payee User”. Section 2.3: detailing of the step-by-step table, to better explain the process of generating the order by dynamic QR Code.
29/9/2021	1.3	Adjustment in flow 2.2 “Generation of the payment order by static QR Code” and in the table. Structure: insertion of subsection 2.3.1 “Pix Billing for immediate payment”. Structure: insertion of subsection 2.3.2 “Pix Billing for payment with maturity”. Structure: insertion of section 2.4 “Generation of the payment order of a Scheduled Pix by manual data entry or by means of a Pix key”. Structure: numbering adjustments in the subsequent subsection 2.5. “Generation of the payment order by the Payment Transaction Initiation Service Provider, in cases where the participant has all the information of the Payee User.”
29/10/2023	1.4	Section 3.1: adjustment in the explanatory text and in the flow to define the payment orders that must be sent to the primary message transmission channel of the SPI and to the secondary message transmission channel of the SPI. Section 3.2: adjustment in the explanatory text and in the flow to define the payment orders that must be sent to the primary message transmission channel of the SPI and to the secondary message transmission channel of the SPI.

103 • Manual of Flows for the Pix Execution Process Internal

Section 3.3: adjustment in the explanatory text and in the flow due to the creation of the secondary message transmission channel of the SPI.
Section 3.4: adjustment in the explanatory text and in the flow due to the creation of the secondary message transmission channel of the SPI.

30/08/2024 2.0 Section 3: inclusion of flows with scheduled settlement of the payment order (Scheduled Pix, Recurring Scheduled Pix, and Pix Cobrança with due date). Structure: insertion of section 5 – Flows of Automatic Pix. Structure: general review of the flows and explanatory texts.

05/06/2025 2.1 Structure: insertion of subsection 2.6 “Generation of payment order by proximity (NFC)”.
Section 3.1: adjustment in the explanatory text to include Automatic Pix among the payment orders that must be sent to the secondary message transmission channel of the SPI.
Section 5: adjustment in the explanatory text to indicate the flows of Automatic Pix that occur in the primary message transmission channel of the SPI and in the secondary message transmission channel of the SPI.
Section 5.1.3.1: adjustment in the explanatory text to emphasize that the Receiving PSP must wait for the completion of the settlement flow of the first immediate payment before proceeding to the step of updating the recurrence status.
Section 5.1.5.1: adjustment in the explanatory text to point out that after the cancellation of the recurrence, if there are pending schedules to be cancelled, the responsibility for their cancellation is that of the Payer User’s PSP.
Section 5.1.5.2: adjustment in the explanatory text to point out that after the cancellation of the recurrence, if there are pending schedules to be cancelled, the responsibility for their cancellation is that of the Payer User’s PSP.

Instruction Normative BCB No. 631 — Discloses Version 2.1 of the Manual of Flows of the Pix Execution Process, which composes the Pix Regulation

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Layer Type Description

Pix Execution Process Flows Manual

5.1.3.2. When the Payer's PSP and the Payee's PSP are the same institution

5.1.4. Journey 4 – User pays via QR Code and receives a proposal to enable Pix Automatic for future recurring charge payments

5.1.4.1. When the Payer's PSP and the Payee's PSP are different institutions

5.1.4.2. When the Payer's PSP and the Payee's PSP are the same institution

5.1.5. Cancellation of authorization by the Payer User

5.1.5.1. When the Payer's PSP and the Payee's PSP are different institutions

Lineage: Superseded

Timeline