Normative Instruction BCB No. 752 — Publishes Version 8.4 of the Operational Manual of the Transactional Account Identifiers Directory (DICT)

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 Normative Instruction publishes version 8.4 of the Operational Manual of the Transactional Account Identifiers Directory (DICT), which constitutes 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 following electronic address of the Central Bank of Brazil on the internet: https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/X_ManualOperacionaldoDICT.pdf

Art. 2 Normative Instruction BCB No. 742, of June 9, 2026, is hereby revoked.

Art. 3 This Normative Instruction enters into force on the date of its publication.

RICARDO TEIXEIRA LEITE MOURÃO

ANNEX TO NORMATIVE INSTRUCTION BCB NO. 752 OF JULY 1, 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 manifest within the resolution period, the donor PSP must necessarily confirm the claim in the DICT; during 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 the synchronization check does not need to be performed daily. It must be performed at maximum intervals of 36 hours, as per the Pix Time Manual.
Section 10: adjustment to provide that the infringement 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 check should be.
Section 10: removal of the “Reason” field in the process of opening an infringement notification.
Section 14: removal of information stored by the DICT regarding transactions suspected of violating regulations on anti-money laundering and counter-terrorism financing.
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 sub-sections 10.3 “Flow of infringement notification for opening refund request (Pix participants with direct access to the DICT)” and 10.4 “Flow of infringement 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 infringement notification; detailing of fields when closing an infringement notification; and detailing of the operation of the infringement notification flow for opening a refund request.
Section 10.1: change of section name to “Flow of infringement notification between Pix participants with direct access to the DICT, for reason ‘fraud’”.
Section 10.1: maximum deadline for opening an infringement notification becomes eighty calendar days (step 2).
Section 10.1: maximum deadline for analyzing an infringement notification becomes seven days (step 7).
Section 10.2: change of section name to “Flow of infringement notification between Pix participants with indirect access to the DICT, for reason ‘fraud’”.
Section 10.2: maximum deadline for opening an infringement notification becomes eighty calendar days (step 2).
Section 10.2: maximum deadline for analyzing an infringement 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 every minute; maximum size of the participant bucket becomes 20,000 tokens, with a temporal increment of 6,000 tokens every 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 sub-sections 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 infringement notifications 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 infringement 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 clarify the operation of the functionality.
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 queries from natural person (PF) and legal person (PJ) users, 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 clarify the operation of the functionality.
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 clarify the operation of the functionality.
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 (the 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 (the 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 infringement 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 (the 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 field “RefundRejectionReason”.
Section 19: provision that information about rejected transactions that underwent infringement 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 clearing house, the party that closes the notification, agreeing or disagreeing, is the counterparty that did not open the notification.
Section 16.1: adjustment in the flow and step-by-step table due to the possibility of verification of registration of all types of Pix keys.
Section 16.2: adjustment in the flow and step-by-step table due to the possibility of verification of registration of all types of Pix keys.
Section 17: adjustments in the text due to the possibility of verification of registration of all types of Pix keys.
11/2/2022	5.3	Section 13: alteration in the mode of token replenishment of 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 footnote information on 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 initiation service provider.
Section 8.4: adjustment in step 5, to provide that the EndToEndId of a transaction must be generated by the initiation service provider.
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 now 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 infringement 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 infringement 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 person 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 person.
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 infringement notification in the DICT immediately after the complaint of the payer user.
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 sub-sections: one to detail the infringement notification for refund request or cancellation of refund; and another to detail the infringement notification for marking transactional fraud. The detailing of the functionality was updated to include new security information to be shared with participants. Sub-sections 10.1 and 10.2 of the previous version were transformed into sub-sections 10.2.1 and 10.2.2, respectively, with adjustments in the flow. Sub-sections 10.3 and 10.4 of the previous version were transformed into sub-sections 10.1.1 and 10.1.2, respectively. Two new sub-sections, 10.1.3 and 10.1.4, were also created to detail, respectively, the infringement notification flow of type “cancellation of refund” between participants with direct access to the DICT and the infringement notification flow of type “cancellation of refund” between participants with indirect access to the DICT.
Section 13: creation of two sub-sections: 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 initiation service providers 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 operation getPersonStatistics 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, CNPJ, or 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 infringement notification for cancellation of refund, must immediately cancel the infringement 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 infringement notification against payee user acting as payment intermediary.
Section 10.1: Insertion of determination that the payer PSP must cancel the open refund request if it has canceled the infringement notification that gave rise to it. If a refund has occurred, the payer PSP must return the funds to the payee PSP through a new Pix transaction and open an infringement 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 information that, exceptionally, at the discretion of the Central Bank of Brazil, the bucket parameters of a PJ user may be altered.
Section 13.1: Inclusion of excerpt in the footnote to clarify that requests for bucket category increase must be duly justified by historical data, and not by future projections.
Section 17: Inclusion of excerpt to allow the payee PSP to end monitoring of the payee user's account if the infringement notification for refund request is canceled by the payer PSP.
02/09/2024	7.3	Section 1: creation of sub-section 1.1 for guidance on keys blocked by judicial order.
Section 8: restructuring of the section, with creation of sub-section 8.1 to detail which information must be displayed to the user in key consultation. Sub-sections 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 sub-section 13.2.5 with the restrictions of the key data displayed to the user who makes the consultation.
Section 13.1: Inclusion of explanatory text on the operation of the bucket 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, correction of the same relationship and change of the parameter from 30% to 20% in user monitoring. Inclusion of text to clarify that the DICT checkKeys endpoint 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 the basis for a service made available to the user. Inclusion of text to clarify that the DICT checkKeys endpoint is for exclusive use by the PSP.
Section 18: corrections of the DICT response texts to align with the terminology of the DICT API.
16/06/2025		Section 10: Inclusion, in the footnote, of text to include automatic Pix authorization 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 regarding Automatic Pix (pix_automatico). Inclusion of footnote for explanation that operational error in an Automatic Pix transaction is not included in the reason operational failure...