Operational Manual of the Transactional Account Identifiers Directory (DICT) - Version 8.3

1 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3 Operational Manual of the Transactional Account Identifiers Directory (DICT) Version 8.3

2 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3
Table of Contents
1 PIX KEYS ................................................................................................................................................ 5
1.1 KEYS BLOCKED BY JUDICIAL ORDER ....................................................................................................... 5
2 VALIDATION OF PIX KEYS...................................................................................................................... 5
2.1 VALIDATION OF KEY POSSESSION....................................................................................................................... 5
2.2 VALIDATION OF THE USER'S REGISTRATION STATUS WITH THE FEDERAL REVENUE SERVICE ................................................................. 6
2.3 VALIDATION OF NAMES LINKED TO PIX KEYS ........................................................................................... 6
3 KEY REGISTRATION FLOW .................................................................................................................. 8
3.1 KEY REGISTRATION FLOW INITIATED BY THE END USER (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT)
8
3.2 KEY REGISTRATION FLOW INITIATED BY THE END USER (PIX PARTICIPANTS WITH INDIRECT ACCESS TO
DICT) 11
3.3 KEY REGISTRATION FLOW INITIATED BY THE PARTICIPANT (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT) ..... 14
3.4 KEY REGISTRATION FLOW INITIATED BY THE PARTICIPANT (PIX PARTICIPANTS WITH INDIRECT ACCESS TO DICT) .. 15
4 KEY EXCLUSION FLOW ............................................................................................................... 17
4.1 KEY EXCLUSION DUE TO DATA INCOMPATIBILITY WITH THE FEDERAL REVENUE SERVICE ................................................. 17
4.2 KEY EXCLUSION FLOW INITIATED BY THE END USER (PIX PARTICIPANTS WITH DIRECT ACCESS TO
DICT) 17
4.3 KEY EXCLUSION FLOW INITIATED BY THE END USER (PIX PARTICIPANTS WITH INDIRECT ACCESS TO
DICT) 18
4.4 KEY EXCLUSION FLOW INITIATED BY THE PARTICIPANT (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT) .... 20
4.5 KEY EXCLUSION FLOW INITIATED BY THE PARTICIPANT (PIX PARTICIPANTS WITH INDIRECT ACCESS TO DICT).. 22
5 KEY PORTABILITY FLOW ...................................................................................................... 23
5.1 PORTABILITY FLOW TO THE CLAIMANT PSP WITH DIRECT ACCESS TO DICT............................................. 24
5.2 PORTABILITY FLOW TO THE CLAIMANT PSP WITH INDIRECT ACCESS TO DICT .......................................... 26
5.3 PORTABILITY FLOW TO THE DONOR PSP WITH DIRECT ACCESS TO DICT ...................................................... 28
5.4 PORTABILITY FLOW TO THE DONOR PSP WITH INDIRECT ACCESS TO DICT ................................................... 30
6 KEY POSSESSION CLAIM FLOW....................................................................................... 33
6.1 POSSESSION CLAIM FLOW FOR THE CLAIMANT PSP WITH DIRECT ACCESS TO DICT ................................ 33
6.2 POSSESSION CLAIM FLOW FOR THE CLAIMANT PSP WITH INDIRECT ACCESS TO DICT ............................. 36
6.3 POSSESSION CLAIM FLOW FOR THE DONOR PSP WITH DIRECT ACCESS TO DICT ......................................... 40
6.4 POSSESSION CLAIM FLOW FOR THE DONOR PSP WITH INDIRECT ACCESS TO DICT ...................................... 43
7 FLOW FOR CHANGING DATA LINKED TO THE KEY ..................................................................... 46
7.1 FLOW FOR CHANGING DATA LINKED TO THE KEY (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT).......... 46
7.2 FLOW FOR CHANGING DATA LINKED TO THE KEY (PIX PARTICIPANTS WITH INDIRECT ACCESS TO DICT)....... 48
7.3 CHANGING DATA LINKED TO THE KEY FOR CORRECTION OF INCONSISTENCIES .............................................. 51
8 KEY INQUIRY FLOW............................................................................................................... 51
8.1 KEY DATA PERMITTED FOR DISPLAY TO THE USER .................................................................................... 52
8.2 INQUIRY FLOW FOR THE PIX PARTICIPANT WITH DIRECT ACCESS TO DICT................................................... 52
8.3 INQUIRY FLOW FOR THE PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT................................................ 54
8.4 INQUIRY FLOW FOR THE PIX PARTICIPANT ACTING AS A PAYMENT TRANSACTION INITIATION SERVICE PROVIDER
WITH DIRECT ACCESS TO DICT ............................................................................................................. 57

3 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3
8.5 INQUIRY FLOW FOR THE PIX PARTICIPANT ACTING AS A PAYMENT TRANSACTION INITIATION SERVICE PROVIDER
WITH INDIRECT ACCESS TO DICT .......................................................................................................... 58
9 SYNCHRONISM VERIFICATION FLOW .............................................................................................. 61
9.1 VSYNC VERIFICATION (PIX PARTICIPANT WITH DIRECT ACCESS TO DICT)....................................................... 62
9.2 VSYNC VERIFICATION (PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT).................................................... 63
9.3 CIDS LIST ............................................................................................................................................ 65
9.3.1 Pix participant with direct access ........................................................................................... 65
9.3.2 Pix participant with indirect access ........................................................................................ 66
10 INFRACTION NOTIFICATION FLOW .................................................................................................... 68
10.1 INFRACTION NOTIFICATION FOR REQUEST FOR REFUND............................................................................ 68
10.1.1 Infraction notification flow for opening a refund request................................ 72
10.2 INFRACTION NOTIFICATION FOR MARKING TRANSACTIONAL FRAUD .............................................................. 72
10.2.1 Infraction notification flow for marking transactional fraud between Pix participants
with direct access to DICT .............................................................................................................................. 73
10.2.2 Infraction notification flow for marking transactional fraud between Pix participants
with indirect access to DICT ........................................................................................................................... 74
11 COMMUNICATION INTERFACE................................................................................................................. 75
12 CACHE OF INQUIRED KEYS............................................................................................................ 76
13 MECHANISMS FOR PREVENTION OF READING ATTACKS........................................................................... 76
13.1 MECHANISMS ADOPTED BY DICT.............................................................................................................. 76
13.2 MECHANISMS THAT MUST BE ADOPTED BY PIX PARTICIPANTS ............................................................... 78
13.2.1 Verification of the authenticity of the user requesting the inquiry .................................................. 78
13.2.2 Establishment of an internal policy for limiting inquiries..................................................... 78
13.2.3 Qualitative and permanent monitoring of inquiries ............................................................. 79
13.2.4 Action plan for handling suspicious cases ...................................................................... 80
13.2.5 Restriction of key data displayed to the user making the inquiry.......................................... 80
14 LIMITATION OF REQUESTS TO THE DICT API............................................................................................. 81
15 FLOW FOR VERIFICATION OF REGISTERED PIX KEYS ............................................................................ 82
15.1 FLOW FOR VERIFICATION OF REGISTERED PIX KEYS FOR THE PIX PARTICIPANT WITH DIRECT ACCESS TO DICT ........ 82
15.2 FLOW FOR VERIFICATION OF REGISTERED PIX KEYS FOR THE PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT ..... 83
16 CACHE OF PIX KEY EXISTENCE........................................................................................................ 85
17 FLOW FOR REQUESTING REFUND.................................................................................................. 85
17.1 REQUEST FOR REFUND DUE TO OPERATIONAL FAILURE ...................................................................................... 88
17.1.1 Flow for requesting refund due to "payer PSP operational failure" (participants of
Pix with direct access to DICT) ....................................................................................................................... 89
17.1.2 Flow for requesting refund due to "payer PSP operational failure" (participants of
Pix with indirect access to DICT)..................................................................................................................... 91
17.2 FLOW FOR REQUESTING REFUND DUE TO "FOUNDED SUSPICION OF FRAUD" ....................................................... 95
17.3 FLOW FOR REQUESTING REFUND DUE TO PAYER PSP ERROR IN SENDING PAYMENT ORDER REGARDING
AUTOMATIC PIX ................................................................................................................................................ 95
17.3.1 Flow for requesting refund due to payer PSP error in sending payment order
regarding Automatic Pix (Pix participants with direct access to DICT) ............................................. 95
17.3.2 Flow for requesting refund due to payer PSP error in sending payment order
regarding Automatic Pix (Pix participants with indirect access to DICT) .......................................... 98
18 FLOW FOR INQUIRY INTO SECURITY INFORMATION ........................................................................ 102
18.1 FLOW FOR INQUIRY INTO SECURITY INFORMATION FOR THE PIX PARTICIPANT WITH DIRECT ACCESS TO DICT..... 103

4 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3
18.2 FLOW FOR INQUIRY INTO SECURITY INFORMATION FOR THE PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT.. 104
19 BALDERS INQUIRY ............................................................................................................................ 106
20 VALUE RECOVERY FLOW................................................................................................... 107
20.1 GENERAL RULES......................................................................................................................................... 108
20.1.1 Institution.................................................................................................................................. 109
20.1.2 Tracking .............................................................................................................................. 110
20.1.3 Prioritization ................................................................................................................................... 110
20.1.4 Request for blocking ................................................................................................................ 110
20.1.5 Analysis ......................................................................................................................................... 110
20.1.6 Refund .................................................................................................................................... 111
20.1.7 Unblocking of resources ............................................................................................................ 112
20.1.8 Value recovery for transactions settled in participants' systems................. 112
20.1.9 Contestation of refund transaction due to fraud ................................................................... 113
20.1.10 Cancellation of Value Recovery............................................................................. 113
20.1.11 Alteration of Value Recovery..................................................................................... 114
20.2 FLOW FOR INSTITUTION AND REQUEST FOR BLOCKING...................................................................................... 114
20.3 FLOW FOR ANALYSIS ..................................................................................................................................... 117
20.4 FLOW FOR REFUND ............................................................................................................................... 119
21 EVENT NOTIFICATIONS ................................................................................................................... 126
21.1 EXISTING EVENTS ................................................................................................................................. 127
21.1.1 Related to Value Recovery ..................................................................................... 127
22 REVISION HISTORY.......................................................................................................................... 128

5 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3 1 Pix Keys Pix keys will be stored in the DICT in the format indicated in the table below:
Type Format Description
Cell phone number
+XXXXXXXXXXXXX The cell phone will use the E.1641 standard.
Email address xxxxxxxx@xxxxxxx.xxx(.xx)
The email will have a maximum size of 77 characters and will be validated according to regular expression defined in the DICT API specification. CPF XXXXXXXXXXX The CPF will be used with 11 numbers, including the check digits. It must be provided without dots or dashes. CNPJ XXXXXXXXXXXXXX The CNPJ will be used with 14 numbers, including the check digits. It must be provided without dots or dashes. Random key2 XXXXXXXX-XXXX-XXXX- XXXX-XXXXXXXXXXXX UUID generated by DICT, according to format specified in RFC41223. The end user with a CPF registration number may link up to five Pix keys for each transactional account of which they are the owner. The end user with a CNPJ registration number may link up to twenty Pix keys for each transactional account of which they are the owner. The key limit is applied per transactional account, regardless of the number of account owners. 1 https://www.itu.int/rec/T-REC-E.164-201011-I/en. 2 The random key is an alphanumeric sequence that has no meaning other than to serve as a Pix key. The random key is not a key of free determination. It is a key constituted by a sequence of bits generated randomly by DICT. 3 https://tools.ietf.org/html/rfc4122#section-3.

1.1 Keys blocked by judicial order
When there is a request to block a key, by judicial order, the DICT returns the key blocked error message (EntryBlocked), with HTTP code 400, in inquiry, data change, exclusion, portability, and possession claim operations. As part of the process, the Pix participant, upon receiving the request via official letter from the Central Bank, must perform the same block in its internal databases, so that inquiries to this key, in an internal transaction, return the block information, without displaying the permitted key information.

2 Validation of Pix Keys
2.1 Validation of key possession
To validate the CPF or CNPJ number, the Pix participant must, at least, verify if the number provided corresponds to the number used for account opening. To validate the cell phone number or email address, the Pix participant must, at least, send a code to the cell phone number or to the email address provided and request the inclusion of this code in some customer service channel made available by it, which must be confirmed through some digital authentication mechanism, at the free choice of the Pix participant.

2.2 Validation of the user's registration status with the Federal Revenue Service
The Pix participant must observe the registration situations of its end users that appear in the Individual Taxpayer Registry, CPF, and the National Legal Entity Registry, CNPJ, as the case may be, to meet the criteria for registration, change, portability, possession claim, and exclusion of keys, as provided in the Pix Regulation. In the case of natural persons, the following registration situations are considered irregular in the DICT:

• suspended;
• cancelled;
• deceased owner;
• null.
  In the case of legal entities, the following situations are considered irregular:
• suspended;
• unfit, except in the case provided for in item I of art. 38 of RFB Instruction No. 2,119,
  of December 6, 2022;
• deregistered;
• null.
  In cases of CNPJ attributed to the Individual Microentrepreneur (MEI), the "suspended" situation will not constitute irregularity when it results from non-compliance with the provisions of art. 1 of Resolution No. 36, of May 2, 2016, of the Committee for the Management of the National Network for Simplification of Registration and Legalization of Companies and Businesses - CGSIM.

2.3 Validation of names linked to Pix Keys
The information linked to Pix keys stored in the DICT must be in accordance with the Individual Taxpayer Registry (CPF) or the National Legal Entity Registry (CNPJ) of the Federal Revenue Service, depending on the type of person owning the key. For this conformity, the rules of this section must be observed. For natural persons, the civil name must be used in the Name field, and the social name may be used only if registered in the CPF. For legal entities, the corporate name must be used in the Name field, and the trade name may be filled in the TradeName field, but only when it appears in the company's CNPJ registration. In the case of Individual Microentrepreneurs, MEI, it is not allowed to fill in the TradeName field, which must remain empty. Both for natural and legal persons, all words that make up the user's name in the CPF, or in the CNPJ, must be written in the appropriate field of the key. In addition, the names linked to the key

6 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3 cannot contain words that do not exist in the original name. Each word must be spelled identically to that in the Federal Revenue Service record, with the following exceptions:

• The use of diacritics in the words of the names linked to the Pix key is allowed, even if the
  Federal Revenue Service bases do not use them, however, restricted to the list: Ã, Õ, Á, É, Í, Ó, Ú, À, È, Ì, Ò, Ù, Â, Ê, Î, Ô, Û, Ä, Ë, Ï, Ö, Ü, Ç, Ñ, Å;
• The exchange of the following characters for space, or vice-versa: dot (.), comma (,), hyphen (-),
  apostrophe (');
• The exchange of the symbol &, "ampersand" or ampersand, for the letter E, or vice-versa;
• If there are characters in the Federal Revenue Service record that are not accepted by the DICT API,
  these must be replaced by a single space (U+0020). If this transformation leads to having two or more consecutive spaces in the name, the sequence must be replaced by a single space.
• It is not necessary to differentiate uppercase from lowercase letters.
  In the case of natural persons, it is allowed to abbreviate words of the name, whether civil name or social name, as long as the following rules are followed:
• An abbreviation is the exchange of a word for its first letter. It is not allowed to exchange a
  word for two or more letters, as would happen in FCO for FRANCISCO, or JR for JUNIOR;
• The first name, taken as the first word of the name registered in the CPF, must appear
  in full, even if it is part of a compound name and the other names remain in full;
• The last surname, taken as the last word of the name registered in the CPF, must
  appear in full, even if it is a suffix like "Filho", "Junior", "Sobrinho", "Primeiro", "Segundo" etc.;
• When abbreviating the user's name, it is not allowed to omit any word, not even
  prepositions like "da", "de", or "do", for example.
  In the case of legal entities, the corporate name must be written in full, as well as the trade name, when this appears in the CNPJ registration. This includes the terms indicating its legal nature, like LTDA, S/A, ME, EIRELI, etc. All words must be spelled in full, without any abbreviation, and exactly as they appear in the CNPJ, with the exceptions already listed and the exchange of the slash (/) for space, or vice-versa. Both for natural and legal persons, the words, abbreviated or not, must be separated by a single space, even in situations where the rules about exchanging characters for space in this section have been used. For example, when omitting a dot that is followed by a space, it is not necessary to write two spaces. For a hypothetical company with the corporate name "M. Almeida Reparos M. E.", it could be written as "M Almeida Reparos M E", with only one space between each word. Also it is not necessary to write spaces after the end of the last word. Examples to assist in interpreting the rules:
  Permitted spelling differences:
• Maria, MARIA, maria
• João, Joao
• Conceição, CONCEICAO

7 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3

• D’Alembert, D Alembert
• Sant’Anna, Sant Anna
• Ben-Hur, Ben Hur
• LAVA-RÁPIDO, LAVA RAPIDO
• Comes & Bebes, Comes e Bebes
• Empresa ABCD S/A, Empresa ABCD S A, Empresa ABCD S.A.
  The pairs below are considered different, or non-conforming, according to the rules of this section:
• Sousa, Souza
• Luis, Luiz
• Sant’Anna, Santanna
• Empresa S/A, Empresa SA
• Empresa S.A., Empresa as
  Here are some examples of abbreviation of natural person names. Starting from the name Fulano Beltrano Sicrano de Tal, the following are acceptable: Fulano B. S. d. Tal, Fulano Beltrano S. de Tal, Fulano B. Sicrano de Tal, and are not acceptable: F. Beltrano S. de Tal, Fulano Beltrano de Tal, Fulano Beltrano Sicrano Tal. For compound names, if the person is named, for example, Maria Cecília, the name "Maria" cannot be abbreviated, even if one intends to write "M. Cecília". The use of a dot (.) to denote abbreviations is optional, by the way they are treated.

3 Key Registration Flow

8 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.3
3.1 Key Registration Flow Initiated by the End User (Pix Participants with Direct Access to DICT)

3.2 Key Registration Flow Initiated by the End User (Pix Participants with Indirect Access to DICT)

3.3 Key Registration Flow Initiated by the Participant (Pix Participants with Direct Access to DICT)

3.4 Key Registration Flow Initiated by the Participant (Pix Participants with Indirect Access to DICT)

4 Key Exclusion Flow

4.1 Key Exclusion Due to Data Incompatibility with the Federal Revenue Service

4.2 Key Exclusion Flow Initiated by the End User (Pix Participants with Direct Access to DICT)

4.3 Key Exclusion Flow Initiated by the End User (Pix Participants with Indirect Access to DICT)

4.4 Key Exclusion Flow Initiated by the Participant (Pix Participants with Direct Access to DICT)

4.5 Key Exclusion Flow Initiated by the Participant (Pix Participants with Indirect Access to DICT)

5 Key Portability Flow

5.1 Portability Flow to the Claimant PSP with Direct Access to DICT

5.2 Portability Flow to the Claimant PSP with Indirect Access to DICT

5.3 Portability Flow to the Donor PSP with Direct Access to DICT

5.4 Portability Flow to the Donor PSP with Indirect Access to DICT

6 Key Possession Claim Flow

6.1 Possession Claim Flow for the Claimant PSP with Direct Access to DICT

6.2 Possession Claim Flow for the Claimant PSP with Indirect Access to DICT

6.3 Possession Claim Flow for the Donor PSP with Direct Access to DICT

6.4 Possession Claim Flow for the Donor PSP with Indirect Access to DICT

7 Flow for Changing Data Linked to the Key

7.1 Flow for Changing Data Linked to the Key (Pix Participants with Direct Access to DICT)

7.2 Flow for Changing Data Linked to the Key (Pix Participants with Indirect Access to DICT)

7.3 Changing Data Linked to the Key for Correction of Inconsistencies

8 Key Inquiry Flow

8.1 Key Data Permitted for Display to the User

8.2 Inquiry Flow for the Pix Participant with Direct Access to DICT

8.3 Inquiry Flow for the Pix Participant with Indirect Access to DICT

8.4 Inquiry Flow for the Pix Participant Acting as a Payment Transaction Initiation Service Provider
with Direct Access to DICT

9 Synchronism Verification Flow

9.1 VSYNC Verification (Pix Participant with Direct Access to DICT)

9.2 VSYNC Verification (Pix Participant with Indirect Access to DICT)

9.3 CIDS List

9.3.1 Pix participant with direct access

9.3.2 Pix participant with indirect access

10 Infraction Notification Flow

10.1 Infraction Notification for Request for Refund

10.1.1 Infraction notification flow for opening a refund request

10.2 Infraction Notification for Marking Transactional Fraud

10.2.1 Infraction notification flow for marking transactional fraud between Pix participants
with direct access to DICT

10.2.2 Infraction notification flow for marking transactional fraud between Pix participants
with indirect access to DICT

11 Communication Interface

12 Cache of Inquired Keys

13 Mechanisms for Prevention of Reading Attacks

13.1 Mechanisms Adopted by DICT

13.2 Mechanisms That Must Be Adopted by Pix Participants

13.2.1 Verification of the authenticity of the user requesting the inquiry

13.2.2 Establishment of an internal policy for limiting inquiries

13.2.3 Qualitative and permanent monitoring of inquiries

13.2.4 Action plan for handling suspicious cases

13.2.5 Restriction of key data displayed to the user making the inquiry

14 Limitation of Requests to the DICT API

15 Flow for Verification of Registered Pix Keys

15.1 Flow for Verification of Registered Pix Keys for the Pix Participant with Direct Access to DICT

15.2 Flow for Verification of Registered Pix Keys for the Pix Participant with Indirect Access to DICT

16 Cache of Pix Key Existence

17 Flow for Requesting Refund

17.1 Request for Refund Due to Operational Failure

17.1.1 Flow for requesting refund due to "payer PSP operational failure" (participants of
Pix with direct access to DICT)

17.1.2 Flow for requesting refund due to "payer PSP operational failure" (participants of
Pix with indirect access to DICT)

17.2 Flow for Requesting Refund Due to "Founded Suspicion of Fraud"

17.3 Flow for Requesting Refund Due to Payer PSP Error in Sending Payment Order Regarding
Automatic Pix

17.3.1 Flow for requesting refund due to payer PSP error in sending payment order
regarding Automatic Pix (Pix participants with direct access to DICT)

17.3.2 Flow for requesting refund due to payer PSP error in sending payment order
regarding Automatic Pix (Pix participants with indirect access to DICT)

18 Flow for Inquiry into Security Information

18.1 Flow for Inquiry into Security Information for the Pix Participant with Direct Access to DICT

18.2 Flow for Inquiry into Security Information for the Pix Participant with Indirect Access to DICT

19 Balders Inquiry

20 Value Recovery Flow

20.1 General Rules

20.1.1 Institution

20.1.2 Tracking

20.1.3 Prioritization

20.1.4 Request for Blocking

20.1.5 Analysis

20.1.6 Refund

20.1.7 Unblocking of Resources

20.1.8 Value Recovery for Transactions Settled in Participants' Systems

20.1.9 Contestation of Refund Transaction Due to Fraud

20.1.10 Cancellation of Value Recovery

20.1.11 Alteration of Value Recovery

20.2 Flow for Institution and Request for Blocking

20.3 Flow for Analysis

20.4 Flow for Refund

21 Event Notifications

21.1 Existing Events

21.1.1 Related to Value Recovery

22 Revision History