Instruction Normative BCB No. 766 — Publishes Version 8.5 of the Operational Manual of the Transactional Account Identifiers Directory (DICT), which comprises the Pix Regulation

The Head of the Department of Competition and Financial Market Structure (Decem), using the powers conferred by Articles 23, item I, letter “a”, and 94, item IX, of the Internal Regulations of the Central Bank of Brazil, annexed to Resolution BCB No. 340, of September 21, 2023, and considering the provisions of Article 2, item X, of the Regulation annexed to Resolution BCB No. 1, of August 12, 2020,

RESOLVES:

Art. 1º This Instruction Normative publishes version 8.5 of the Operational Manual of the Transactional Account Identifiers Directory (DICT), which comprises the Pix Regulation, as per Article 2 of the Regulation annexed to Resolution BCB No. 1, of August 12, 2020.

Sole Paragraph. The DICT Operational Manual is available at the Central Bank of Brazil’s internet address: https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/X_ManualOperacionaldoDICT.pdf

Art. 2º Instruction Normative BCB No. 752, of July 1, 2026, is hereby revoked.

Art. 3º This Instruction Normative enters into force:

I - on August 10, 2026, for the changes in sections 10.1 and 20.1.5; and

II - on September 1, 2026, for the changes in sections 20.1.1, 20.1.9 and 20.2 and for the revocation referred to in Article 2.

RICARDO TEIXEIRA LEITE MOURÃO

ANNEX TO INSTRUCTION NORMATIVE BCB NO. [766] OF JULY 27, 2026

Operational Manual of the Transactional Account Identifiers Directory (DICT)

Revision History

Date

Version

Description of changes

11/8/2020

1.0

10/9/2020

1.1

Section 6: Adjustments to the wording of the claim flow, to clarify its operation:

if the donor user does not respond within the resolution period, the donor PSP must necessarily confirm the claim in the DICT; in the closing period, the donor user can only validate ownership of the key, canceling the process. Confirmation is not possible during this period; and provision that the claiming PSP must cancel the claim process in the DICT if its user does not perform active validation of the key by the thirtieth day after the start of the claim process.

Section 6.1: adjustments in steps 5 and 7, to make the wording clearer and to incorporate the adjustments made in section 6.

Section 6.2: adjustments in steps 7, 11, 12 and 13, to make the wording clearer and to incorporate the adjustments made in section 6.

Section 6.3:

adjustment in the flow; and adjustments in steps 4, 12, 14, 15, 16, 17, 19 and 20, to make the wording clearer and to incorporate the adjustments made in section 6.

Section 6.4:

adjustment in the flow; and adjustments in steps 6, 16, 18, 20, 21, 22, 23, 27 and 28, to make the wording clearer and to incorporate the adjustments made in section 6.

Section 9: adjustment to clarify that synchronization verification does not need to be performed daily. It needs to be performed at maximum intervals of 36 hours, as per the Pix Times Manual.

Section 10: adjustment to provide that the infraction notification can be canceled at any time.

Section 10.1: adjustment in the nomenclature of messages sent to the DICT.

Section 10.2: adjustment in the nomenclature of messages sent to the DICT.

13/11/2020

2.0

Structure: insertion of section 15 “Limitation of requests to the DICT API”.

Section 5: insertion of a footnote to clarify that it is possible to update account data linked to the key while the status of the portability request is “Open” or “Awaiting Resolution”.

Section 6: insertion of a footnote to clarify that it is possible to update account data linked to the key while the status of the ownership claim request is “Open” or “Awaiting Resolution”.

Section 9: insertion of text to detail how the process of correcting divergent keys after a synchronization verification should be.

Section 10: removal of the “Reason” field in the process of opening an infraction notification.

Section 14: removal of the information stored by the DICT related to transactions suspected of violating regulations on anti-money laundering and financing of terrorism.

17/11/2020

2.1

Section 9: guidance that any discrepancies found between the internal database and the DICT, after the synchronization verification process, should be corrected in the internal database.

18/3/2021

3.0

Structure: insertion of sections 16 “Flow of verification of registered Pix keys” and 17 “Cache of Pix key existence”.

Section 7.1: adjustment in the flow and step-by-step table, to provide for the possibility of changing the name of the user linked to the Pix key.

Section 7.2: adjustment in the flow and step-by-step table, to provide for the possibility of changing the name of the user linked to the Pix key.

Section 15: adjustment of form and text in the table detailing the rate limit policy, with the inclusion of limits for keys.read.

8/6/2021

4.0

Structure: insertion of section 18 “Flow of refund request”.

Structure: insertion of subsections 10.3 “Flow of infraction notification for opening refund request (Pix participants with direct access to the DICT)” and 10.4 “Flow of infraction notification for opening refund request (Pix participants with indirect access to the DICT)”.

Section 5: provision for the possibility of canceling a portability with status “Confirmed” by the claiming PSP.

Section 10: insertion of the “Reason” field and detailing of fields when opening an infraction notification; detailing of fields when closing an infraction notification; and detailing of the operation of the infraction notification flow for opening a refund request.

Section 10.1: change of section name to “Flow of infraction notification between Pix participants with direct access to the DICT, for ‘fraud’ reason”.

Section 10.1: maximum deadline for opening an infraction notification becomes eighty calendar days (step 2).

Section 10.1: maximum deadline for analyzing an infraction notification becomes seven days (step 7).

Section 10.2: change of section name to “Flow of infraction notification between Pix participants with indirect access to the DICT, for ‘fraud’ reason”.

Section 10.2: maximum deadline for opening an infraction notification becomes eighty calendar days (step 2).

Section 10.2: maximum deadline for analyzing an infraction notification becomes seven days (step 14).

Section 13: maximum size of the end-user bucket becomes 1,000 tokens, with a temporal increment of 2 tokens per minute; maximum size of the participant bucket becomes 20,000 tokens, with a temporal increment of 6,000 tokens per minute; and insertion of text to give flexibility to the Central Bank of Brazil in managing the buckets.

Section 15: adjustments in the table with the limits of requests to the DICT API.

29/6/2021

4.1

Section 15: incorporation of new request limits to the DICT API.

22/7/2021

4.2

Structure: insertion of subsections 8.3 “Flow of consultation for the Pix participant acting as a payment transaction initiation service provider, with direct access to the DICT” and 8.4 “Flow of consultation for the Pix participant acting as a payment transaction initiation service provider, with indirect access to the DICT”.

Section 10: inclusion of footnotes 6 and 7, to clarify the date from which the deadlines related to infraction notification will start to apply.

Section 13: insertion of read-attack prevention mechanisms for participants providing payment transaction initiation services.

Section 15: inclusion of footnote 10, to clarify that the same limits for verification of registered Pix keys are applicable to initiating participants.

24/8/2021

4.3

Section 10: insertion of footnote to clarify that the infraction notification for opening a refund request will be available only from November 16, 2021, in accordance with Resolution BCB No. 103.

Section 13: adjustments to the DICT read-attack prevention mechanisms. Unsettled queries for all types of keys will now consume tokens in the buckets, for both end-users and participants. For this, a new bucket was created, with 1,000 tokens, for CPF, CNPJ and random keys for end-users; and the temporal increment of tokens for participants was increased.

Section 13: insertion of footnote to explain the new rules for forming the PayerId field.

Section 15: creation of a specific bucket for the updateEntry endpoint. As a result, the bucket for createEntry and deleteEntry was reduced.

Section 18: adjustment in footnote, to clarify that the refund request will be available only from November 16, 2021, in accordance with Resolution BCB No. 103.

21/9/2021

4.4

Section 10: insertion of text to make the operation of the functionality clearer.

Section 10.3: insertion of footnotes to clarify the cases in which the Special Refund Mechanism cannot be triggered.

Section 10.4: insertion of footnotes to clarify the cases in which the Special Refund Mechanism cannot be triggered.

Section 13: adjustments to the DICT read-attack prevention mechanisms. Separation of buckets for PF and PJ user queries, with definition of differentiated parameters, through identification of the person type by the PayerID field. In addition, participant query buckets will now have categories with differentiated size and increment parameters, to suit the needs of each participant.

Section 13: adjustment in footnote 13, to clarify the format to be used in the PayerId field.

Section 15: removal of the general entries.read policy and inclusion of footnote, to explain that this policy is being treated in more detail in section 13. In addition, the parameters of the update.entries policy were reduced.

Section 18: insertion of text to make the operation of the functionality clearer.

Section 18.2: adjustment in step 15, to make the text clearer.

Section 18.3: adjustment in the flow, to fix step 4, which was identifying a state incorrectly.

Section 18.4: adjustment in the flow, to fix step 6, which was identifying a state incorrectly.

Section 18.5: insertion of footnotes, to make the operation of the functionality clearer.

3/11/2021

5.0

Structure: insertion of section 19 “Consultation of information linked to Pix keys for Pix security purposes”.

Section 8.1: alteration in step 7 of the flow, to change the way the payer user is identified in the consultation (payer user must be identified by their CPF/CNPJ, and no longer by a pseudonymized identifier).

Section 8.1: alteration in step 9 of the flow, to change the way the payer user is identified in the consultation (payer user must be identified by their CPF/CNPJ, and no longer by a pseudonymized identifier).

Section 10: adjustments to the text to provide for the new fields that will allow infraction notification for transactions settled outside the SPI and for rejected transactions.

Section 10.1: adjustments to explain how the flow should be interpreted in cases of transactions settled outside the SPI and rejected transactions.

Section 10.2: adjustments to explain how the flow should be interpreted in cases of transactions settled outside the SPI and rejected transactions.

Section 13: alteration in the way the payer user is identified in the consultation (payer user must be identified by their CPF/CNPJ, and no longer by a pseudonymized identifier).

Section 14: alteration in the information for security purposes returned by the DICT whenever a key is consulted.

19/11/2021

5.1

Section 14: the information for security purposes regarding 3 days will continue, provisionally, to be presented whenever a key is consulted.

Section 15: insertion of the limitation of requests to the endpoint “statistics_read”.

Section 18: insertion of a new domain in the “RefundRejectionReason” field.

Section 19: provision that information about rejected transactions that suffered infraction notification will also be returned in the consultation of information linked to Pix keys.

12/1/2022

5.2

Section 10: adjustment in the text to provide that, in “INTERNAL” transactions where the payer PSP and the payee PSP have the same settler, the counterparty that did not open the notification is the one that closes the notification, agreeing or disagreeing.

Section 16.1: adjustment in the flow and step-by-step table due to the possibility of verifying registration of all types of Pix keys.

Section 16.2: adjustment in the flow and step-by-step table due to the possibility of verifying registration of all types of Pix keys.

Section 17: adjustments in the text due to the possibility of verifying registration of all types of Pix keys.

11/2/2022

5.3

Section 13: alteration in the way of replenishing tokens in the DICT query buckets, which will now be replenished after receipt of the payment order by the SPI in PACS.008, and no longer after a settlement.

Section 15: inclusion of the information in footnote of the maximum quantity of 200 (two hundred) keys capable of being verified by each request of the checkKeys operation.

1/9/2022

5.4

Section 8.3: adjustment in step 5, to provide that the EndToEndId of a transaction must be generated by the service provider of initiation.

Section 8.4: adjustment in step 5, to provide that the EndToEndId of a transaction must be generated by the service provider of initiation.

Section 13: participants providing initiation services must now use the same endpoint for key consultation as account transaction service provider participants. As a consequence, the rules of limits and of decrease and increase of tokens will be the same for all participants.

Section 15: increase of the bucket increment and maximum bucket size for the statistics_read transaction.

3/10/2022

6.0

Structure: insertion of section 20 “Bucket Consultation”.

Section 10.3: adjustment in the step-by-step table (step 12), to clarify that there is no specification of value to be refunded in an infraction notification.

Section 10.4: adjustment in the step-by-step table (step 16), to clarify that there is no specification of value to be refunded in an infraction notification.

Section 13: (i) increase from 10 to 20 in the decrease of tokens per invalid query of any key, for natural person and legal entity users; (ii) increase from 8,000 to 12,000 and from 5,000 to 8,000 in the increment of tokens per minute of buckets in categories A and B, respectively; and (iii) adjustment in the maximum bucket size for end-user natural person and legal entity.

Section 15: (i) change in the name of the rate limit policy from keys.read to keys.check; and (ii) inclusion of new rate limit policies.

2/1/2023

6.1

Section 10: adjustments in the text to emphasize that the payer PSP must open the infraction notification in the DICT immediately after the payer user’s complaint.

Section 10.3: adjustment in the flow and step-by-step table to remove the condition in which the PSP cannot trigger the MED.

Section 10.4: adjustment in the flow and step-by-step table to remove the condition in which the PSP cannot trigger the MED.

Section 18: (i) adjustment in the text to clarify that the request for cancellation of refund must be created by the payee PSP; (ii) inclusion of detail about the monitoring to be performed by the PSP in case of partial refunds; and (iii) removal of the condition in which the PSP cannot trigger the MED.

Section 18.1: adjustment in the flow and step-by-step table to remove the condition in which the PSP cannot trigger the MED.

Section 18.2: adjustment in the flow and step-by-step table to remove the condition in which the PSP cannot trigger the MED.

Section 18.3: adjustment in the flow and step-by-step table to remove the condition in which the PSP cannot trigger the MED.

Section 18.4: adjustment in the flow and step-by-step table to remove the condition in which the PSP cannot trigger the MED.

5/11/2023

7.0

Structure: exclusion of section 14 “Information linked to keys for security purposes” and renumbering of subsequent sections

Section 8: inclusion of the information returned by the DICT when a key is consulted.

Section 10: restructuring of the section, with creation of two subsections: one to detail the infraction notification for refund request or cancellation of refund; and another to detail the infraction notification for transactional fraud marking. The detailing of the functionality was updated to include new security information to be shared with participants. Subsections 10.1 and 10.2 of the previous version were transformed into subsections 10.2.1 and 10.2.2, respectively, with adjustments in the flow. Subsections 10.3 and 10.4 of the previous version were transformed into subsections 10.1.1 and 10.1.2, respectively. Two new subsections, 10.1.3 and 10.1.4, were also created to detail, respectively, the infraction notification flow of type “cancellation of refund” between participants with direct access to the DICT and the infraction notification flow of type “cancellation of refund” between participants with indirect access to the DICT

Section 13: creation of two subsections: 13.1 Mechanisms adopted by the DICT (which kept the text of the previous version, with the update of the token credit policy in transactions involving service providers of initiation and the detailing of the limitation policy for the new operation getEntryStatistics) and 13.2 Mechanisms that must be adopted by Pix participants.

Section 14 (corresponds to section 15 of the previous version): adjustment in the request limit policy of the getPersonStatistics operation and creation of the request limit policy for the new operations getEntryStatistics and createFraudMarker.

Section 17 (corresponds to section 18 of the previous version): adjustment in the text to clarify that the account must be monitored in case of partial refund or rejection of the refund request, provided that the transactional account has not been closed by the user or by the PSP itself.

Section 18 (corresponds to section 19 of the previous version): complete restructuring of the section, including its title, to reflect the new security information that will be returned by the DICT when a CPF, a CNPJ or a key is consulted in the statistics endpoint.

Section 18.1 (corresponds to section 19.1 of the previous version): adjustment in the title and flow.

Section 18.2 (corresponds to section 19.2 of the previous version): adjustment in the title and flow.

1/12/2023

7.1

Section 13.1: Inclusion of two new bucket categories for participants in the DICT read-attack prevention mechanism and adjustments in the maximum size and temporal increment parameters of the buckets.

Section 17.5: Insertion of determination that the payer PSP, if it accepts the infraction notification for cancellation of refund, must immediately cancel the infraction notification for refund request that it created to request the refund of the original transaction.

2/5/2024

7.2

Section 5: Adjustment in the text to inform that a portability can be canceled by the claiming PSP while the status of the request is “Open”.

Section 6: Adjustment in the text to inform that an ownership claim can be canceled by the claiming PSP while the status of the request is “Open”.

Section 10.1: Insertion of explanation about infraction notification against payee user acting as payment intermediary.

Section 10.1: Insertion of determination that the payer PSP must cancel the opened refund request if it has canceled the infraction notification that gave rise to it. If there has been a refund, the payer PSP must return the resources to the payee PSP through a new Pix transaction and open an infraction notification for fraud marking against its user if it concludes that the user acted in bad faith.

Section 13.1: Increase of the replenishment rate per query of any key after receipt of the payment order by the SPI to 2 tokens for the PJ user bucket and increase of the temporal increment to 20 tokens every minute in each PJ user bucket.

Section 13.1: Insertion of the information that, exceptionally, at the discretion of the Central Bank of Brazil, the bucket parameters of a PJ user can be altered.

Section 13.1: Inclusion of passage in the footnote to clarify that requests for bucket category increase must be properly grounded in historical data, and not in future projections.

Section 17: Inclusion of passage to allow the payee PSP to end monitoring of the payee user’s account if the infraction notification for refund request is canceled by the payer PSP.

02/09/2024

7.3

Section 1: creation of subsection 1.1 for guidance on keys blocked by judicial order

Section 8: restructuring of the section, with creation of subsection 8.1 to detail which information must be displayed to the user in key consultation. Subsections 8.1, 8.2, 8.3 and 8.4 of the old version were transformed into 8.2, 8.3, 8.4 and 8.5 respectively

Section 8.2 (old 8.1): insertion of text, in the flow table, to clarify that key data can be informed manually or via QR Code reading.

Section 8.3 (old 8.2): insertion of text, in the flow table, to clarify that key data can be informed manually or via QR Code reading. Insertion of one more step for the PSP with direct access to the DICT, to verify if the key is registered in its internal database.

Section 8.4 (old 8.3): insertion of text, in the flow table, to clarify that key data can be informed manually or via QR Code reading.

Section 8.5 (old 8.4): insertion of text, in the flow table, to clarify that key data can be informed manually or via QR Code reading. Insertion of one more step for the PSP with direct access to the DICT, to verify if the key is registered in its internal database.

Section 10: Inclusion of social engineering scams and exclusion of text that restricted the possibilities of framing as fraud.

Section 10.1: Exclusion of text that restricted the possibilities of framing as fraud in the “scam” domain.

Section 13: creation of subsection 13.2.5 with the restrictions of the key data displayed to the user making the consultation.

Section 13.1: Inclusion of explanatory text of the bucket operation when it has few tokens (fewer tokens than the penalty of a query with return of invalid key).

Section 13.2.3: Correction of the relationship between existing and non-existing keys for monitoring purposes (NOT FOUND/(NOT FOUND+FOUND)). In the footnote, the correction of the same relationship and change of the parameter from 30% to 20% in user monitoring. Inclusion of text to clarify that the checkKeys endpoint of the DICT is for exclusive use by the PSP, and should not be made available, even indirectly, to users.

Section 16: Inclusion of text to reinforce that the Pix key existence cache should not serve as a basis for a service made available to the user. Inclusion of text to clarify that the checkKeys endpoint of the DICT is for exclusive use by the PSP.

Section 18: corrections of the DICT response texts to align with the DICT API terminology.

16/06/2025

Section 10: Inclusion, in the footnote, of text to include authorization of automatic Pix in the possibilities of fraud.

Section 17: Inclusion of the payer PSP error in sending a payment order regarding Automatic Pix as one of the cases of possibility of opening a refund request created by the payer PSP. Inclusion in the table in the Reason field the description: payer PSP error in sending a payment order