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 OWNERSHIP....................................................................................................................... 5
2.2 VALIDATION OF THE USER'S TAX 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 OWNERSHIP CLAIM FLOW....................................................................................... 33
6.1 OWNERSHIP CLAIM FLOW FOR THE CLAIMANT PSP WITH DIRECT ACCESS TO DICT ................................ 33
6.2 OWNERSHIP CLAIM FLOW FOR THE CLAIMANT PSP WITH INDIRECT ACCESS TO DICT ............................. 36
6.3 OWNERSHIP CLAIM FLOW FOR THE DONOR PSP WITH DIRECT ACCESS TO DICT ......................................... 40
6.4 OWNERSHIP CLAIM FLOW FOR THE DONOR PSP WITH INDIRECT ACCESS TO DICT ...................................... 43
7 FLOW FOR ALTERING DATA LINKED TO THE KEY ..................................................................... 46
7.1 FLOW FOR ALTERING DATA LINKED TO THE KEY (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT).......... 46
7.2 FLOW FOR ALTERING DATA LINKED TO THE KEY (PIX PARTICIPANTS WITH INDIRECT ACCESS TO DICT)....... 48
7.3 ALTERATION OF 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 RETURN REQUEST ............................................................................ 68
10.1.1 Infraction notification flow for opening a return 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 CACHED CONSULTED KEYS............................................................................................................ 76
13 MECHANISMS FOR PREVENTING READING ATTACKS........................................................................... 76
13.1 MECHANISMS ADOPTED BY THE 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 VERIFYING REGISTERED PIX KEYS ............................................................................ 82
15.1 FLOW FOR VERIFYING REGISTERED PIX KEYS FOR THE PIX PARTICIPANT WITH DIRECT ACCESS TO DICT ........ 82
15.2 FLOW FOR VERIFYING REGISTERED PIX KEYS FOR THE PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT ..... 83
16 PIX KEY EXISTENCE CACHE........................................................................................................ 85
17 RETURN REQUEST FLOW.................................................................................................. 85
17.1 RETURN REQUEST DUE TO OPERATIONAL FAILURE ...................................................................................... 88
17.1.1 Flow for return request due to "payer PSP operational failure" (Pix participants with direct access to DICT) ....................................................................................................................... 89
17.1.2 Flow for return request due to "payer PSP operational failure" (Pix participants with indirect access to DICT)..................................................................................................................... 91
17.2 FLOW FOR RETURN REQUEST DUE TO "FOUNDED SUSPICION OF FRAUD" ....................................................... 95
17.3 FLOW FOR RETURN REQUEST DUE TO PAYER PSP ERROR IN SENDING PAYMENT ORDER REGARDING AUTOMATIC PIX ................................................................................................................................................ 95
17.3.1 Flow for return request 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 return request due to payer PSP error in sending payment order regarding Automatic Pix (Pix participants with indirect access to DICT) .......................................... 98
18 FLOW FOR INQUIRY OF SECURITY INFORMATION ........................................................................ 102
18.1 FLOW FOR INQUIRY OF 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 OF SECURITY INFORMATION FOR THE PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT.. 104
19 INQUIRY OF BUCKETS ............................................................................................................................ 106
20 VALUE RECOVERY FLOW................................................................................................... 107
20.1 GENERAL RULES......................................................................................................................................... 108
20.1.1 Initiation.................................................................................................................................. 109
20.1.2 Tracking .............................................................................................................................. 110
20.1.3 Prioritization ................................................................................................................................... 110
20.1.4 Blocking Request ................................................................................................................ 110
20.1.5 Analysis ......................................................................................................................................... 110
20.1.6 Return .................................................................................................................................... 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 return 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 INITIATION AND BLOCKING REQUEST...................................................................................... 114
20.3 FLOW FOR ANALYSIS ..................................................................................................................................... 117
20.4 FLOW FOR RETURN ............................................................................................................................... 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 a regular expression defined in the DICT API specification.
CPF XXXXXXXXXXX
The CPF will be used with 11 digits, including the check digits. It must be provided without dots or hyphens.
CNPJ XXXXXXXXXXXXXX
The CNPJ will be used with 14 digits, including the check digits. It must be provided without dots or hyphens.
Random key2 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX UUID generated by the DICT, according to the 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 freely determined key. It is a key constituted by a sequence of bits generated randomly by the 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 blocked key error message (EntryBlocked), with HTTP code 400, in operations for inquiry, data alteration, exclusion, portability, and ownership claim. 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 their internal databases, so that inquiries for 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 ownership
To validate the CPF or CNPJ number, the Pix participant must, at a minimum, 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 a minimum, send a code to the cell phone number or email address provided and request the inclusion of this code in any customer service channel made available by them, which must be confirmed through some digital authentication mechanism, at the Pix participant's discretion.

2.2 Validation of the user's tax status with the Federal Revenue Service
The Pix participant must observe the tax status of their end users listed in the Individual Taxpayer Registry (CPF) and the National Legal Entity Registry (CNPJ), as applicable, to meet the criteria for registration, alteration, portability, ownership claim, and exclusion of keys, as set forth in the Pix Regulation. In the case of natural persons, the following tax statuses are considered irregular in the DICT:

• suspended;
• cancelled;
• deceased owner;
• null.
  In the case of legal entities, the following statuses 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 assigned to the Individual Microentrepreneur (MEI), the "suspended" status 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 conform to 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), filling the TradeName field is not allowed; it must remain empty. For both natural and legal persons, all words comprising the user's name in the CPF or CNPJ must be written in the appropriate field of the key. Furthermore, names linked to the key 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 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 a space, or vice-versa: period (.), 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, they must be replaced by a single space (U+0020). If this transformation results in two or more consecutive spaces in the name, the sequence must be replaced by a single space.
• It is not necessary to differentiate uppercase and lowercase letters.
  In the case of natural persons, it is allowed to abbreviate words of the name, whether civil or social name, provided 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 occur 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 permitted 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 it appears in the CNPJ registration. This includes terms indicative of their legal nature, such as 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 a space, or vice-versa. For both natural and legal persons, words, whether abbreviated or not, must be separated by a single space, even in situations where the rules regarding the exchange of characters for space in this section have been used. For example, when omitting a period 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. It is also 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

8 • 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
  Below are some examples of abbreviating 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 the following 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 period (.) to denote abbreviations is optional, given how they are treated. 3 Key Registration Flow

---