RegAlert2025-08-28 | Instrução Normativa BCB 655Added
Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.5
Version 8.5 of the DICT Operational Manual establishes technical specifications for Pix key formats, including mobile phone, email, CPF, CNPJ, and random keys, and defines registration limits of five keys per individual account and twenty per corporate account. It mandates validation procedures for key ownership, tax registry status, and name consistency, while detailing operational flows for key registration, deletion, portability, claim, modification, and inquiry for both direct and indirect DICT participants. The document further outlines security mechanisms, API request limitations, fraud notification processes, and procedures for value recovery and operational failure refunds.
BCB published 18 documents in the last 30 days — get each new one by email the day it lands.
1 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Manual Operacional
do Diretório de
Identificadores de
Contas Transacionais
(DICT)
Versão 8.5
2 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Sumário
- PIX KEYS ................................................................................................................................................ 5
1.1 KEYS BLOCKED BY JUDICIAL ORDER ....................................................................................................... 5 - VALIDATION OF PIX KEYS...................................................................................................................... 5
2.1 VALIDATION OF KEY OWNERSHIP....................................................................................................................... 5
2.2 VALIDATION OF THE USER'S TAX REGISTRY STATUS WITH THE FEDERAL REVENUE ................................................................. 6
2.3 VALIDATION OF NAMES LINKED TO PIX KEYS ........................................................................................... 6 - KEY REGISTRATION FLOW .................................................................................................................. 8
3.1 KEY REGISTRATION FLOW BY FINAL USER REQUEST (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT)
3.2 KEY REGISTRATION FLOW BY FINAL USER REQUEST (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 - KEY DELETION FLOW ............................................................................................................... 17
4.1 KEY DELETION DUE TO DATA INCOMPATIBILITY WITH THE FEDERAL REVENUE ................................................. 17
4.2 KEY DELETION FLOW BY FINAL USER REQUEST (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT) 17
4.3 KEY DELETION FLOW BY FINAL USER REQUEST (PIX PARTICIPANTS WITH INDIRECT ACCESS TO DICT) 18
4.4 KEY DELETION FLOW INITIATED BY THE PARTICIPANT (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT) .... 20
4.5 KEY DELETION FLOW INITIATED BY THE PARTICIPANT (PIX PARTICIPANTS WITH INDIRECT ACCESS TO DICT).. 22 - KEY PORTABILITY FLOW ...................................................................................................... 23
5.1 PORTABILITY FLOW TO THE CLAIMING PSP WITH DIRECT ACCESS TO DICT............................................. 24
5.2 PORTABILITY FLOW TO THE CLAIMING 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 - KEY OWNERSHIP CLAIM FLOW....................................................................................... 33
6.1 OWNERSHIP CLAIM FLOW FOR THE CLAIMING PSP WITH DIRECT ACCESS TO DICT ................................ 33
6.2 OWNERSHIP CLAIM FLOW FOR THE CLAIMING 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 - FLOW TO MODIFY DATA LINKED TO THE KEY ..................................................................... 46
7.1 FLOW TO MODIFY DATA LINKED TO THE KEY (PIX PARTICIPANTS WITH DIRECT ACCESS TO DICT).......... 46
7.2 FLOW TO MODIFY DATA LINKED TO THE KEY (PIX PARTICIPANTS WITH INDIRECT ACCESS TO DICT)....... 48
7.3 MODIFICATION OF DATA LINKED TO THE KEY FOR CORRECTION OF INCONSISTENCIES .............................................. 51 - 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 INITIATION SERVICE PROVIDER, WITH DIRECT ACCESS TO DICT ............................................................................................................. 57
3 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
8.5 INQUIRY FLOW FOR THE PIX PARTICIPANT ACTING AS A PAYMENT INITIATION SERVICE PROVIDER, WITH INDIRECT ACCESS TO DICT .......................................................................................................... 58
9. SYNCHRONIZATION 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 LIST OF CIDS ............................................................................................................................................ 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 REFUND REQUEST............................................................................ 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 TO PREVENT 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 TO VERIFY REGISTERED PIX KEYS ............................................................................ 82
15.1 FLOW TO VERIFY REGISTERED PIX KEYS FOR THE PIX PARTICIPANT WITH DIRECT ACCESS TO DICT ........ 82
15.2 FLOW TO VERIFY REGISTERED PIX KEYS FOR THE PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT ..... 83
16. CACHE OF PIX KEY EXISTENCE........................................................................................................ 85
17. FLOW TO REQUEST REFUND.................................................................................................. 85
17.1 REFUND REQUEST DUE TO OPERATIONAL FAILURE ...................................................................................... 88
17.1.1 Refund request flow due to "operational failure of the payer's PSP" (participants with direct access to DICT) ....................................................................................................................... 89
17.1.2 Refund request flow due to "operational failure of the payer's PSP" (participants with indirect access to DICT)..................................................................................................................... 91
17.2 FLOW TO REQUEST REFUND DUE TO "FOUNDED SUSPICION OF FRAUD" ....................................................... 95
17.3 FLOW TO REQUEST REFUND DUE TO ERROR BY THE PAYER'S PSP IN SENDING PAYMENT ORDER REGARDING AUTOMATIC PIX ................................................................................................................................................ 95
17.3.1 Refund request flow due to error by the payer's PSP in sending payment order regarding Automatic Pix (participants with direct access to DICT) ............................................. 95
17.3.2 Refund request flow due to error by the payer's PSP in sending payment order regarding Automatic Pix (participants with indirect access to DICT) .......................................... 98
18. FLOW TO INQUIRE SECURITY INFORMATION ........................................................................ 102
18.1 FLOW TO INQUIRE SECURITY INFORMATION FOR THE PIX PARTICIPANT WITH DIRECT ACCESS TO DICT..... 103
4 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
18.2 FLOW TO INQUIRE SECURITY INFORMATION FOR THE PIX PARTICIPANT WITH INDIRECT ACCESS TO DICT.. 104
19. INQUIRY INTO BUCKETS ............................................................................................................................ 106
20. FLOW TO RECOVER VALUES................................................................................................... 107
20.1 GENERAL RULES......................................................................................................................................... 108
20.1.1 Initiation.................................................................................................................................. 109
20.1.2 Tracking .............................................................................................................................. 109
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 ............................................................................................................ 113
20.1.8 Recovery of values for transactions settled in participants' systems................. 113
20.1.9 Contestation of refund transaction due to fraud ................................................................... 113
20.1.10 Cancellation of Value Recovery............................................................................. 114
20.1.11 Modification of Value Recovery..................................................................................... 114
20.2 FLOW TO INITIATE AND REQUEST BLOCKING...................................................................................... 115
20.3 FLOW TO ANALYZE ..................................................................................................................................... 118
20.4 FLOW TO REFUND ............................................................................................................................... 120
21. EVENT NOTIFICATIONS ................................................................................................................... 127
21.1 EXISTING EVENTS ................................................................................................................................. 128
21.1.1 Related to Value Recovery ..................................................................................... 128
22. REVISION HISTORY.......................................................................................................................... 129
5 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
1 Pix Keys
Pix keys will be stored in the DICT in the format indicated in the table below:
| Type | Format | Description |
|---|---|---|
| Mobile phone number | +XXXXXXXXXXXXX | The mobile phone will use the E.164 standard 1. |
| Email address | xxxxxxxx@xxxxxxx.xxx(.xx) | The email will have a maximum size of 77 characters and will be validated according to the regular expression defined in the DICT API specification. |
| CPF (Individual Taxpayer Registry) | XXXXXXXXXXX | The CPF will be used with 11 numbers, including the check digits. It must be provided without dots or dashes. |
| CNPJ (Corporate Taxpayer Registry) | XXXXXXXXXXXXXX | The CNPJ will be used in alphanumeric format, with 14 characters, including the check digits. It must be provided without dots or dashes. |
| Random key 2 | XXXXXXXX-XXXX-XXXXXXXX-XXXXXXXXXXXX | UUID generated by the DICT, according to the format specified in RFC4122 3. |
The final user with a CPF registration number may link up to five Pix keys for each transactional account of which they are the owner. The final 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 applies to each transactional account, regardless of the number of account owners.
1.1 Keys blocked by judicial order
When there is a blocking request for a key, by judicial order, the DICT returns the blocked key error message (EntryBlocked), with HTTP code 400, in inquiry, data modification, deletion, portability, and ownership 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 blocking in their internal databases, so that inquiries to this key, in an internal transaction, return the blocking 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 least, verify if the number provided corresponds to the number used for account opening.
To validate the mobile phone number or email address, the Pix participant must, at least, send a code to the mobile phone number or email address provided and request the inclusion of this code in a 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 registry status with the Federal Revenue
The Pix participant must observe the registry statuses of their final users listed in the Individual Taxpayer Registry (CPF) and the National Corporate Taxpayer Registry (CNPJ), as applicable, to meet the registration, modification, portability, ownership claim, and key deletion criteria, as provided in the Pix Regulation.
In the case of natural persons, the following registry statuses are considered irregular in the DICT:
- suspended;
- cancelled;
- deceased holder;
- null.
In the case of legal entities, the following statuses are considered irregular:
- suspended;
- ineligible, except in the case provided for in item I of Article 38 of Federal Revenue 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 Article 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 consistent with the Individual Taxpayer Registry (CPF) or the National Corporate Taxpayer Registry (CNPJ) of the Federal Revenue, depending on the type of person owning the key. For this consistency, the rules of this section must be observed.
For natural persons, the civil name must be used in the Name field; 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 in the TradeName field is not allowed; it must remain empty.
6 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
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 recorded in the Federal Revenue registry, 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 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 registry that are not accepted by the DICT API, these 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 permitted to abbreviate words of the name, whether civil or social name, provided that the following rules are followed:
- An abbreviation is the exchange of a word for its first letter. It is not permitted 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 an agnomen such as "Filho", "Junior", "Sobrinho", "Primeiro", "Segundo" etc.;
- When abbreviating the user's name, it is not permitted to omit any word, not even prepositions such as "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 indicating 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, abbreviated or not, must be separated by a single space, even in situations where the rules regarding the exchange of characters for spaces from 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
Footnotes
- https://www.itu.int/rec/T-REC-E.164-201011-I/en.
- 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 self-determined key. It is a key constituted by a sequence of bits generated randomly by the DICT.
- https://tools.ietf.org/html/rfc4122#section-3.
8 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
- João, Joao
- Conceição, CONCEICAO
- 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 abbreviations for individual 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 the intention is to write “M. Cecília”. The use of a period (.) to denote abbreviations is optional, as they are treated.
3 Key registration flow
3.1 Key registration flow initiated by the end user (Pix participants with direct access to the DICT)
9 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | End User | Action | End user accesses their service channel. |
| 2 | End User | Action | End user informs which key they wish to register among the five possible types: CPF, CNPJ, e-mail, mobile phone number, and random key. End user requests key registration. |
| 3 | End User | Communication | End user forwards their request and the necessary data to their Payment Service Provider (PSP). |
| PSP of the end user | Communication | PSP of the end user receives the key registration request in the DICT. | |
| PSP of the end user | Action | PSP validates key ownership by the end user and confirms their data and registration status with the Federal Revenue Service. Before forwarding the registration request to the DICT, the PSP must check if the key is already registered in its internal database. If it is, there is no need to send the request to the DICT. PSP proceeds directly to step 15. | |
| PSP of the end user | Message | Key registration request is forwarded to the DICT via the “Directory / Create Link” message. | |
| 7 | DICT | Message | DICT receives the message with the key registration request. |
10 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 8 | DICT | Action | DICT performs compliance checks: i) the institution that requested the registration, i.e., the PSP with direct access, must have authorization to register Pix keys; and ii) the PSP linked to the key must be the same PSP as the end user who requested the key registration. |
| 9 | DICT | Action | DICT checks if the requested Pix key is already registered. In the case of a random key, DICT generates the hexadecimal number that will serve as the address. |
| 10 | DICT | Action | If the requested key is not registered in the DICT, it is registered, linking the key to the transactional account data. |
| 11 | DICT | Action | If the requested key is already registered in the DICT, a message is created indicating the existence of a registration for that key, with the data of the existing key. |
| 12 | DICT | Message | DICT sends a response message to the PSP of the end user, informing the success of the registration or the existence of an already registered key. |
| 13 | PSP of the end user | Message | PSP of the end user receives the response message from the DICT. |
| 14 | PSP of the end user | Action | In case of successful registration, the PSP of the end user updates its internal database with the key and the data of the account linked to it. |
| 15 | PSP of the end user | Communication | PSP of the end user may send three communications to the end user: i) if the key was registered successfully, a communication confirming the key registration is sent; ii) if the key was not registered and the key is in the possession of the same CPF/CNPJ that requested its registration, a communication is sent indicating the PSP of the already registered key and asking if the user wishes to perform key portability; or iii) if the key was not registered and the key is in the possession of a different CPF/CNPJ from that which requested its registration, a communication is sent indicating the PSP of the already registered key and asking if the user wishes to claim ownership of the key. |
| 16 | End User | Communication | End user receives communication from their PSP. If the key was registered successfully, the flow is ended. |
| 17 | End User | Communication | End user sends communication to their PSP, if the user decides to request portability or claim ownership. |
| 18 | PSP of the end user | Communication | PSP of the end user receives communication from the user. If the user chooses to request key portability, the portability flow is initiated. |
11 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
If the user chooses to request key ownership claim, the ownership claim flow is initiated.
3.2 Key registration flow initiated by the end user (Pix participants with indirect access to the DICT)
12 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | End User | Action | End user accesses their service channel. |
| 2 | End User | Action | End user informs which key they wish to register among the five possible types: CPF, CNPJ, e-mail, mobile phone number, and random key. End user requests key registration. |
| 3 | End User | Communication | End user forwards their request and the necessary data to their Payment Service Provider (PSP). |
| PSP of the end user | Communication | PSP of the end user receives the key registration request in the DICT. |
12 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| PSP of the end user | Action | PSP validates key ownership by the end user and confirms their data and registration status with the Federal Revenue Service. Before forwarding the registration request to the DICT, the PSP must check if the key is already registered in its internal database. If it is, there is no need to send the request to the DICT. PSP proceeds directly to step 19. | |
| PSP of the end user | Communication | Key registration request is forwarded to the PSP with direct access to the DICT. | |
| PSP with direct access to the DICT | Communication | PSP with direct access to the DICT receives communication with the key registration request. | |
| PSP with direct access to the DICT | Message | PSP with direct access forwards the key registration request to the DICT via the “Directory / Create Link” message. | |
| 9 | DICT | Message | DICT receives the message with the key registration request. |
| 10 | DICT | Action | DICT performs compliance checks: i) the institution that requested the registration, i.e., the PSP with direct access, must have authorization to register Pix keys. The DICT must, in addition, verify if the PSP with direct access to the DICT has authorization to register keys for the PSP without direct access; ii) the PSP linked to the key must be the same PSP as the end user who requested the key registration; and iii) the PSP with direct access to the DICT has permission to perform registrations on behalf of the user's PSP. |
| 11 | DICT | Action | DICT checks if the requested Pix key is already registered. In the case of a random key, DICT generates the hexadecimal number that will serve as the address. |
| 12 | DICT | Action | If the requested key is already registered in the DICT, a message is created indicating the existence of a registration for that key, with the data of the existing key. |
| 13 | DICT | Action | If the requested key is already registered in the DICT, a message is created indicating registration for that key, with the data of the existing key. |
| 14 | DICT | Message | DICT sends a response message to the PSP with direct access, informing the success of the registration or the existence of an already registered key. |
| 15 | PSP with direct access to the DICT | Message | PSP with direct access to the DICT receives the response message. |
| 16 | PSP with direct access to the DICT | Communication | PSP with direct access to the DICT sends communication to the PSP of the end user, informing the registration or the existence of an already registered key. |
| 17 | PSP of the end user | Communication | PSP of the end user receives communication. |
| 18 | PSP of the end user | Action | In case of successful registration, the PSP of the end user updates its internal database with the key and the data of the account linked to it. |
13 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 19 | PSP of the end user | Communication | PSP of the end user may send three communications to the end user: i) if the key was registered successfully, a communication confirming the key registration is sent; ii) if the key was not registered and the key is in the possession of the same CPF/CNPJ that requested its registration, a communication is sent indicating the PSP of the already registered key and asking if the user wishes to perform key portability; or iii) if the key was not registered and the key is in the possession of a different CPF/CNPJ from that which requested its registration, a communication is sent indicating the PSP of the already registered key and asking if the user wishes to claim ownership of the key. |
| 20 | End User | Communication | End user receives communication from their PSP. If the key was registered successfully, the flow is ended. |
| 21 | End User | Communication | End user sends communication to their PSP, if the user decides to request portability or claim ownership. |
| 22 | PSP of the end user | Communication | PSP of the end user receives communication from the user. If the user chooses to request key portability, the portability flow is initiated. |
If the user chooses to request key ownership claim, the ownership claim flow is initiated.
14 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
3.3 Key registration flow initiated by the participant (Pix participants with direct access to the DICT)
15 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| PSP of the end user | Action | After the synchronization verification process, PSP identifies a key correctly registered in its database, but which, due to an operational failure, is not registered in the DICT. | |
| PSP of the end user | Message | Key registration request is forwarded to the DICT via the “Directory / Create Link” message. | |
| 3 | DICT | Message | DICT receives the message with the key registration request. |
| 4 | DICT | Action | DICT performs compliance checks: i) the institution that requested the registration, i.e., the PSP with direct access, must have authorization to register Pix keys; and ii) the PSP linked to the key must be the same PSP as the end user who requested the key registration. |
| 5 | DICT | Action | DICT checks if the requested addressing key is already registered. |
| 6 | DICT | Action | If the requested key is not registered in the DICT, it is registered, linking the key to the transactional account data. |
15 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 7 | DICT | Action | If the requested key is already registered in the DICT, a message is created indicating the existence of a registration for that key, with the data of the existing key. |
| 8 | DICT | Message | DICT sends a response message to the PSP of the end user, informing the success of the registration or the existence of an already registered key. |
| PSP of the end user | Message | PSP of the end user receives the response message from the DICT. |
3.4 Key registration flow initiated by the participant (Pix participants with indirect access to the DICT)
16 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| PSP of the end user | Action | After the synchronization verification process, PSP identifies a key correctly registered in its database, but which, due to an operational failure, is not registered in the DICT. | |
| PSP of the end user | Communication | Key registration request in the DICT is forwarded to the PSP with direct access to the DICT. |
16 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| PSP with direct access to the DICT | Communication | PSP with direct access to the DICT receives communication with the key registration request. | |
| PSP with direct access to the DICT | Message | PSP with direct access forwards the key registration request to the DICT via the “Directory / Create Link” message. | |
| 5 | DICT | Message | DICT receives the message with the key registration request. |
| 6 | DICT | Action | DICT performs compliance checks: i) the institution that requested the registration, i.e., the PSP with direct access, must have authorization to register Pix keys; ii) the PSP linked to the key must be the same PSP as the end user who requested the key registration; and iii) the PSP with direct access to the DICT has permission to perform registrations on behalf of the user's PSP. |
| 7 | DICT | Action | DICT checks if the requested addressing key is already registered. |
| 8 | DICT | Action | If the requested key is not registered in the DICT, it is registered, linking the key to the transactional account data. |
| 9 | DICT | Action | If the requested key is already registered in the DICT, a message is created indicating the existence of a registration for that key, with the data of the existing key. |
| 10 | DICT | Message | DICT sends a response message to the PSP with direct access, informing the success of the registration or the existence of an already registered key. |
| 11 | PSP with direct access to the DICT | Message | PSP with direct access to the DICT receives the response message. |
| 12 | PSP with direct access to the DICT | Communication | PSP with direct access to the DICT sends communication to the PSP of the end user, informing the registration or the existence of an already registered key. |
| 13 | PSP of the end user | Communication | PSP of the end user receives communication. |
17 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
4 Key deletion flow
4.1 Key deletion due to incompatibility of data with the Federal Revenue Service
In the case of key deletion due to incompatibility of data with the Federal Revenue Service registration, such as name non-conformity or irregular CPF or CNPJ status, the PSP must use the following codes in the “Reason” field of the “Remove Link” endpoint:
- “FRAUD”: if the PSP identifies that the name divergence or CPF/CNPJ irregularity is related to fraud;
- “RFB_VALIDATION”: in other cases.
The user must be notified about the key deletion immediately after its implementation, according to the flows in sections 4.4 and 4.5 of this manual, informing the reason for the deletion. For example, in case of name incompatibility, the participant must provide details that allow the user to identify the problem, or in case of irregular status, specify the situation that caused the deletion.
4.2 Key deletion flow initiated by the end user (Pix participants with direct access to the DICT)
18 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | End User | Action | End user accesses their service channel. |
| 2 | End User | Action | End user requests Pix key deletion. |
| 3 | End User | Communication | End user forwards their request to their PSP. |
18 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| PSP of the end user | Communication | PSP of the end user receives the key deletion request in the DICT. | |
| PSP of the end user | Action | PSP checks if the key is registered in its internal database and if the user requesting the deletion is the same user linked to the key. | |
| PSP of the end user | Message | Key deletion request is forwarded to the DICT via the “Directory / Remove Link” message. | |
| 7 | DICT | Message | DICT receives the message with the key deletion request. |
| 8 | DICT | Action | DICT performs compliance checks: i) key is registered in the DICT; ii) the institution that requested the deletion must be the same that performed the registration; and iii) the key must belong to the user who requested the deletion. |
| 9 | DICT | Action | DICT deletes the Pix key from its database. |
| 10 | DICT | Message | DICT sends a confirmation message of the deletion to the PSP of the end user. |
| 11 | PSP of the end user | Message | PSP of the end user receives communication informing the key deletion. |
| 12 | PSP of the end user | Action | PSP of the end user updates its internal database, deleting the key. |
| 13 | PSP of the end user | Communication | PSP of the end user sends key deletion confirmation. |
| 14 | End User | Communication | End user receives confirmation of the requested key deletion. |
4.3 Key deletion flow initiated by the end user (Pix participants with indirect access to the DICT)
19 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | End User | Action | End user accesses their service channel. |
| 2 | End User | Action | End user requests Pix key deletion. |
| 3 | End User | Communication | End user forwards their request to their PSP. |
| 4 | PSP of the end user | Communication | PSP of the end user receives the key deletion request in the DICT. |
| 5 | PSP of the end user | Action | PSP checks if the key is registered in its internal database and if the user requesting the deletion is the same user linked to the key. |
| 6 | PSP of the end user | Communication | Key deletion request is forwarded to the PSP with direct access to the DICT. |
| PSP with direct access to the DICT | Communication | PSP with direct access to the DICT receives communication with the key deletion request. | |
| PSP with direct access to the DICT | Message | PSP with direct access forwards the key deletion request via the “Directory / Remove Link” message. | |
| 9 | DICT | Message | DICT receives the message with the key deletion request. |
20 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 10 | DICT | Action | DICT performs compliance checks: i) key is registered in the DICT; ii) the institution that requested the deletion must be the same that performed the registration; and iii) the key must belong to the user who requested the deletion. |
| 11 | DICT | Action | DICT deletes the Pix key from its database. |
| 12 | DICT | Message | DICT sends a confirmation message of the deletion to the PSP with direct access. |
| 13 | PSP with direct access to the DICT | Message | PSP with direct access to the DICT receives the response of the key deletion. |
| 14 | PSP with direct access to the DICT | Communication | PSP with direct access to the DICT forwards communication to the PSP of the end user, informing the key deletion. |
| 15 | PSP of the end user | Communication | PSP of the end user receives communication informing the key deletion. |
| 16 | PSP of the end user | Action | PSP of the end user updates its internal database, deleting the key. |
| 17 | PSP of the end user | Communication | PSP of the end user sends key deletion confirmation. |
| 18 | End User | Communication | End user receives confirmation of the requested key deletion. |
4.4 Key deletion flow initiated by the participant (Pix participants with direct access to the DICT)
21 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| PSP of the end user | Action | Initiates deletion process. | |
| PSP of the end user | Message | Key deletion request is sent to the DICT via the “Directory / Remove Link” message. | |
| 3 | DICT | Message | DICT receives the message with the key deletion request. |
| 4 | DICT | Action | DICT performs compliance checks: i) key is registered in the DICT; and ii) the institution that requested the deletion must be the same that performed the registration. |
| 5 | DICT | Action | DICT deletes the Pix key from its database. |
| 6 | DICT | Message | DICT sends a confirmation message of the deletion to the PSP of the end user. |
| PSP of the end user | Message | PSP of the end user receives communication informing the key deletion. | |
| PSP of the end user | Action | PSP of the end user updates its internal database, deleting the key. | |
| PSP of the end user | Communication | PSP of the end user sends key deletion confirmation. | |
| 10 | End User | Communication | End user receives confirmation of the key deletion. |
22 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
4.5 Key deletion flow initiated by the participant (Pix participants with indirect access to the DICT)
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | PSP of the end user | Action | Initiates deletion process. |
| 2 | PSP of the end user | Communication | Key deletion request is forwarded to the PSP with direct access to the DICT. |
| PSP with direct access to the DICT | Communication | PSP with direct access to the DICT receives communication with the key deletion request. | |
| PSP with direct access to the DICT | Message | PSP with direct access forwards the key deletion request via the “Directory / Remove Link” message. | |
| 5 | DICT | Message | DICT receives the message with the key deletion request. |
22 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
23 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
6 DICT Action
DICT performs compliance checks:
i) the key is registered in the DICT; and ii) the institution that requested the deletion must be the same one that performed the registration.
7 DICT Action DICT deletes the Pix key from its database.
8 DICT Message DICT sends a confirmation message of the deletion to the PSP with direct access.
PSP with direct access to DICT Message PSP with direct access to DICT receives the response of the key deletion.
10 PSP with direct access to DICT Communication PSP with direct access to DICT forwards communication to the end-user PSP, informing the key deletion.
11 End-user PSP Communication End-user PSP receives communication informing the key deletion.
12 End-user PSP Action End-user PSP updates its internal database, deleting the key.
13 End-user PSP Communication End-user PSP sends confirmation of key deletion.
14 End-user Communication End-user receives confirmation of key deletion.
5 Key portability flow
Within the scope of the portability process, the donor PSP is the Pix participant to which the key is originally linked.
During the portability process, from the moment the DICT sets the request status to “Open” until the moment the DICT changes the status to “Complete”, the Pix key is not subject to registration and deletion requests 4. While the request status is “Awaiting Resolution”, queries will continue to normally return the identification of the transactional account originally linked to the key. Also during this period, both the claiming PSP and the donor PSP may cancel the request, in case of suspected fraud or in case of cancellation request by the claiming PSP’s user. The request may also be cancelled by the claiming PSP if its status is “Open”. The resolution period for a portability process is seven days. If the donor user does not cancel or confirm the portability by the end of this period, the donor PSP must necessarily cancel the request. The cancellation of the process must be done immediately after the end of the resolution period. The process will continue with the status of “Awaiting Resolution” until the receipt of this information by the DICT. The claiming PSP may also cancel a portability that has the status “Confirmed”. This possibility is necessary in case of any error in the portability process. The DICT provides a service that allows querying and filtering portability processes. PSPs with direct access to the DICT must query this service at least once per minute in order to identify 4
24 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5 status changes of portabilities of interest to the PSP (in addition to those of interest to the PSPs with indirect access for which it provides service), both as claimant and as donor.
5.1 Portability flow for the claiming PSP with direct access to the DICT
Layer Type Description
1 Claiming PSP Action
The process is initiated:
(i) after detecting that there is already a record for the requested key and after the user’s request; or (ii) directly by the end-user, from a specific functionality offered by their PSP (in this case, the user must go through an active validation process of the key). Before sending the request to the DICT, the PSP must confirm the data and registration status of the end-user with the Federal Revenue. If the status is irregular or there is a discrepancy, the PSP must not initiate the process and go directly to step 13.
2 Claiming PSP Message
The claiming PSP sends a portability request to the DICT through the message “Claim / Create Claim” indicating the type “Portability”.
3 DICT Message DICT receives the message with the key portability request.
25 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
4 DICT Action
DICT creates a portability request with status “Open”, with the key and claiming PSP data, and starts the counting of the resolution period, awaiting response from the donor PSP.
5 DICT Action
Once received, from the donor PSP, the confirmation or cancellation of the portability, DICT updates the request status to "Confirmed" or "Cancelled", as the case may be. If the status is "Cancelled", the DICT changes the request status to “Complete”, finalizing the process. If the status is “Confirmed”, the DICT blocks the key until the confirmation is received by the claiming PSP. The block means that queries to this key in the DICT will return an error message.
6 Claiming PSP Action
Claiming PSP periodically queries the DICT until identifying a change in the status of the portability request, through the message “Claim / List Claims” or “Claim / Query Claim”. Upon identifying a status change to "Cancelled", the claiming PSP proceeds directly to step 12. Upon identifying a status change to "Confirmed", the claiming PSP proceeds to step 6.
7 Claiming PSP Message
Claiming PSP requests completion of the key portability in the DICT, through the message “Claim / Complete Claim”.
8 DICT Message DICT receives the request for completion of the key portability.
9 DICT Action DICT updates the data linked to the key and changes the portability request status to “Complete”.
10 DICT Message DICT sends a confirmation message of the update of data linked to the key to the claiming PSP.
11 Claiming PSP Message Claiming PSP receives confirmation of the update of data linked to the key.
12 Claiming PSP Action Claiming PSP updates its internal database.
13 Claiming PSP Communication
Claiming PSP informs the end-user about the cancellation or confirmation of the key portability request.
14 End-user Communication End-user receives the information about the cancellation or confirmation of the key portability request.
26 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
5.2 Portability flow for the claiming PSP with indirect access to the DICT
Layer Type Description
1 Claiming PSP Action
The process is initiated:
(i) after detecting that there is already a record for the requested key and after the user’s request; or (ii) directly by the end-user, from a specific functionality offered by their PSP (in this case, the user must go through an active validation process of the key). Before sending the request to the DICT, the PSP must confirm the data and registration status of the end-user with the Federal Revenue. If the status is irregular or there is a discrepancy, the PSP must not initiate the process and go directly to step 21.
27 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
2 Claiming PSP Communication The claiming PSP sends the portability request to the PSP with direct access to the DICT.
PSP with direct access to DICT Communication PSP with direct access to DICT receives the portability request.
PSP with direct access to DICT Message
PSP with direct access to DICT forwards the portability request through the message “Claim / Create Claim” of type “Portability”.
5 DICT Message DICT receives the message with the key portability request.
6 DICT Action
DICT creates a portability request with status “Open”, with the key and claiming PSP data, and starts the counting of the resolution period, awaiting response from the donor PSP.
7 DICT Action
Once received, from the donor PSP, the confirmation or cancellation of the portability, DICT updates the request status to "Confirmed" or "Cancelled", as the case may be. If the status is "Cancelled", the DICT changes the request status to “Complete”, finalizing the process. If the status is “Confirmed”, the DICT blocks the key until the confirmation is received by the claiming PSP. PSP with direct access to DICT Action PSP with direct access periodically queries the DICT until identifying a change in the status of the portability request, through the message “Claim / List Claims” or “Claim / Query Claim”. PSP with direct access to DICT Communication PSP with direct access sends communication to the claiming PSP, identifying whether the request status has changed to “Cancelled” or to “Confirmed”.
10 Claiming PSP Communication
Claiming PSP receives communication from the PSP with direct access informing of a change in the request status.
If the status is "Cancelled", proceed directly to step 21.
11 Claiming PSP Communication
If the request status is "Confirmed", the claiming PSP requests completion of the key portability in the DICT.
12 PSP with direct access to DICT Communication PSP with direct access receives the request for completion of the key portability.
13 PSP with direct access to DICT Message
PSP with direct access forwards the request for completion of the key portability to the DICT through the message “Claim / Complete Claim”.
14 DICT Message DICT receives the request for completion of the key portability.
15 DICT Action DICT updates the data linked to the key and changes the portability request status to “Complete”.
28 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
16 DICT Message DICT sends a confirmation message of the update of data linked to the key to the PSP with direct access.
17 PSP with direct access to DICT Message PSP with direct access receives confirmation of key update.
18 PSP with direct access to DICT Communication PSP with direct access forwards confirmation of key update.
19 Claiming PSP Communication Claiming PSP receives confirmation of the update of data linked to the key.
20 Claiming PSP Action Claiming PSP updates its internal database.
21 Claiming PSP Communication
Claiming PSP informs the end-user about the cancellation or confirmation of the key portability request.
22 End-user Communication End-user receives the information about the cancellation or confirmation of the key portability request.
5.3 Portability flow for the donor PSP with direct access to the DICT
29 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
1 Donor PSP Action
Donor PSP periodically queries the DICT for the list of portabilities with status “Open” that refer to keys registered by it, through the message “Claim / List Claims”.
2 Donor PSP Message/
Communication
Upon identifying a portability with status “Open”, donor PSP sends message “Claim / Receive Claim” to the DICT and notifies the end-user, requesting confirmation or cancellation of the portability.
3 DICT Message DICT receives the message from the donor PSP.
4 DICT Action
DICT changes the request status to “Awaiting Resolution” and waits for receipt of information about the portability process.
5 End-user Communication End-user receives notification from the donor PSP.
30 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
6 End-user Action
End-user may cancel or confirm the portability.
The user has up to seven days to do so. To cancel the portability within this period, the user must perform active validation of the key. If the user does not cancel or confirm the portability within this period, the donor PSP must necessarily cancel the request, without the need for the user to send a response, proceeding directly to step 12. In this case, while the donor PSP does not cancel the request, the key will remain with the status “Awaiting Resolution”, in which it is blocked for alteration, but remains active for queries.
7 End-user Communication End-user sends communication to the donor PSP.
8 Donor PSP Communication Donor PSP receives communication from the user.
9 Donor PSP Action
If the user responds requesting cancellation of the portability, the PSP advances to step 12.
If the user responds requesting confirmation of the portability, the donor PSP removes the key from its internal database.
10 Donor PSP Communication If the key has been deleted from the internal database, the donor PSP informs the end-user about the key deletion.
11 End-user Communication End-user receives the information of key deletion.
12 Donor PSP Message
Donor PSP informs the DICT about the conclusion of the process, informing the cancellation, through the message “Claim / Cancel Claim”, or the confirmation of the portability, through the message “Claim / Confirm Claim”, as the case may be.
13 DICT Message
DICT receives the information of cancellation or confirmation of the portability and continues the process (step 4 of the portability flow for the claiming PSP with direct access to the DICT).
5.4 Portability flow for the donor PSP with indirect access to the DICT
31 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
PSP with direct access to DICT Action
PSP with direct access periodically queries the DICT for the list of portabilities with status “Open” that refer to keys registered by the donor PSP to which it provides services, through the message “Claim / List Claims”. PSP with direct access to DICT Message/ Communication Upon identifying a portability with status “Open”, PSP with direct access sends message “Claim / Receive Claim” to the DICT and communication to the donor PSP.
3 DICT Message DICT receives the message from the PSP with direct access.
32 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
4 DICT Action
DICT changes the request status to “Awaiting Resolution” and waits for receipt of information about the portability process.
5 Donor PSP Communication Donor PSP receives communication from the PSP with direct access.
6 Donor PSP Communication Donor PSP notifies the end-user, requesting confirmation or cancellation of the portability.
7 End-user Communication End-user receives notification from the donor PSP.
8 End-user Action
End-user may cancel or confirm the portability.
The user has up to seven days to do so. To cancel the portability within this period, the user must perform active validation of the key. If the user does not cancel or confirm the portability within this period, the donor PSP must necessarily cancel the request, without the need for the user to send a response, proceeding directly to step 14. In this case, while the donor PSP does not cancel the request, the key will remain with the status “Awaiting Resolution”, in which it is blocked for alteration, but remains active for queries.
9 End-user Communication End-user sends communication to the donor PSP.
10 Donor PSP Communication Donor PSP receives communication from the user.
11 Donor PSP Action
If the user responds requesting cancellation of the portability, the PSP advances to step 14.
If the user responds requesting confirmation of the portability, the donor PSP removes the key from its internal database.
12 Donor PSP Communication If the key has been deleted from the internal database, the donor PSP informs the end-user about the key deletion.
13 End-user Communication End-user receives the information of key deletion.
14 Donor PSP Communication
Donor PSP informs the PSP with direct access about the conclusion of the process, informing the cancellation or confirmation of the portability, as the case may be.
15 PSP with direct access to DICT Communication PSP with direct access receives information.
16 PSP with direct access to DICT Message
PSP with direct access forwards information to the DICT about cancellation or confirmation, through the messages “Claim / Cancel Claim” or “Claim / Confirm Claim”, respectively, as the case may be.
33 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
17 DICT Message
DICT receives the information of cancellation or confirmation of the portability and continues the process (step 6 of the portability flow for the claiming PSP with indirect access to the DICT).
6 Key possession claim flow
As in the portability process, within the scope of the possession claim process, the donor PSP is the Pix participant to which the key is originally linked.
During the possession claim process, from the moment the DICT sets the request status to “Open” until the moment the DICT changes the status to “Complete”, the Pix key is not subject to registration and deletion requests 5. During the first seven days, while the request status is “Awaiting Resolution”, queries will continue to normally return the identification of the transactional account originally linked to the key. After the seventh day, if there is no indication of fraud or user consent, the donor PSP must confirm the claim. The key will be disassociated from the donor PSP and queries to the key will return the message “key does not exist”. During the resolution period, both the claiming PSP and the donor PSP may cancel the request, in case of suspected fraud or in case of cancellation request by the claiming PSP’s user. The request may also be cancelled by the claiming PSP if its status is “Open”. The resolution period for a possession claim process is seven days. If the donor user does not manifest within this resolution period, the donor PSP must necessarily confirm the claim in the DICT. In addition to the resolution period, there is a closing period, also of seven days, which begins immediately after the end of the resolution period. Throughout the closing period, the donor user may still validate possession of the key subject of the claim, by cancelling the claim. In this case, the donor PSP must cancel the process, due to indication of fraud. If, at the end of the closing period, the donor PSP has not cancelled the claim, the claiming PSP must request possession validation from its user and, after this validation, complete the request in the DICT. If the claiming user does not perform the possession validation by the thirtieth day after the start of the possession claim process, the claiming PSP must necessarily cancel the request in the DICT, so that the disputed key can be released. The DICT provides a service that allows querying and filtering possession claim processes. PSPs with direct access to the DICT must query this service at least once per minute in order to identify status changes of possession claims of interest to the PSP (in addition to those of interest to the PSPs with indirect access for which it provides service), both as claimant and as donor.
6.1 Possession claim flow for the claiming PSP with direct access to the DICT
5 It is permitted for the donor PSP to update data linked to the key while the request status is “Open” or “Awaiting Resolution”.
34 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
1 Claiming PSP Action
The process is initiated after detecting that there is already a record for the requested key and after the user’s request.
Before sending the request to the DICT, the PSP must confirm the data and registration status of the end-user with the Federal Revenue. If the status is irregular or there is a discrepancy, the PSP must not initiate the process and go directly to step 14.
2 Claiming PSP Message
The claiming PSP sends a possession claim request to the DICT through the message “Claim / Create Claim” of type “Possession”.
3 DICT Message DICT receives the message with the key possession claim request.
4 DICT Action
DICT creates a possession claim request with status “Open”, with the key and claiming PSP data, and starts the counting of the resolution period, awaiting response from the donor PSP.
5 DICT Action
Once received, from the donor PSP, the confirmation or cancellation of the possession claim, DICT updates the request status to "Confirmed" or "Cancelled", as the case may be.
35 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
If the status is "Cancelled", the DICT changes the request status to “Complete”, finalizing the process.
If the status is “Confirmed”, the DICT blocks the key until the confirmation is received by the claiming PSP.
The block means that queries to this key in the DICT will return an error message.
6 Claiming PSP Action
Claiming PSP periodically queries the DICT until identifying a change in the status of the possession claim request, through the messages “Claim / List Claims” or “Claim / Query Claim”. The request may have three statuses: (i) “Cancelled”, with reason “Fraud”, if the user who originally registered the key performed active validation of the key possession by the 7th day; (ii) “Confirmed”, with reason “At user’s request”, if the user who originally registered the key confirmed the claim by the 7th day; or (iii) “Confirmed”, with reason “Standard”, if the user who originally registered the key did not manifest by the 7th day. In case (i), claiming PSP proceeds directly to step 14. In case (ii), claiming PSP proceeds to step 7. In case (iii), claiming PSP waits for the end of the closing period. If the user who originally registered the key performed active validation of the key possession between the 8th and 14th day, the request will change to status “Cancelled”, with reason “Fraud”. In this case, the flow proceeds directly to step 14. If the request status remains “Confirmed”, with reason “Standard”, at the end of the 14th day, the claiming PSP follows the flow from step 7.
7 Claiming PSP Action
If the request status is “Confirmed”, the claiming PSP performs possession validation of the key with the end-user.
8 Claiming PSP Message
If the possession validation has been successfully performed, the claiming PSP requests completion of the process in the DICT, through the message “Claim / Complete Claim”. If the possession validation has not been performed by the thirtieth day after the opening of the claim, the claiming PSP requests cancellation of the process in the DICT, through the message “Claim / Cancel Claim”, with reason “Standard”. In this case, DICT changes the status of the possession claim request to “Cancelled” and the flow is ended, with the key subject of the claim excluded from the DICT and available for a new registration.
36 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 9 DICT Mensagem DICT receives the request to conclude the claim.
10 DICT Ação DICT updates the data linked to the key and changes the status of the ownership claim request to “Complete”.
11 DICT Mensagem DICT sends a message confirming the update of the data linked to the key to the claiming PSP.
12 PSP reivindicador Mensagem Claiming PSP receives confirmation of the update of the data linked to the key.
13 PSP reivindicador Ação Claiming PSP updates its internal database.
14 PSP reivindicador Comunicação
Claiming PSP informs the end user about the cancellation or confirmation of the ownership claim request for the key.
15 Usuário final Comunicação
End user receives information about the cancellation or confirmation of the ownership claim request for the key.
6.2 Ownership claim flow for the claiming PSP with indirect access to
DICT
37 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Camada Tipo Descrição
1 PSP reivindicador Ação
The process is initiated after detecting that a record already exists for the requested key and after the user's request.
Before sending the request to DICT, the PSP must confirm the data and the user's registration status with the Federal Revenue. If the status is irregular or there is a discrepancy, the PSP must not initiate the process and proceed directly to step 22. 2 PSP reivindicador Comunicação The claiming PSP sends an ownership claim request to the PSP with direct access to DICT. PSP com acesso direto ao DICT Comunicação PSP with direct access to DICT receives the ownership claim request.
38 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 PSP com acesso direto ao DICT Mensagem PSP with direct access to DICT forwards the ownership claim request via the message “Claim / Create Claim”. 5 DICT Mensagem DICT receives the message with the ownership claim request. 6 DICT Ação DICT creates an ownership claim request with status “Open”, with the data of the key and the claiming PSP, and starts the resolution period countdown, awaiting response from the donor PSP. 7 DICT Ação Once received, from the donor PSP, the confirmation or cancellation of the ownership claim, DICT updates the request status to "Confirmed" or "Cancelled", as appropriate. If the status is "Cancelled", DICT changes the request status to “Complete”, finalizing the process. If the status is “Confirmed”, DICT blocks the key until receiving confirmation from the claiming PSP. The block means that queries to this key in DICT will return an error message. PSP com acesso direto ao DICT Ação PSP with direct access periodically queries DICT until identifying a change in the status of the ownership claim request, via the messages “Claim / List Claims” or “Claim / Query Claim”. The request can have three statuses: (i) “Cancelled”, with reason “Fraud”, if the user who originally registered the key performed active validation of the key's ownership until the 7th day; (ii) “Confirmed”, with reason “At user's request”, if the user who originally registered the key confirmed the claim until the 7th day; or (iii) “Confirmed”, with reason “Standard”, if the user who originally registered the key did not respond until the 7th day. In any of the cases, PSP with direct access proceeds to step 8. In case (iii), the PSP with direct access must wait until the end of the closure period (fourteen days after the start of the process), if the request is not cancelled by the donor PSP within this period, to proceed to step 9. PSP com acesso direto ao DICT Comunicação PSP with direct access sends communication to the claiming PSP, identifying whether the request status has changed to “Cancelled” or to “Confirmed”. 10 PSP reivindicador Comunicação Claiming PSP receives communication from the PSP with direct access informing of the change in the request status. If the status is "Cancelled", proceed directly to step 22.
39 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 11 PSP reivindicador Ação If the request status is “Confirmed”, the claiming PSP performs validation of the key's ownership with the end user. 12 PSP reivindicador Comunicação If ownership validation was successfully performed, the claiming PSP requests completion of the claim in DICT. If ownership validation was not performed by the thirtieth day after the claim was opened, the claiming PSP requests cancellation of the process in DICT. 13 PSP com acesso direto ao DICT Comunicação PSP with direct access receives the request. 14 PSP com acesso direto ao DICT Mensagem If ownership validation was successfully performed, PSP with direct access forwards the request to complete the claim in DICT via the message “Claim / Complete Claim”. If ownership validation was not performed by the thirtieth day after the claim was opened, the PSP with direct access forwards the request to cancel the claim in DICT via the message “Claim / Cancel Claim”, with reason “Standard”. In this case, DICT changes the status of the ownership claim request to “Cancelled” and the flow is ended, with the key subject to the claim excluded from DICT and available for a new registration. 15 DICT Mensagem DICT receives the request to complete the claim. 16 DICT Ação DICT updates the data linked to the key and changes the status of the ownership claim request to “Complete”. 17 DICT Mensagem DICT sends a message confirming the update of the data linked to the key to the PSP with direct access. 18 PSP com acesso direto ao DICT Mensagem PSP with direct access receives confirmation of the key update. 19 PSP com acesso direto ao DICT Comunicação PSP with direct access forwards confirmation of the key update. 20 PSP reivindicador Comunicação Claiming PSP receives confirmation of the update of the data linked to the key. 21 PSP reivindicador Ação Claiming PSP updates its internal database. 22 PSP reivindicador Comunicação Claiming PSP informs the end user about the cancellation or confirmation of the ownership claim request for the key. 23 Usuário final Comunicação End user receives information about the cancellation or confirmation of the ownership claim request for the key.
40 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
6.3 Ownership claim flow for the donor PSP with direct access to DICT
Camada Tipo Descrição
1 PSP doador Ação
Donor PSP periodically queries DICT for the list of ownership claims with status “Open” that refer to keys registered by it, via the message “Claim / List Claims”.
2 PSP doador Mensagem/
Comunicação
Upon identifying an ownership claim with status “Open”, donor PSP sends message “Claim / Receive Claim” to DICT and notifies the end user, requesting confirmation of the claim or validation of the key's ownership. If the donor PSP receives communication from the user by the 7th day, it advances to step 8. If the donor PSP does not receive communication from the user by the 7th day, the donor PSP proceeds directly to step 11.
41 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 3 DICT Mensagem DICT receives the message from the donor PSP.
4 DICT Ação
DICT changes the request status to “Awaiting
Resolution” and waits for receiving information about the ownership claim process.
Usuário final que registrou a chave originalmente Comunicação User receives notification from the donor PSP.
Usuário final que registrou a chave originalmente Ação User can validate the key's ownership or confirm the ownership claim.
The user has up to seven days to do so.
If the user responds by the 7th day, they advance to step 7.
If the user does not respond by the 7th day, they proceed directly to step 15.
Usuário final que registrou a chave originalmente Comunicação User sends communication to the donor PSP.
If the key has been validated, the process is finalized for them. The user retains ownership of the key.
If the ownership claim process has been confirmed, the process is finalized for them. The user loses ownership of the key.
8 PSP doador Comunicação
Donor PSP receives communication from the user.
If the user has confirmed the ownership claim, donor PSP advances to step 9.
If the user performs active validation of the key's ownership, the PSP proceeds directly to step 10.
9 PSP doador Ação Donor PSP removes the key from its internal database.
10 PSP doador Mensagem
Donor PSP sends message to DICT.
If the user has confirmed the ownership claim, PSP sends message “Claim / Confirm Claim”, with reason “At user's request”.
If the user has validated the key's ownership, PSP sends message “Claim / Cancel Claim”, for reason “Fraud”.
In any of the cases, the flow goes directly to step 13.
11 PSP doador Ação Donor PSP removes the key from its internal database.
12 PSP doador Comunicação/
Mensagem
Donor PSP notifies the user about the removal of the key and about the opening of an additional seven-day period for the user to still validate the key's ownership, cancelling the ownership claim process.
42 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 Donor PSP also sends message to DICT informing the removal of the key from its internal database via the message “Claim / Confirm Claim”, with reason “Standard”. 13 DICT Mensagem DICT receives the message from the donor PSP. 14 DICT Ação If the user who originally registered the key has responded by the 7th day, DICT continues the process (step 4 of the ownership claim flow for the claiming PSP with direct access to DICT). If DICT receives the confirmation message for the claim with reason “Standard”, DICT blocks the key and waits for the end of the closure period (between the 8th and 14th day). During this period, DICT may receive a message from the donor PSP, with the cancellation of the claim. If it receives the message, DICT goes to step 20. If it does not receive, DICT continues the process (step 4 of the ownership claim flow for the claiming PSP with direct access to DICT). The block means that DICT will return the message “not registered”, if the key in question is subject to any query. Usuário final que registrou a chave originalmente Comunicação User receives notification from the donor PSP. If the user cancels the claim between the 8th and 14th day, they go to step 16. If the user does not cancel the claim between the 8th and 14th day, the flow is ended for them. Usuário final que registrou a chave originalmente Ação User can validate the key's ownership within seven days. If the key has been validated, the process is finalized for them. Since the key will have already been removed from the internal database and DICT, the user who originally registered the key must register their key again, if they so desire. Usuário final que registrou a chave originalmente Comunicação User sends communication to the donor PSP, cancelling the ownership claim process. 18 PSP doador Comunicação Donor PSP receives communication from the user. 19 PSP doador Mensagem Donor PSP sends message to DICT. If the user has validated the key's ownership, PSP sends message “Claim / Cancel Claim”, for reason “Fraud”.
43 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 20 DICT Mensagem DICT receives the information of cancellation of the ownership claim and continues the process (step 4 of the ownership claim flow for the claiming PSP with direct access to DICT).
6.4 Ownership claim flow for the donor PSP with indirect access to DICT
Camada Tipo Descrição
PSP com acesso direto ao DICT Ação
PSP with direct access periodically queries DICT for the list of ownership claims with status “Open” that refer to keys registered by the donor PSP to
44 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 which it provides services, via the message “Claim / List Claims”.
PSP com acesso direto ao DICT
Mensagem/
Comunicação
Upon identifying an ownership claim with status “Open”, PSP with direct access sends message “Claim / Receive Claim” to DICT and sends communication to the donor PSP.
3 PSP doador Comunicação Donor PSP receives communication.
4 PSP doador Comunicação
Donor PSP notifies the end user, requesting confirmation of the claim or validation of the key's ownership.
If the donor PSP receives communication from the user by the 7th day, it advances to step 10.
If the donor PSP does not receive communication from the user by the 7th day, the donor PSP proceeds directly to step 15.
5 DICT Mensagem DICT receives the message from the PSP with direct access.
6 DICT Ação
DICT changes the request status to “Awaiting
Resolution” and waits for receiving information about the ownership claim process.
Usuário final que registrou a chave originalmente Comunicação User receives notification from the donor PSP.
Usuário final que registrou a chave originalmente Ação User can validate the key's ownership or confirm the ownership claim.
The user has up to seven days to do so.
If the user responds by the 7th day, they advance to step 9.
If the user does not respond by the 7th day, they proceed directly to step 21.
Usuário final que registrou a chave originalmente Comunicação User sends communication to the donor PSP.
If the key has been validated, the process is finalized for them. The user retains ownership of the key.
If the ownership claim process has been confirmed, the process is finalized for them. The user loses ownership of the key.
10 PSP doador Comunicação
Donor PSP receives communication from the user.
If the user has confirmed the ownership claim, donor PSP advances to step 11.
If the user performs active validation of the key's ownership, the PSP proceeds directly to step 12.
11 PSP doador Ação Donor PSP removes the key from its internal database.
45 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 12 PSP doador Comunicação Donor PSP sends communication to PSP with direct access. 13 PSP com acesso direto ao DICT Comunicação PSP with direct access receives communication. PSP com acesso direto ao DICT Mensagem PSP with direct access sends message to DICT. If the user has confirmed the ownership claim, PSP sends message “Claim / Confirm Claim”, with reason “At user's request”. If the user has validated the key's ownership, PSP sends message “Claim / Cancel Claim”, for reason “Fraud”. In any of the cases, the flow goes directly to step 19. 15 PSP doador Ação Donor PSP removes the key from its internal database. 16 PSP doador Comunicação Donor PSP notifies the user about the removal of the key and about the opening of an additional seven-day period for the user to still validate the key's ownership, cancelling the ownership claim process. Donor PSP also sends communication to the PSP with direct access, informing the removal of the key from its internal database. 17 PSP com acesso direto ao DICT Comunicação PSP with direct access receives communication. 18 PSP com acesso direto ao DICT PSP with direct access sends message to DICT informing the removal of the key from the donor PSP's internal database, via the message “Claim / Confirm Claim”, with reason “Standard”. 19 DICT Mensagem DICT receives the message from the PSP with direct access. 20 DICT Ação If the user who originally registered the key has responded by the 7th day, DICT continues the process (step 4 of the ownership claim flow for the claiming PSP with direct access to DICT). If DICT receives the confirmation message for the claim with reason “Standard”, DICT blocks the key and waits for the end of the closure period (between the 8th and 14th day). During this period, DICT may receive a message with the cancellation of the claim. If it receives the message, DICT goes to step 28.
46 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5 If it does not receive, DICT continues the process (step 4 of the ownership claim flow for the claiming PSP with direct access to DICT). The block means that DICT will return the message “not registered”, if the key in question is subject to any query. Usuário final que registrou a chave originalmente Comunicação User receives notification from the donor PSP. If the user cancels the claim between the 8th and 14th day, they go to step 22. If the user does not cancel the claim between the 8th and 14th day, the flow is ended for them. Usuário final que registrou a chave originalmente Ação User can validate the key's ownership within seven days. If the key has been validated, the process is finalized for them. Since the key will have already been removed from the internal database and DICT, the user who originally registered the key must register their key again, if they so desire. Usuário final que registrou a chave originalmente Comunicação User sends communication to the donor PSP, cancelling the ownership claim process. 24 PSP doador Comunicação Donor PSP receives communication from the user. 25 PSP doador Comunicação Donor PSP sends communication to the PSP with direct access. 26 PSP com acesso direto ao DICT Comunicação PSP with direct access receives communication. 27 PSP com acesso direto ao DICT Mensagem PSP with direct access sends message to DICT. If the user has validated the key's ownership, PSP sends message “Claim / Cancel Claim”, for reason “Fraud”. 28 DICT Mensagem DICT receives the information of cancellation of the ownership claim and continues the process (step 6 of the ownership claim flow for the claiming PSP with direct 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)
47 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
48 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Camada Tipo Descrição
1 PSP reivindicador Ação Process can be initiated by the user or by the PSP itself.
2 PSP reivindicador Ação
If the change is of full name, business name or trade name, PSP validates the changed data with the user's registration at the Federal Revenue.
3 PSP reivindicador Mensagem
Claiming PSP sends request to change the data (full name, business name, trade name, branch or branch and account) linked to the key, via the message “Directory / Update Link”. 4 DICT Mensagem DICT receives the request to change the data forwarded by the claiming PSP. 5 DICT Ação DICT checks if the key is registered for the PSP and for the users involved. If the result is negative, the request is rejected and proceeds to step 6. 6 DICT Ação If DICT verifies that the key belongs to the PSP and users involved, the data linked to the key is changed. 7 DICT Mensagem DICT informs the confirmation or rejection of the request to change the data. 8 PSP reivindicador Mensagem Claiming PSP receives information of confirmation or rejection from DICT. 9 PSP reivindicador Ação After receiving the information of change of data linked to the key, the claiming PSP updates its internal database with the new data of the key. 10 PSP reivindicador Comunicação Claiming PSP informs the end user about the cancellation or confirmation of the request to change the data. 11 Usuário final Comunicação End user receives information of confirmation or cancellation of the change of data.
7.2 Flow for changing data linked to the key (Pix participants with
indirect access to DICT)
49 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
50 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Camada Tipo Descrição
1 PSP reivindicador Ação Process can be initiated by the user or by the PSP itself.
2 PSP reivindicador Ação
If the change is of full name, business name or trade name, PSP performs the user's registration validation at the Federal Revenue.
3 PSP reivindicador Comunicação
Claiming PSP sends request to change the data (full name, business name, trade name, branch or branch and account) linked to the key.
PSP com acesso direto ao DICT Comunicação PSP with direct access to DICT receives request to change the data.
PSP com acesso direto ao DICT Mensagem
PSP with direct access forwards request to change the data to DICT via the message “Directory / Update Link”.
51 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
6 DICT Message DICT receives the request to alter the data.
7 DICT Action DICT verifies whether the PSP with direct access can send requests to the claiming PSP.
8 DICT Action DICT verifies whether the key is registered for the claiming PSP and for the users involved. If the result is negative, the request is rejected and proceeds to step 9. 9 DICT Action If DICT verifies that the key belongs to the claiming PSP and the users involved, the data linked to the key are altered. 10 DICT Message DICT informs the confirmation or rejection of the request to alter the data. 11 PSP with direct access to DICT Message PSP with direct access to DICT receives information of confirmation or rejection of the request to alter the data. 12 PSP with direct access to DICT Communication PSP with direct access to DICT forwards information of confirmation or rejection of the request to alter the data. 13 Claiming PSP Communication Claiming PSP receives information of confirmation or rejection. 14 Claiming PSP Action After receiving the information of alteration of the data linked to the key, the claiming PSP updates its internal database with the new data of the key. 15 Claiming PSP Communication Claiming PSP informs the end user about the cancellation or confirmation of the request to alter the data. 16 End User Communication End User receives the information of confirmation or cancellation of the alteration of the data.
7.3 Alteration of the data linked to the key to correct inconsistencies
In the event of alteration of the data linked to the Pix key regardless of user request, the participant must include in the communication made to the user the reasons for the alteration.
8 Key query flow
DICT will return the following information after the query of a key (whenever the key is registered):
- queried key;
- type of the queried key;
- identification (ISPB) of the participant that registered the queried key;
- branch number linked to the queried key (if any);
- account number linked to the queried key;
- type of the account linked to the queried key;
- date of opening of the account linked to the queried key;
52 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
- legal nature of the user that registered the queried key;
- identification (CPF or CNPJ) of the user that registered the queried key;
- full name of the user that registered the queried key, which, at the discretion of the end user, may be the civil name or the social name, as registered in the CPF, in case the queried key is linked to an individual user;
- business name of the user that registered the queried key, as registered in the CNPJ, in case the queried key is linked to a legal entity user;
- establishment title (trade name) of the user that registered the queried key, if registered in the CNPJ, in case the queried key is linked to a legal entity user;
- date of registration of the queried key in DICT;
- date of registration of the queried key in the current participant linked to the key;
- date of opening of the portability or of the claim of possession of the date consulted, in case any of these operations is open at the moment of the query of the key.
In addition to the data above, the participant may inform, through the optional parameter includeStatistics, whether the security information of the key should be inserted in the DICT response. If the parameter is omitted, only the data registered linked to the key will be returned. The detail of the security information is available in section 18.
8.1 Key data allowed in display to the user
Of the information returned by DICT in the key query, only some can be made available to the user who makes the query, whether through the application, internet banking, internal systems or the PSP API:
- full name or business name 6 of the user that registered the queried key;
- establishment title (trade name) of the user that registered the queried key, in case it is linked to a legal entity user;
- masked CPF (example: *.777.888-) or CNPJ of the user that registered the queried key;
- queried key;
- name of the receiving PSP (optional).
8.2 Query flow for the Pix participant with direct access to DICT
6 In the case of an individual user application, as determined by the Minimum Requirements for User Experience manual, the business name can only be made available if the trade name is not registered in the Pix key.
53 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Layer Type Description
1 Payer User Action Payer user accesses their service channel.
2 Payer User Action
Payer user inserts, manually or through reading a QR Code, the data of the key, which can correspond to any of the five existing types, of the receiving user.
3 Payer User Communication Payer user forwards request to their PSP.
PSP of the payer user Communication PSP of the payer user receives request.
PSP of the payer user Action PSP verifies whether the key is registered in its internal database.
PSP of the payer user Action
If the key is registered in its internal database, the PSP creates a response message. After, proceeds directly to step 15.
PSP of the payer user Message
If the key is not registered in its internal database, the PSP of the payer user sends a query message to DICT, in which it must inform, in addition to the Pix key, the unique identifier of the transaction that will be used in the settlement message. This unique identifier corresponds to the EndToEndId field, which is a mandatory field of the PACS.008 settlement message. It
54 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
should be generated by the PSP and transmitted during the query operation and again in the PACS.008. Another information that should be sent is the identifier of the payer user (their CPF or CNPJ). The query message is “Directory / Consult Link”. 8 DICT Message DICT receives message with query request. 9 DICT Action DICT verifies whether the institution is authorized to perform queries. 10 DICT Action DICT verifies whether the key is registered. If the payer's PSP is the same PSP linked to the key, DICT will reject the query and return an error message. 11 DICT Action If the key is registered, DICT creates a response message, which must contain all data linked to the key. 12 DICT Action If the key is not registered, DICT creates a message informing the non-existence of the queried key. 13 DICT Message DICT sends response message to the query. 14 PSP of the payer user Message PSP of the payer user receives message with the response to the query. 15 PSP of the payer user Communication PSP of the payer user forwards response to the query to the end user. The CPF registration number, if present in the response, must be made available in the format *.111.111- (replaces the beginning and end numbers with asterisks). 16 Payer User Communication Payer user receives message of response to their query.
8.3 Query flow for the Pix participant with indirect access to DICT
55 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Layer Type Description
1 Payer User Action Payer user accesses their service channel.
2 Payer User Action
Payer user inserts, manually or through reading a QR Code, the data of the key, which can correspond to any of the five existing types, of the receiving user.
3 Payer User Communication Payer user forwards request to their PSP.
PSP of the payer user Communication PSP of the payer user receives request.
PSP of the payer user Action PSP verifies whether the key is registered in its internal database.
PSP of the payer user Action
If the key is registered in its internal database, the PSP creates a response message. After, proceeds directly to step 21.
56 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
PSP of the payer user Communication
If the key is not registered in its internal database, the PSP of the payer user sends communication to the PSP with direct access, requesting query to DICT.
PSP with direct access to DICT Communication PSP with direct access receives communication with the query request.
PSP with direct access to DICT Action PSP with direct access to DICT verifies whether the key is registered in its internal database.
10 PSP with direct access to DICT Action If the key is registered in its internal database, proceeds directly to step 19.
11 PSP with direct access to DICT Message
If the key is not registered in its internal database, PSP with direct access to DICT forwards message with query request to DICT. The message must contain, in addition to the Pix key, the unique identifier of the transaction that will be used in the settlement message. This unique identifier corresponds to the EndToEndId field, which is a mandatory field of the PACS.008 settlement message. It should be generated by the PSP and transmitted during the query operation and again in the PACS.008. Another information that should be sent is the identifier of the payer user (their CPF or CNPJ). The query message is “Directory / Consult Link”. 12 DICT Message DICT receives message with query request. 13 DICT Action DICT verifies whether the institution is authorized to perform queries. DICT must also verify whether the PSP with direct access is authorized to query keys for the PSP with indirect access. 14 DICT Action DICT verifies whether the key is registered. If the payer's PSP is the same PSP linked to the key, DICT will reject the query and return an error message. 15 DICT Action If the key is registered, DICT creates a response message, which must contain all data linked to the key. 16 DICT Action If the key is not registered, DICT creates a message informing the non-existence of the queried key. 17 DICT Message DICT sends response message to the query. 18 PSP with direct access to DICT Message PSP with direct access to DICT receives response to the query. 19 PSP with direct access to DICT Communication PSP with direct access to DICT communicates to the PSP of the payer user the response to the query. 20 PSP of the payer user Communication PSP of the payer user receives communication about the response to the query. 21 PSP of the payer user Communication PSP of the payer user forwards response to the query to the end user.
57 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
The CPF registration number, if present in the response, must be made available in the format *.111.111- (replaces the beginning and end numbers with asterisks).
22 Payer User Communication Payer user receives message of response to their query.
8.4 Query flow for the Pix participant that acts as a payment transaction initiation service provider, with direct access to DICT
Layer Type Description
1 Payer User Action Payer user accesses the interface of the participant that provides payment transaction initiation service.
2 Payer User Action
Payer user inserts, manually or through reading a QR Code, the data of the key, which can correspond to any of the five existing types, of the receiving user.
3 Payer User Communication Payer user forwards request.
Initiation Service Provider Communication Initiation service provider receives request.
Initiation Service Provider Message Initiation service provider sends query message to DICT, in which it must inform the Pix key of the receiving user. In addition to the Pix key, the initiation service provider must inform the unique identifier of the transaction that will be used in the settlement message. This unique identifier corresponds to the
58 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
EndToEndId field, which is a mandatory field of the PACS.008 settlement message. It should be generated by the initiation service provider, sent to DICT in the query operation and transmitted by the payer's PSP in the PACS.008 sent to the SPI. Another information that should be sent is the identifier of the payer user (their CPF or CNPJ). The query message is “Directory / Consult Link”. Initiating participants must identify themselves, in the query message, through the first eight digits of their CNPJ (field PI-RequestingParticipant). 6 DICT Message DICT receives message with query request. 7 DICT Action DICT verifies whether the institution is authorized to perform queries. 8 DICT Action DICT verifies whether the key is registered. 9 DICT Action If the key is registered, DICT creates a response message, which must contain all data linked to the key. 10 DICT Action If the key is not registered, DICT creates a message informing the non-existence of the queried key. 11 DICT Message DICT sends response message to the query. Initiation Service Provider Message Initiation service provider receives message with the response to the query. Initiation Service Provider Communication Initiation service provider forwards response to the query to the end user. The CPF registration number, if present in the response, must be made available in the format *.111.111- (replaces the beginning and end numbers with asterisks). 14 Payer User Communication Payer user receives message of response to their query.
8.5 Query flow for the Pix participant that acts as a payment transaction initiation service provider, with indirect access to DICT
59 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Layer Type Description
1 Payer User Action Payer user accesses the interface of the participant that provides payment transaction initiation service.
2 Payer User Action
Payer user inserts, manually or through reading a QR Code, the data of the key, which can correspond to any of the five existing types, of the receiving user.
3 Payer User Communication Payer user forwards request.
Initiation Service Provider Communication Initiation service provider receives request.
Initiation Service Provider Communication Initiation service provider sends communication to the PSP with direct access, requesting query to DICT. In addition to the Pix key, the initiation service provider must inform the unique identifier of the transaction that will be used in the settlement message. This unique identifier corresponds to the EndToEndId field, which is a mandatory field of the PACS.008 settlement message. It should be generated by the initiation service provider,
60 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
sent to DICT by the PSP with direct access in the query operation and transmitted by the payer's PSP in the PACS.008 sent to the SPI. Another information that should be sent is the identifier of the payer user (their CPF or CNPJ). PSP with direct access to DICT Communication PSP with direct access receives communication with the query request. PSP with direct access to DICT Action PSP with direct access to DICT verifies whether the key is registered in its internal database. PSP with direct access to DICT Action If the key is registered in its internal database, proceeds directly to step 17. PSP with direct access to DICT Message If the key is not registered in its internal database, PSP with direct access to DICT forwards message with query request. The query message is “Directory / Consult Link”. Initiating participants must be identified, in the query message, through the first eight digits of their CNPJ (field PI-RequestingParticipant). 10 DICT Message DICT receives message with query request. 11 DICT Action DICT verifies whether the institution is authorized to perform queries. DICT must also verify whether the PSP with direct access is authorized to query keys for the initiation service provider. 12 DICT Action DICT verifies whether the key is registered. 13 DICT Action If the key is registered, DICT creates a response message, which must contain all data linked to the key. 14 DICT Action If the key is not registered, DICT creates a message informing the non-existence of the queried key. 15 DICT Message DICT sends response message to the query. 16 PSP with direct access to DICT Message PSP with direct access receives message with the response to the query. 17 PSP with direct access to DICT Communication PSP with direct access communicates to the initiation service provider the response to the query. 18 Initiation Service Provider Communication Initiation service provider receives communication about the response to the query. 19 Initiation Service Provider Communication Initiation service provider forwards response to the query to the end user. The CPF registration number, if present in the response, must be made available in the format *.111.111- (replaces the beginning and end numbers with asterisks). 20 Payer User Communication Payer user receives message of response to their query.
61 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
9 Synchronization verification flow
The synchronization verification process relies on two concepts: content identifier (CID) and synchronization verifier (VSync).
CID is a unique 256-bit number generated from a hash of the state of the key (key together with the information linked to it). Its creation rule is specified in the DICT API. Using the formation rule, the CID is calculated independently by the Pix participant and by DICT. The Pix participant must store this number in its internal database, preferably in an indexed manner, as the synchronization verification process will be based on it. The use of the CID allows: (i) simplified comparison between two records, as it is simpler to compare two numbers than two keys with various attributes; (ii) the possibility of internal verification of the integrity of each key record, allowing to identify a change made directly on an attribute without the update of the CID; and (iii) the possibility of generating the VSync in an optimized way. VSync is the result of applying an XOR function (exclusive 'or') on a set of CIDs. As the CIDs are unique, random and sufficiently large, the XOR operation between CIDs maintains the chance of collision of the CIDs themselves (infinitesimally small). Thus, it is possible to guarantee that, if the VSync generated by DICT and by the Pix participant are the same, the set of CIDs is the same and both have the same keys with the same attributes. Each participant must maintain five VSyncs, one for each set of CIDs by key type (CPF, CNPJ, mobile phone number, email and random key). The PSP can verify the synchronization between its database and DICT using the following functionalities: (i) VSync synchronization verification; (ii) log of key alterations of the participant; and (iii) file of CIDs registered in DICT. For the VSync synchronization verification, the PSP must inform the VSyncs of each key type. DICT will respond whether the set is synchronized or not. If the synchronization verification fails, the PSP must take actions to correct the divergences. After the corrections, the PSP must send the VSync again. The synchronization verification process can be simpler if performed outside the mandatory window for providing record, deletion, alteration, portability and claim of possession. Thus, the participant can temporarily suspend these functionalities, perform the VSync calculation and act to correct any divergences, without worrying about concurrent alterations in the set of CIDs. The Pix participant can also monitor the log of key alterations. The log shows the CIDs that are being registered and excluded from DICT, from the operations performed by the participant. Thus, it is recommended for the participant to build a monitoring mechanism for the log, ensuring that its database is continuously synchronized with DICT. Finally, in case a complete reconciliation is necessary, it is possible to perform individual verification of the participant's keys, requesting a file with the CIDs registered in DICT. This file contains
62 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
the CIDs of all active keys, without any additional information, aiming to simplify the storage and distribution of this file, from a security point of view. Thus, the participant must look for the CIDs stored in its internal database and verify if there is the same entry listed in the file. From the matching of the file with the participant's internal database, there may be divergences of two types: (i) CIDs that exist only in the file (and not in the participant's database); and (ii) CIDs that exist only in the participant (and not in the file). It is recommended for participants to maintain, on their side, the record of all CIDs already generated, associated with the key involved in the operation. This will allow to identify, in cases of divergences, which key originated it. If the participant does not locate the CID in its database, it can still perform a query based on the CID and receive the data linked to the key as a response. Any necessary modification resulting from the synchronization verification process must be performed:
- for keys registered only in DICT, and not in the participant, the key must be included in the participant's database with the same attributes registered in DICT;
- for keys registered only in the participant, and not in DICT, the key must be removed from the participant's database; and
- for keys registered in both databases, but with divergent values, there must be correction of the values in the participant's database, exactly as stated in the DICT database.
DICT makes available the reason “reconciliation” for when it is necessary to update information due to errors in the participant's processes, for example when entering account data incorrectly. The other alterations must, whenever possible, use the reasons related to the fact that generated the loss of synchronization. It is important to emphasize that, upon completion of the corrections, the participant must generate the VSync again and send it to DICT to confirm synchronization. If the databases are still divergent, the participant must restart the reconciliation process.
9.1 VSync verification (Pix participant with direct access to DICT)
Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| PSP with direct access to DICT | Action | PSP accesses communication channel with DICT. | |
| PSP with direct access to DICT | Message | PSP sends to DICT the synchronization checkers for each type of key registered in its internal database through “Reconciliation / Check Synchronization” messages. | |
| 3 | DICT | Message | DICT receives message with synchronization checkers from PSP with direct access. |
| 4 | DICT | Action | DICT identifies the synchronization checkers generated for each type of key of the PSP. The DICT checkers are then compared with the PSP checkers. |
| 5 | DICT | Message | DICT sends response of matches (OK) or does not match (NOK) by key type to PSP with direct access. |
| PSP with direct access to DICT | Message | PSP with direct access receives verification response by key type. |
9.2 VSync Verification (Pix participant with indirect access to DICT)
| # | Layer | Type | Description |
|---|---|---|---|
| PSP with indirect access to DICT | Action | PSP without direct access accesses communication channel with PSP with direct access to DICT. | |
| PSP with indirect access to DICT | Communication | PSP without direct access sends to PSP with direct access the synchronization checkers for each type of key registered in its internal database. | |
| PSP with direct access to DICT | Communication | PSP with direct access to DICT receives synchronization checkers from PSP without direct access. | |
| PSP with direct access to DICT | Message | PSP with direct access forwards message to DICT with synchronization checkers from PSP with indirect access through “Reconciliation / Check Synchronization” messages. | |
| 5 | DICT | Message | DICT receives message with synchronization checkers from PSP with indirect access. |
| 6 | DICT | Action | DICT verifies if PSP with direct access has authorization to forward requests to PSP with indirect access. |
| 7 | DICT | Action | DICT identifies the synchronization checkers generated for each type of key of the PSP with indirect access. The DICT checkers are then compared with the checkers of this PSP. |
| 8 | DICT | Message | DICT sends response of matches (OK) or does not match (NOK) by key type to PSP with direct access. |
| PSP with direct access to DICT | Message | PSP with direct access receives verification response from DICT. | |
| 10 | PSP with direct access to DICT | Communication | PSP with direct access forwards verification response to PSP with indirect access. |
| 11 | PSP with indirect access to DICT | Communication | PSP with indirect access receives verification response by key type. |
9.3 CID List
To obtain the list of CIDs, it is necessary for the participant to request a specific type of key. Thus, on demand, DICT generates the list of CIDs of a certain type that are registered by the requesting participant.
The CID list is generated asynchronously. The participant with direct access makes the request and DICT starts the generation process, returning an ID to the participant. The participant must consult DICT periodically to check the status of the list generation. Once the process is completed, DICT changes the status of the request and makes available the file name and the URL for download. The download must be done via HTTPS connection in a service provided in the environment of the National Financial System Network (RSFN).
9.3.1 Pix Participant with Direct Access
| # | Layer | Type | Description |
|---|---|---|---|
| PSP with direct access to DICT | Action | PSP accesses communication channel with DICT. | |
| PSP with direct access to DICT | Message | PSP requests list of its keys, by specific type, through the message “Reconciliation / Create CID File”. | |
| 3 | DICT | Message | DICT receives message with the request. |
| 4 | DICT | Action | DICT generates list with specific type keys of PSP with direct access. |
| 5 | DICT | Action | DICT changes the status of the request and makes available the name of the generated file and the URL for download. |
| PSP with direct access to DICT | Action | PSP with direct access identifies change in status and file name with CID list through the message “Reconciliation / Consult CID File”. PSP performs download via the provided URL. |
9.3.2 Pix Participant with Indirect Access
| # | Layer | Type | Description |
|---|---|---|---|
| PSP with indirect access to DICT | Action | PSP with indirect access accesses communication channel with PSP with direct access to DICT. | |
| PSP with indirect access to DICT | Communication | PSP with indirect access requests list of its keys, by specific type. | |
| PSP with direct access to DICT | Communication | PSP with direct access receives request from PSP with indirect access. | |
| PSP with direct access to DICT | Message | PSP with direct access forwards request to DICT through the message “Reconciliation / Create CID File”. | |
| 5 | DICT | Message | DICT receives message with the request. |
| 6 | DICT | Action | DICT verifies if PSP with direct access has authorization to forward requests to PSP with indirect access. |
| 7 | DICT | Action | DICT generates list with specific type keys of PSP with indirect access. |
| 8 | DICT | Action | DICT changes the status of the request and makes available the name of the generated file and the URL for download. |
| PSP with direct access to DICT | Action | PSP with direct access identifies change in status and file name with CID list through the message “Reconciliation / Consult CID File”. PSP performs download via the provided URL. | |
| 10 | PSP with direct access to DICT | Communication | PSP with direct access forwards list of specific type keys to PSP with indirect access. |
| 11 | PSP with indirect access to DICT | Communication | PSP with indirect access receives list of specific type keys. |
10 Infringement Notification Flow
Infringement notification must be made exclusively for Pix transactions with well-founded suspicion of fraud 7. It cannot be made for transactions carried out within the scope of other payment arrangements.
In the DICT API, infringement notification can be created through two distinct endpoints: “Create Funds Recovery” (createFundsRecovery) and “Create Fraud Marker” (createFraudMarker).
In the “transactional fraud marker” endpoint, infringements that have the sole and exclusive purpose of marking CPFs, CNPJs, and user keys involved in fraud related to Pix transactions and who are clients of the participant creating the marker must be notified.
In the “Funds Recovery” endpoint, infringement notification for refund request is opened automatically by DICT. This flow is part of the macroprocess described in section 20 - Funds Recovery Flow.
10.1 Infringement Notification for Refund Request
All infringement notifications created within the scope of Funds Recovery are of the type “refund request”. This applies even in the case of Funds Recovery opened for a refund transaction, when there is a suspicion of fraud against the payer user who had originally requested the refund.
An infringement notification for refund request can have the following states in DICT:
- opened: the infringement notification was opened by the PSP;
- received: the infringement notification was received by the PSP;
- analyzed/concluded/closed: the infringement notification was analyzed by the PSP that received it and the result of this analysis is available; or
- cancelled: the PSP that opened the notification can cancel the notification at any time, even after it has already been analyzed. Infringement notifications associated with a Funds Recovery cannot be cancelled individually, only through the cancellation of the Funds Recovery, as per section 20, Funds Recovery. The infringement notification will be automatically cancelled by DICT if the NI of a previous layer is rejected, so that there is no longer a connection between the receiver of the transaction under analysis and the payer of the root transaction.
An infringement notification for refund request is opened automatically by DICT from the establishment of a Funds Recovery by the payer's PSP and must be closed by the receiver's PSP of the transaction. This type of notification is used in cases where the payer's PSP wishes to recover the values of a Pix transaction with well-founded suspicion of fraud. At the time of creation of a notification of this type, DICT associates the transaction to which the notification refers through the field TransactionId. This applies both to the root transaction and to subsequent transactions identified in the tracing stage. Additionally, when applicable, a refund transaction (pacs.004) can be informed at the opening of the Funds Recovery, identified by its RtrId.
The infringement notification for refund request contains the following fields, whose information is automatically assigned by DICT from the information inserted by the payer's PSP at the opening of the Funds Recovery:
| Field | Mandatory or Optional | Description |
|---|---|---|
| Reason for opening the notification (Reason) | Mandatory | Domain: - refund request (refund_request) |
| EndToEndID or RtrId (TransactionId) | Mandatory | Identifier of the payment transaction (EndToEndID) or identifier of the refund transaction (RtrId) |
| Cause of fraud (SituationType) | Mandatory | Domains: - scam - unauthorized transaction (account_takeover) - coercion crime (coercion) - fraudulent access and authorization (fraudulent_access) - other (other) |
| Contact Email (Email) | Optional | In the infringement notification of the root transaction, the email will be the same as informed in the Funds Recovery. In the infringement notifications of subsequent transactions this field will be empty. (*) |
| Contact Phone (Phone) | Optional | In the infringement notification of the root transaction, the contact phone will be the same as informed in the Funds Recovery. In the infringement notifications of subsequent transactions this field will be empty. (*) |
| Comments (ReportDetails) | Mandatory, if SituationType = “other” | The infringement notification of the root transaction will have the same content informed in the Funds Recovery. For the infringement notifications of subsequent transactions this field will be filled with a standard message guiding the PSP to consult the information in the Funds Recovery. |
| Depth in the graph (TransactionDepth) | Mandatory | Level of the tracing graph layer in which the transaction linked to the infringement notification is found. The infringement notification of the root transaction has depth 1. The infringement notifications of the transactions identified in the second layer have depth 2, and so on. () |
(*) For infringement notifications of subsequent transactions, contact information from the Funds Recovery must be consulted.
() Infringement notifications generated before this change will be updated following the same rule, and those not linked to a Funds Recovery will receive the value 1.
The domains of the “SituationType” field must be used as explained below:
- scam: transaction that was initiated by the payer user due to scam/fraud (social engineering scams, false intermediary, false seller, etc.);
- account_takeover: transaction that was initiated without the payer user having authorized the transaction through digital authentication (transaction initiated by third party without the use of digital authentication);
- coercion: transaction that was initiated by the payer user under coercion or extortion (kidnapping, false kidnapping of an acquaintance, etc.);
- fraudulent_access: transaction that was initiated by a third party who had access to the transaction initiation interface and managed to authenticate and authorize the transaction, but who is not recognized by the payer user (social engineering scams, such as the false employee, who obtains the payer user's password and initiates authenticated transactions with password obtained in this way); and
- other: any case that does not fit appropriately into the four previous cases.
An infringement notification can be opened and accepted even in cases where the receiver user acts as a payment intermediary 8 and the final recipient of the transaction is not necessarily this intermediary.
When sending message to DICT to close an infringement notification for refund request, the receiver's PSP (or the PSP with direct access to DICT, or the payer's PSP, as the case may be) must inform the following fields:
| Field | Mandatory or Optional | Description |
|---|---|---|
| Analysis Result (AnalysisResult) | Mandatory | Possible results: - agreed; or - disagreed |
| Fraud Type (FraudType) | Mandatory, if AnalysisResult = “agreed” | Domains: - ideological falsehood, i.e., the fraudster opened the account used to apply the fraud using another person's documents (application_fraud) - mule account, i.e., the account used to receive fraud resources was opened legitimately (mule_account) - the account used to receive fraud resources was in the name of the fraudster himself (scammer_account) - other (other) |
| Comments (AnalysisDetails) | Mandatory, if FraudType = “other” | Free text field, with information about the analysis of the infringement notification, including reasons for eventual rejection of the notification. |
An infringement notification for refund request that has been accepted automatically generates a fraud marker for the receiver user of the transaction indicated in the TransactionId field.
8 Defined as payment intermediary the legal entity agent that establishes a legal relationship with a final user for the provision or use of services involving charges, payments, receipts, and other similar activities through Pix; and that has an account in its own name, with a Pix participant, to receive resources from a payer in favor of the final recipient. Included in the concept of payment intermediary are national and international marketplaces, collection agents (or billing agents or collection agents), payment intermediaries, among others. Intermediaries, in general, hold graphic accounts (or pocket accounts) of their clients, who are the final recipients of Pix transactions, and manage these resources and their subsequent transfer to them.
An infringement notification can only be cancelled by the participant that opened it. Infringement notifications linked to a Funds Recovery cannot be cancelled individually. They will be automatically cancelled if the Funds Recovery is cancelled. If a closed infringement notification is cancelled, the fraud marker generated by it is also automatically cancelled. The participant who accepted the infringement notification, if they change their mind, can cancel only the fraud marker, through the CancelFraudMarker endpoint. If the rejection of an infringement notification causes subsequent transactions to no longer be connected to the payer of the root transaction, DICT will automatically cancel the infringement notifications linked to the thus disconnected transactions.
The recovering PSP must cancel the Funds Recovery if it verifies that it is not a case suitable for MED. If the recovering PSP 9 cancels a Funds Recovery, it is assumed that there was no fraud, and therefore DICT will also cancel all infringement notifications that were created. If there has been a refund, the recovering participant must reimburse the refunded resources. In this case, the provisions of section 20.1.10 “Cancellation of Funds Recovery” must be observed.
After the receiver's PSP has analyzed and concluded the infringement notification, if they have accepted the notification, they must wait for the start of the refund stage or the conclusion of the Funds Recovery, as described in section 20 “Funds Recovery Flow”.
10.1.1 Infringement Notification Flow for Opening Refund Request
The analysis of infringement notifications by participants is part of the analysis stage of the Funds Recovery. Thus, the provisions of section 20.3 “Analysis Flow” must be observed.
10.2 Infringement Notification for Transactional Fraud Marker
The infringement notification for transactional fraud marker must be used in cases where the PSP wishes only to mark the CPF or CNPJ of a user who is their client and who is involved in some episode of fraud related to a specific Pix transaction. It only needs to be created by the Pix participant through the CreateFraudMarker endpoint. Furthermore, it can, at any time, be cancelled 10 by the participant that created it.
The transactional fraud marker can be created by any PSP involved in a given Pix transaction. The PSP that creates the marker must be sure that its client is a fraudster. Whenever the Pix key of the fraudster is known, it must be informed, so that the key also receives the fraud marker. Examples, non-exhaustive, of cases in which the transactional fraud marker can be used:
9 Recovering PSP is the PSP that established the Funds Recovery.
10 A fraud marker that has been generated automatically through an infringement notification can be cancelled by the PSP that closed the notification, which has a relationship with the user who received the marker.
- well-founded suspicion of fraud of a Pix transaction settled outside the SPI (between clients of the same participant or between clients of different participants who have the same clearing participant);
- well-founded suspicion of fraud of a Pix transaction that was rejected, both by the payer's PSP and by the receiver's PSP;
- after a precautionary block, in cases where the resources of the original transaction were returned by the receiver's PSP – in this case, the one who opens the notification is the receiver's PSP;
- after identification of resources originating from a fraud by the receiver's PSP, with or without return of resources, without having received an infringement notification for refund request or without having made the precautionary block – in this case, the one who opens the notification is the receiver's PSP;
- well-founded suspicion of fraud of a Pix transaction settled in the SPI, when the payer's PSP wishes only to mark its own user, without the intention of recovering the resources.
When creating a transactional fraud marker in DICT, the PSP must inform the following fields:
| Field | Mandatory or Optional | Description |
|---|---|---|
| User (TaxIdNumber) | Mandatory | CPF or CNPJ of the user with well-founded suspicion of fraud |
| Key (Key) | Optional | Pix key of the user with well-founded suspicion of fraud (must be informed whenever it is known) |
| Fraud Type (FraudType) | Mandatory | Domains: - ideological falsehood, i.e., the fraudster opened the account used to apply the fraud using another person's documents (application_fraud) - mule account, i.e., the account used to receive fraud resources was opened legitimately (mule_account) - the account used to receive fraud resources was in the name of the fraudster himself (scammer_account) - other (other) |
10.2.1 Infringement Notification Flow for Transactional Fraud Marker between Pix Participants with Direct Access to DICT
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | PSP | Action | PSP identifies problem. |
| 2 | PSP | Message | PSP creates transactional fraud marker in DICT through the message “Fraud Marker / Create Transactional Fraud Marker”. |
| 3 | DICT | Message | DICT receives message with transactional fraud marker. |
10.2.2 Infringement Notification Flow for Transactional Fraud Marker between Pix Participants with Indirect Access to DICT
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | PSP | Action | PSP identifies problem. |
| 2 | PSP | Communication | PSP sends transactional fraud marker to its clearing participant in SPI. |
| PSP with direct access to DICT (clearing participant in SPI of PSP) | Communication | PSP with direct access receives transactional fraud marker. | |
| PSP with direct access to DICT (clearing participant in SPI of PSP) | Message | PSP with direct access creates transactional fraud marker in DICT through the message “Fraud Marker / Create Transactional Fraud Marker”. | |
| 5 | DICT | Message | DICT receives message with transactional fraud marker. |
11 Communication Interface
The DICT interface will provide all functionalities for maintenance and obtaining data of the transactional account linked to a key. Implementation details are available in the section on DICT in the Communication Interfaces Manual.
76 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
12 Key Consultation Cache
To reduce the load of requests to the DICT, consultations for keys linked to legal entity users may have their responses cached by the participant itself, following the maximum 180-second period defined in the Cache-Control header. It is recommended that the PSP not perform new consultations to the DICT for links saved in the cache that are within the validity period, under the risk of activating denial of service and read attack prevention mechanisms.
13 Read Attack Prevention Mechanisms
Read attacks are situations in which a user (or an intruder using the participant's structure) captures existing links in the DICT for purposes other than making payments. Read attacks can occur quickly and intensely, within a few hours, or slowly, over days or months. Effective protection of the data in the DICT database against read attacks requires joint action between the Central Bank of Brazil, as the maintainer of the database, and the participants, with direct and indirect access, as requesters of consultations and responsible for their internal databases. This section addresses the mechanisms adopted by the DICT, as well as the minimum mechanisms that must be adopted by the participants, as provided for in Chapter XIII, Section V, of the Pix Regulation.
13.1 Mechanisms adopted by the DICT
The DICT has key Pix consultation limits based on two indicators, applicable to participants providing transactional accounts:
a. consultations without payment order: the number of consultations that did not result in a payment order; and b. invalid consultations: the number of consultations performed for keys not registered in the DICT. For the calculation of these indicators, the participant must always inform, in the PI-PayerId header, the identifier of the paying user originating the consultation, which must be the same used in the payment order 11. All consultations from a final user from a given participant must have the same identifier. Thus, the DICT will control consultations for both the final user and the participant. The limitation mechanism uses the Token Bucket algorithm 12 (bucket of tokens or symbols), with the following definitions, applicable to the getEntry operation:
11 The PayerId field must be filled with the CPF or CNPJ of the user originating the consultation and who will be responsible for paying the Pix transaction, using the numeric format, without dots, dashes, or slashes, with 11 digits for CPF and 14 digits for CNPJ. 12 Tanenbaum, Andrew S. COMPUTER NETWORKS. Rio de Janeiro: Elsevier Editora, 2003, p.428.
77 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Final User legal person
Maximum bucket size for mobile phone or email consultations: 100 tokens Maximum bucket size for CPF, CNPJ, or random key consultations: 100 tokens Decrease: 1 token per valid consultation of any key and 20 tokens per invalid consultation of any key, per bucket Increase: 1 token per consultation of any key after receiving the payment order from the SPI, per bucket Time increment: 2 tokens per minute in each bucket Final User legal entity Maximum bucket size for mobile phone or email consultations: 1,000 tokens Maximum bucket size for CPF, CNPJ, or random key consultations: 1,000 tokens Decrease: 1 token per valid consultation of any key and 20 tokens per invalid consultation of any key, per bucket Increase: 2 tokens per consultation of any key after receiving the payment order from the SPI, per bucket Time increment: 20 tokens per minute in each bucket Note: Exceptionally, at the discretion of the Central Bank of Brazil, a user's parameters may be altered. Participant Maximum bucket size and time increment: according to the category in which the participant falls, according to the table below 13:
Category Size Increment / min
A 50,000 25,000
B 40,000 20,000
C 30,000 15,000
D 16,000 8,000
E 5,000 2,500
F 500 250
G 250 25
H 50 2
Decrease: 1 token per valid consultation of any key and 3 tokens per invalid consultation of any key Increase: 1 token per consultation of any key after receiving the payment order from the SPI
13 The Central Bank of Brazil will classify each participant into one of the categories. The participant may request, duly justified by historical data (and not projections), with the approval of the participant's cybersecurity director (as referred to in Section III of Chapter VII of the Pix Regulation), if applicable, to change to a higher category. In cases of suspected read attack or operational problem, the participant's category may be changed by the Central Bank of Brazil, which will communicate the change to the PSP.
78 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
When sending a consultation request to the DICT, when the bucket is already empty, the user or participant will receive a RATE LIMITING error response (HTTP 429 code), being unable to perform new consultations until tokens are replenished. For example, if a legal person user, whose bucket has only 5 tokens, after making a consultation request, receives a response of key not registered in the DICT (NOT FOUND – HTTP 404 code), which has a penalty of 20 tokens, their bucket will have a debt balance of 15 tokens. Therefore, it will only be possible for this user to successfully make new consultations after 8 minutes have elapsed (time replenishment of 2 tokens/minute). In transactions initiated through the payment initiation service, the token credit will be made in the bucket of the participant providing the initiation service and in the bucket of the paying participant (holder of the transactional account), if the latter made a key consultation using the same EndToEndID generated by the initiator. The limitation mechanism for the getEntryStatistics operation has the same maximum bucket size and time increment parameters applied to the getEntry operation for participants, which vary according to the category in which the participant is classified.
13.2 Mechanisms that must be adopted by Pix participants
Participants play a fundamental role in protecting DICT data against read attacks and must act preventively, collaboratively, and complementarily with respect to the mechanisms adopted by the Central Bank of Brazil, mentioned in subsection 13.1. To achieve this objective and complement the protection carried out by the Central Bank of Brazil, participants, with direct or indirect access to the DICT, must maintain at least the protection mechanisms listed in this subsection in their systems.
13.2.1 Verification of authenticity of the user requesting the consultation
Participants must adopt effective mechanisms for validating their clients capable of sending request orders to the DICT, so as not to allow the sending of consultations and the receipt of information from the database by unauthorized persons. Participants must ensure that the users originating the consultation, identified by their CPF or CNPJ in the PI-PayerId header, are, in fact, clients using the consultation service to send a Pix. For this, participants must implement robust practices for validating their clients and their devices (for example, client registration validation at the time of account creation, device validation, token embedding in the device, facial or biometric recognition, MFA in transaction execution, etc.). The participant may, at their discretion, implement the practices given as examples or any other controls that make the validation of user authenticity more robust. Consultations to Pix keys must be restricted to a logged-in environment, whose access must be done by authentication, at least by login and password, in addition to the environment being duly authorized to provide such action.
13.2.2 Establishment of internal query limitation policy
Each Pix participant must establish its own internal query limitation policy equal to or more restrictive than that applied by the DICT's Token Bucket mechanism, so as to provide a prior layer of protection, which must limit the excessive sending of requests and avoid the overflow of the buckets of its users and the participant itself, with consequent return of RATE LIMITING error (HTTP 429 code). The participant must implement request control at the application and/or infrastructure level to not forward DICT key consultations when the number of requests from the user's or participant's bucket is reached, thus preventing the return of the RATE LIMITING error. For example, if a user's consultation limit is 20, the participant should not send the twenty-first consultation to the DICT. If this limitation is more restrictive than that of the DICT, the participant must monitor these consultations to ensure that requests that may exceed internal limits are not sent to the DICT.
13.2.3 Qualitative and permanent monitoring of consultations
Participants must implement and maintain mechanisms for monitoring requests made to the DICT at the request of their users/clients. The monitoring must consider short periods (hours) and long periods (days/months), and its objective is the identification and blocking of suspicious cases of read attacks on DICT data, using as main criteria excessive consultations that do not result in payment orders and excessive consultations of keys not registered in the DICT (NOT FOUND error – HTTP 404 code). Participants must monitor the relationship between the volume of consultations to the DICT (VCD) and the sending of orders to the SPI (EOS) on a scale of minutes or, at most, a few hours, as well as in longer periods of days or months. Given that some factors naturally affect the non-sending of orders after a consultation, it is expected that the participant's VDC/EOS ratio be slightly greater than 1. However, values much higher may indicate read attack behaviors 14. It is up to participants to analyze their user journey and historical data to determine their usual ratio and the values from which an anomalous situation (read attack, unauthorized purpose, or internal system failure) can be characterized. In case of obtaining higher values, the participant must check for possible system failures or, if necessary, adopt more restrictive policies in their request limitation controls. Participants must, additionally, monitor the relationship between consultations of keys not registered in the DICT (NOT FOUND – HTTP 404 code) and found keys (FOUND – HTTP 200 code). In the same way as the VDC/EOS ratio, participants must establish normality parameters for the NOT FOUND/(NOT FOUND+FOUND) 15 ratio, both for the PSP as a whole and for each of its users. If these values are exceeded, the participant must verify if the abnormal behavior is justified. If there is a well-founded suspicion and strong evidence of misuse of the DICT, the participant must immediately block the user(s) in question. In case it is necessary for certain user(s) to make large-volume or batch payments, it is suggested to the participant to use the DICT's checkKeys functionality (for PSP use only, cannot be made available, even indirectly, to its users) to confirm the existence of keys, prior to the actual sending of requests, so as to avoid high quantities of invalid consultations (NOT FOUND – HTTP 404 code). This practice aims to avoid situations that may indicate suspicions of read attacks, as well as prevent the emptying of the user's and participant's buckets. The participant may define, at their discretion, the time interval in which they will execute the monitoring of the two indicators and the parameters that will be used to trigger the control actions for the possible attack. In addition to the controls regarding the VDC/EOS and NOT FOUND/(NOT FOUND+FOUND) ratios, mentioned in the previous paragraphs, participants must create all additional controls deemed necessary to ensure security,
considering the specific aspects of their business domain, technological architecture, and target audience behavior.
13.2.4 Action plan for handling suspicious cases
Participants must adopt an action plan for handling cases identified as suspicious of read attacks. The measures provided for in the action plan must aim at the immediate cessation of the anomalous behavior, the preservation of personal data linked to Pix keys, and the implementation of actions to prevent recurrence. In case of confirmation of a read attack, the participant must immediately inform the Central Bank of Brazil about the case, through the email address pix-operacional@bcb.gov.br, describing the emergency measures adopted to contain the problem and prevent recurrence. The incident report to the Central Bank of Brazil does not exempt the participant from taking other actions provided for by law, especially those related to the General Law on Personal Data Protection (LGPD).
13.2.5 Restriction of key data displayed to the user making the consultation
As described in section 8.1 of this Manual, only some information can be returned to the user making the consultation (whether through the application, internet banking, internal systems, or the PSP's API): the full name or business name of the user who registered the consulted key; the establishment title (trade name) of the user who registered the consulted key, if linked to a legal entity user; masked CPF (example: *.777.888-) or CNPJ of the user who registered the consulted key; the consulted key and the name of the receiving PSP (optional). The availability of this information must be based on the security requirements described in section 6 of the Pix Security Manual 16. The other information returned by the DICT must be for the exclusive use of the paying PSP and may not, under any circumstances, be displayed to the user making the consultation.
16 The Pix Security Manual is available at https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Manual_de_Seguranca_PIX.pdf
81 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
14 Limitation of requests to the DICT API
Each API operation is associated with a limitation policy, according to the table below 17. In the table, the bucket means the margin each participant has to eventually, during a short period of time, exceed the established limit.
Rate Limit Policy API Operations Bucket Increment Maximum Bucket Size entries.read getEntry See section 13.1 See section 13.1 entries.write createEntry, deleteEntry 800 requests/min 1,200 requests entries.update updateEntry 600 requests/min 600 requests claims.read getClaim 600 requests/min 18,000 requests claims.write createClaim, acknowledgeClaim, cancelClaim, confirmClaim, completeClaim 1,200 requests/min 36,000 requests claims.list-with-rolefilter listClaims 40 requests/min 200 requests claims.list-withoutrole-filter listClaims 10 requests/min 50 requests syncverifications.write createSyncVerification 10 requests/min 50 requests cids-files.write createCidSetFile 40 requests/day 200 requests cids-files.read getCidSetFile 10 requests/min 50 requests cids-events.list listCidSetEvents 40 requests/min 200 requests cids-entries.read getEntryByCid 1,200 requests/min 36,000 requests infractionreports.read getInfractionReport 600 requests/min 18,000 requests infractionreports.write createInfractionReport, acknowledgeInfractionReport, cancelInfractionReport, closeInfractionReport 1,200 requests/min 36,000 requests infraction-reports.listwith-role-filter listInfractionReports 40 requests/min 200 requests infraction-reports.listwithout-role-filter listInfractionReports 10 requests/min 50 requests fraud-markers.write createFraudMarker 1,200 requests/min 36,000 requests
17 The limitation policy for key consultation (entries.read), whose API operation is getEntry, is detailed in section 13.
82 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
keys.check 18 checkKeys 70 requests/min 70 requests 19 keys.check for final users 20 - 300 keys/day (or more restrictive, at the PSP's discretion) 1,000 keys (or more restrictive, at the PSP's discretion) refunds.read getRefund 1,200 requests/min 36,000 requests refunds.write createRefund, cancelRefund, closeRefund 2,400 requests/min 72,000 requests refund_list_with_role listRefunds 40 requests/min 200 requests refund_list_without role listRefunds 10 requests/min 50 requests statistics_person_read getPersonStatistics 12,000 requests/min 36,000 requests statistics_entry_read getEntryStatistics Same increment as getEntry, by participant category (see section 13.1) Same size as getEntry, by participant category (see section 13.1) policies_read getBucketState 60 requests/min 200 requests policies_list listBucketStates 6 requests/min 20 requests
15 Registered Pix Key Verification Flow
15.1 Registered Pix Key Verification Flow for Pix participant with direct access to the DICT
18 The same limits apply to the initiating participant. For the verification of registered Pix keys, the initiating participant consults the same endpoint as the transactional account provider participant. 19 A maximum of 200 keys can be consulted in each request. 20 The DICT does not control the verification of registered Pix keys by final user. The table values are recommendations for each participant to apply internally regarding its users.
83 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Layer Type Description
1 PSP Message PSP sends list of Pix keys to DICT.
2 DICT Message DICT receives list from PSP.
3 DICT Action DICT verifies if keys are registered.
4 DICT Message DICT sends message, identifying if each of the keys in the list is registered or not.
5 PSP Message PSP receives message.
6 PSP Action PSP updates Pix key existence cache, based on the list sent by DICT.
15.2 Registered Pix Key Verification Flow for Pix participant with indirect access to the DICT
84 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
Layer Type Description
PSP with indirect access Communication PSP sends list of Pix keys to PSP with direct access.
PSP with direct access Communication PSP with direct access receives list.
PSP with direct access Message PSP with direct access sends list of Pix keys to DICT.
4 DICT Message DICT receives list from PSP.
5 DICT Action DICT verifies if keys are registered.
6 DICT Message DICT sends message, identifying if each of the keys in the list is registered or not.
PSP with direct access Message PSP with direct access receives message.
PSP with direct access Communication PSP with direct access sends list to PSP with indirect access.
85 • Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT) – Versão 8.5
PSP with indirect access Communication PSP with indirect access receives list.
10 PSP with indirect access Action PSP with indirect access updates Pix key existence cache, based on the list sent by DICT.
16 Pix Key Existence Cache
To allow filtering, in a set of elements that may be Pix keys, which are registered in the DICT, the PSP can build a Pix key existence cache. In this cache, the PSP can record the status of the key (existing or non-existing), including the status of keys registered by other PSPs. All types of keys can be consulted. The cache must not serve as the basis for a service made available to users; it must be consumed only by the participant, to assist them, for example, in query bucket control or to make large-volume or batch payments. The Pix key existence cache can be populated from the following sources:
a. key consultations performed for the purpose of initiating a Pix, in cases where the PSP is the requesting participant itself or in cases where it is acting as the liquidator of another participant; b. portability and possession claim processes, in cases where the PSP is one of the parties to the process or in cases where it is acting as the liquidator of another participant in one of the parties to the process;
c. the PSP's own internal database; and
d. verification of keys registered in the DICT (checkKeys - for PSP use only).
Records in the cache made through sources “a” and “b” can be kept in the cache for up to thirty days. If the record in the cache is made through source “d”, the record must follow the directives contained in the Cache-Control header, so that it is valid. The cache can store only the following information:
- the hash of the key (SHA-256, or more robust algorithm);
- the date of update of the key in the cache; and
- the date of update of the key in the DICT.
Therefore, it is not permitted for the cache to store the key itself in clear text, the data of the key holder, and the data of the account linked to the key.
17 Refund Request Flow
A refund request can have the following states in the DICT:
- open: the refund was requested by the paying user's PSP;
- closed: the refund request was analyzed by the receiving user's PSP and the result of this analysis is available; or
- cancelled: while the request is not in the “analyzed” state, the paying user's PSP can cancel the request.
86 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Note that, unlike portability flows, ownership claim flows, and infringement notification flows, it is not necessary to receive a return request.
The return request applies to cases of:
- operational failure of the payer's PSP 21;
- well-founded suspicion of fraud; or
- error by the payer's PSP in sending a payment order regarding Pix Automatic 22;
The return request may occur at the initiative of the payer user or at the initiative of the payer's PSP itself. In the context of Value Recovery, which includes all cases of transaction dispute due to fraud (including the dispute of a return transaction), the return request flow due to well-founded suspicion of fraud is part of the macro-process described in section 20 "Value Recovery Flow". In this case, the return request will be generated by the DICT, upon request of the PSP that opened the Value Recovery, called the recovering PSP.
When opening a return request in the DICT, the payer's PSP (or the PSP with direct access to the DICT, as applicable) must inform the fields below. For the reason well-founded suspicion of fraud, the DICT itself performs the filling of the fields.
| Field | Mandatory or Optional | Description |
|---|---|---|
| Identifier of the contested transaction (TransactionId) | Mandatory | Identifier of the payment transaction (EndToEndId) or of the return transaction (RtrId) |
| Reason (RefundReason) | Mandatory | Reason why the transaction must be returned: <br> - operational failure of the payer's PSP (operational_flaw) <br> - well-founded suspicion of fraud (fraud) <br> - error by the payer's PSP in sending a payment order regarding Pix Automatic (pix_automatico) |
| Amount to be returned (RefundAmount) | Mandatory | Amount to be returned |
| Comments (RefundDetails) | Optional / Mandatory | Free text field, with information that may assist the receiver's PSP in analyzing the request, including, eventually, communication channels between the parties and ways to access additional documents. |
21 Does not include operational error in a Pix Automatic transaction.
22 Possible errors are: absence of valid authorization, inconsistency between the payment instruction and the authorization, or operational error by the payer's PSP (for example, sending a payment order after the scheduling has been canceled).
87 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Mandatory when RefundReason=operational_flaw.
When sending a message to the DICT to close a return request, the receiver's PSP (or the PSP with direct access to the DICT, as applicable) must inform the following fields:
| Field | Mandatory or Optional | Description |
|---|---|---|
| Analysis Result (RefundAnalysisResult) | Mandatory | Possible results: <br> - totally accepted (totally_accepted) <br> - partially accepted (partially_accepted) <br> - rejected (rejected) |
| Reason for rejection (RefundRejectionReason) | Mandatory, if analysis result is equal to "rejected" | Domains: <br> - lack of balance in the client's account (no_balance) <br> - client relationship closed (account_closure) <br> - invalid request (invalid_request) (only when RefundReason=operational_flaw) <br> - generic reason, which does not fit into the description of the other two domains (other) |
| Identifier of the return transaction (RefundTransactionId) | Mandatory, if analysis result is equal to "totally accepted" or "partially accepted" | Identifier of the return transaction. If the original transaction is PACS.008, the return must be PACS.004, and vice versa. |
| Comments (RefundAnalysisDetails) | Optional / Mandatory | Free text field, with information about the analysis of the return request. Mandatory when RefundAnalysisResult=reject, RefundRejectionReason=invalid_request and RefundReason=operational_flaw. |
| Effectively refunded amount (EffectiveRefundedAmount) | Optional / Mandatory | Effectively refunded amount. Mandatory when the return request was generated in the context of a Value Recovery. |
The analysis result must be identified as "totally accepted" in cases where the return of funds corresponds exactly to the amount requested in the return. If the return of funds is in an amount lower than the requested amount, the analysis result must be identified as "partially accepted". This case may occur if there are insufficient funds in the receiver user's account at the time of executing the return.
Participants who have a value limit for carrying out transactions and who need to carry out multiple transactions to make the return due to this limit must inform the total effectively refunded amount in the EffectiveRefundedAmount field, so that the return stage of value recovery proceeds adequately. In this case, one of the effective transactions can be informed in the RefundTransactionId field.
In return requests with RefundReason = FRAUD, there is no longer a need for the receiver's PSP to monitor the account after the completion of the return request, in case of partial return or rejection of the request due to lack of balance. Until the MonitorAccount attribute is definitively excluded from the API, the DICT will always send the value "false" in this field. In cases of operational failure or of Pix Automatic with error by the payer's PSP, there is no longer a need for account monitoring by the receiver's PSP, even if there is a partial return or rejection of the request.
The analysis result must be identified as "rejected" in cases where there is no return of financial resources or when the return request was opened improperly. The PSP may reject a return request, even after having accepted the infringement notification that precedes it 23, if (i) there are no funds in the client's account, (ii) the client relationship has been closed, or (iii) generic reason (which does not fit into the description of the other two domains). In cases of rejection of the request, despite there being no return of financial resources, the key and the user remain marked with fraud, since the infringement notification was accepted.
In the case of a return request opened for a subsequent transaction in the context of a Value Recovery, the RefundAccount field will contain the data of the account to which the resources must be returned. The RefundAccount field will come empty in the case of requests opened on the root transaction of a Value Recovery.
17.1 Return request due to operational failure
In the specific case of return request due to operational failure, the receiver's PSP must analyze the return request and must reject it using the rejection reason "invalid_request" if it is not an operational failure.
As provided in the Pix Regulation, cases where the Pix transaction was duly initiated by the payer user and the amount indicated in the initiation of the transaction was correctly credited in the transactional account of the receiver user are not considered as operational failure, for return purposes. In general, operational failure by the payer's PSP is considered to be errors that cause financial damage to the payer user, such as: duplication of the transaction, transaction carried out in an amount different from that instructed by the user, or sending of resources without the transaction being confirmed by the payer.
Some examples of situations in which the return request due to operational failure is not applicable:
- PSP did not debit the payer user's account to execute the Pix;
- PSP debited the payer user's account and did not perform the accounting adjustment;
- PSP did not display the debit made in the payer user's statement;
- The payer user indicated an incorrect destination account/Pix key;
23 Return requests related to cases of operational failure by the payer's PSP and error by the payer's PSP involving Pix Automatic transactions do not require the prior creation of infringement notifications.
88 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
- The payer user placed two orders, when he would like to have executed only one;
- Any case of fraud or scam (these cases must follow the complete MED flow, with the opening of the Value Recovery).
For the receiver's PSP to be able to analyze the case correctly, it is recommended that the payer's PSP provides all possible information when opening the request. Thus, it is suggested to include the following information in the Comments field (details):
- Contact phone number of the responsible area;
- Contact email of the responsible area;
- Failure occurred:
o Duplication o Amount disagreement o Transaction not initiated o Others - Brief report of what happened.
Similarly, in case of rejection of the return request with the reason "invalid_request", the Receiver PSP must include in the "Comments" field (RefundAnalysisDetails) the hypotheses of non-applicability of the request, as exemplified above. If the payer's PSP has not sent sufficient information for the verification of the failure, the receiver's PSP must indicate this in the "Comments" field.
17.1.1 Return request flow due to "operational failure of the payer's PSP" (Pix participants with direct access to the DICT)
89 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | Payer's PSP | Action | Payer's PSP identifies problem and recovers data of the original transaction. |
| 2 | Payer's PSP | Message | If the transaction was carried out in the last ninety days, Payer's PSP sends return request to the DICT through the message "Return / Create a return request", with the amount to be returned, the reason for the request ("operational failure") and the complementary information (in the "Comments" field) to allow the confirmation of the operational failure by the receiver's PSP. The amount requested for return can be equal or lower than the amount of the original transaction. |
| 3 | DICT | Message | DICT receives message with return request. |
| 4 | DICT | Action | DICT makes request available, with status "Open". |
| 5 | Receiver's PSP | Action | Receiver's PSP periodically consults in the DICT the list of return requests with state "Open" that refer to transactions received by its clients. As soon as it identifies a return request with state "Open", the Receiver's PSP evaluates if it is a situation of operational failure. If yes, it checks if there are available resources in the receiver user's account. If there are resources, Receiver's PSP proceeds to step 6. If it is not an operational failure or there are no resources, the flow proceeds directly to step 9. |
| 6 | Receiver's PSP | Action | Receiver's PSP immediately initiates return order (sending of pacs.004). After this action, the flow proceeds concomitantly to steps 7 and 9. |
| 7 | Receiver's PSP | Communication | Receiver's PSP sends communication to its user, informing about the return. |
| 8 | Receiver User | Communication | Receiver user receives communication from its PSP. |
| 9 | Receiver's PSP | Message | Receiver's PSP sends message to the DICT, changing the state of the request to "Completed", with result "Totally Accepted", "Partially Accepted" or "Rejected", as applicable. If the result is "Rejected", the reason for rejection must be identified. |
| 10 | DICT | Message | DICT receives message. |
| 11 | DICT | Action | DICT makes request available, with status "Completed". |
| 12 | Payer's PSP | Action | Payer's PSP periodically consults in the DICT the list of return requests with state "Completed" that refer to transactions initiated by its clients. |
17.1.2 Return request flow due to "operational failure of the payer's PSP" (Pix participants with indirect access to the DICT)
90 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | Payer's PSP | Action | Payer's PSP identifies problem and recovers data of the original transaction. |
| 2 | Payer's PSP | Communication | If the transaction was carried out in the last ninety days, Payer's PSP sends return request to PSP with direct access (responsible or clearing house of the Payer's PSP), with the amount to be returned, the reason for the request ("operational failure") and the complementary information (in the "Comments" field) to allow the confirmation of the operational failure by the receiver's PSP. The amount requested for return can be equal or lower than the amount of the original transaction. |
| PSP with direct access to DICT (responsible or clearing house of the Payer's PSP) | Communication | PSP with direct access receives communication with return request. | |
| PSP with direct access to DICT (responsible or clearing house of the Payer's PSP) | Message | PSP with direct access sends return request to the DICT through the message "Return / Create a return request", with the amount to be returned and the reason for the request ("operational failure"). | |
| 5 | DICT | Message | DICT receives message with return request. |
| 6 | DICT | Action | DICT makes request available, with status "Open". |
| PSP with direct access to DICT (responsible or clearing house of the Receiver's PSP) | Action | PSP with direct access (responsible or clearing house of the Receiver's PSP) periodically consults in the DICT the list of return requests with state "Open" that refer to transactions received by the clients of the Receiver's PSP. | |
| PSP with direct access to DICT (responsible or clearing house of the Receiver's PSP) | Communication | As soon as it identifies a return request with state "Open", the PSP with direct access communicates the Receiver's PSP about the request. | |
| 9 | Receiver's PSP | Communication | Receiver's PSP receives the return request. |
| 10 | Receiver's PSP | Action | Receiver's PSP evaluates if it is a situation of operational failure. If yes, it checks the available balance. If there are funds in its client's account, Receiver's PSP accepts the request and proceeds to step 11. If it is not an operational failure or there are no funds in its client's account, Receiver's PSP rejects the request and proceeds directly to step 13. |
| 11 | Receiver's PSP | Communication | Receiver's PSP sends communication to its user, informing about the return. |
| 12 | Receiver User | Communication | Receiver user receives communication from its PSP. |
91 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 13 | Receiver's PSP | Communication | Receiver's PSP sends communication to the PSP with direct access to the DICT. |
| PSP with direct access to DICT (responsible or clearing house of the Receiver's PSP) | Communication | PSP with direct access receives communication about the return and checks if the return was accepted. | |
| PSP with direct access to DICT (responsible or clearing house of the Receiver's PSP) | Message | If the request is accepted, it initiates the return order (sending of pacs.004) and sends message to the DICT, changing the state of the request to "Completed", with result "Totally Accepted" or "Partially Accepted", depending on the case, after the processing of the pacs.004 is finalized with success. If the request is rejected, it sends message to the DICT, changing the state of the request to "Completed", with result "Rejected" and identifying the reason for rejection. | |
| 16 | DICT | Message | DICT receives message. |
| 17 | DICT | Action | DICT makes request available, with status "Completed". |
| PSP with direct access to DICT (responsible or clearing house of the Payer's PSP) | Action | PSP with direct access periodically consults in the DICT the list of return requests with state "Completed" that refer to transactions initiated by the Payer's PSP. | |
| PSP with direct access to DICT (responsible or clearing house of the Payer's PSP) | Communication | PSP with direct access sends communication with the result of the return request. | |
| 20 | Payer's PSP | Communication | Payer's PSP receives communication with the result of the return request. |
17.2 Return request flow due to "well-founded suspicion of fraud"
The return request flow due to well-founded suspicion of fraud is inserted in the return stage of Value Recovery. Thus, participants must observe the provisions in the "Return Flow" section, of chapter 20.
This flow also includes cases of dispute of a return transaction (pacs.004) when the suspicion of fraud falls on the payer user of the original transaction.
17.3 Return request flow due to error by the payer's PSP in sending payment order regarding Pix Automatic
In case of error by the payer's PSP in sending payment order regarding Pix Automatic, the payer's PSP must, initially, return to its client the amount of the transaction that has not yet been recovered, using its own resources. If part of the amount has already been returned spontaneously by the receiver user, the payer's PSP must deduct this amount from the return to the client.
Subsequently, the payer's PSP initiates the return request flow in the DICT with the reason "pix_automatico" to try to be reimbursed by the receiver's PSP.
Since the payer user has already received the funds in their account, the return by the receiver's PSP, in case of available balance in the receiver user's account, must be carried out through a PACS.008, with the field "finalidadeDaTransacao" filled with "REFU", and identifying as the receiver user of this transaction the payer's PSP of the original transaction. For this, the receiver's PSP must fill in the PACS.008 the CNPJ number of the payer's PSP in the field identifying the receiver user. The receiver's PSP can obtain the CNPJ of each Pix participant in the list of Pix participants published on the BC website 24.
17.3.1 Return request flow due to error by the payer's PSP in sending payment order regarding Pix Automatic (Pix participants with direct access to the DICT)
24 Available at https://www.bcb.gov.br/estabilidadefinanceira/participantespix
92 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | Payer's PSP | Action | Flow starts after complaint by the payer user or identification by the payer's PSP itself of the improper sending of a Pix Automatic transaction. |
| 2 | Payer's PSP | Action | Payer's PSP checks if there was an error by itself in sending the payment order, whether due to inconsistency between the payment instruction sent by the receiver's PSP and the parameters of the authorization granted by the payer user, due to the absence of a valid authorization granted by the payer user, or due to an operational error. If there was an error, the flow proceeds concomitantly to steps 3 and 6. |
| 3 | Payer's PSP | Action | Payer's PSP returns the total resources to its client, using its own resources. |
| 4 | Payer's PSP | Communication | Payer's PSP sends communication to its user, informing about the return. |
| 5 | Payer User | Communication | Payer user receives communication from its PSP. |
| 6 | Payer's PSP | Message | Payer's PSP sends return request to the DICT through the message "Return / Create a return request", with the amount to be returned and the reason "pix_automatico". |
| 7 | DICT | Message | DICT receives message with return request. |
| 8 | DICT | Action | DICT makes request available, with status "Open". |
| 9 | Receiver's PSP | Action | Receiver's PSP periodically consults in the DICT the list of return requests with state "Open" that refer to transactions received by its clients. As soon as it identifies a return request with state "Open", the Receiver's PSP checks if there are available resources in the receiver user's account. If there are resources, Receiver's PSP proceeds to step 10. If there are no resources, the flow proceeds directly to step 13. |
| 10 | Receiver's PSP | Message | Receiver's PSP initiates the return through a pacs.008. After this action, the flow proceeds concomitantly to steps 11 and 13. |
| 11 | Receiver's PSP | Communication | Receiver's PSP sends communication to its user, informing about the return. |
| 12 | Receiver User | Communication | Receiver user receives communication from its PSP. |
| 13 | Receiver's PSP | Message | Receiver's PSP sends message to the DICT, changing the state of the request to "Completed", with result "Totally Accepted", "Partially Accepted" or "Rejected", as applicable. If the result is "Rejected", the reason for rejection must be identified. |
| 14 | DICT | Message | DICT receives message. |
93 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 15 | DICT | Action | DICT makes request available, with status "Completed". |
| 16 | Payer's PSP | Action | Payer's PSP periodically consults in the DICT the list of return requests with state "Completed" that refer to transactions initiated by its clients. |
17.3.2 Return request flow due to error by the payer's PSP in sending payment order regarding Pix Automatic (Pix participants with indirect access to the DICT)
94 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
| # | Layer | Type | Description |
|---|---|---|---|
| 1 | Payer's PSP | Action | Flow starts after complaint by the payer user or identification by the payer's PSP itself of the improper sending of a Pix Automatic transaction. |
95 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
100 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
2 PSP of the payer Action
PSP of the payer verifies if there was an error on its part in sending the payment order, whether due to inconsistency between the payment instruction sent by the PSP of the payee and the parameters of the authorization granted by the payer user, due to the lack of a valid authorization granted by the payer user, or due to an operational error. If an error occurred, the flow proceeds concurrently to steps 3 and 6.
3 PSP of the payer Action PSP of the payer returns the total resources to its client, using its own resources.
4 PSP of the payer Communication PSP of the payer sends communication to its user, informing about the return.
5 Payer user Communication Payer user receives communication from its PSP.
6 PSP of the payer Communication PSP of the payer sends a return request to the PSP with direct access
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payer) Communication PSP with direct access receives communication.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payer) Message PSP with direct access sends a return request to the DICT through the message “Return / Create a return request”, with the amount to be returned and the reason “pix_automatico”.
9 DICT Message DICT receives message with return request.
10 DICT Action DICT makes the request available, with status “Open”.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payee) Action PSP with direct access periodically consults the DICT for the list of return requests with status “Open” that refer to transactions received by clients of the PSP of the payee.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payee) Communication As soon as it identifies a return request with status “Open”, the PSP with direct access communicates the PSP of the payee about the request.
13 PSP of the payee Communication PSP of the payee receives the return request.
14 PSP of the payee Action PSP of the payee verifies if there are available resources in the payee user's account.
15 PSP of the payee Communication PSP of the payee communicates the PSP with direct access about the result of the return request.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payee) Communication PSP with direct access receives communication.
101 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payee) Action PSP with direct access verifies the result of the return request reported by the PSP of the payee.
If the request was accepted, it proceeds to step 18.
If the request was rejected, it proceeds directly to step 23.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payee) Message PSP with direct access initiates the return through a pacs.008. After this action, the flow proceeds concurrently to steps 19 and 23.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payee) Communication PSP with direct access communicates the PSP of the payee about the completion of the return.
20 PSP of the payee Communication PSP of the payee receives communication.
21 PSP of the payee Communication PSP of the payee sends communication to its user, informing about the return.
22 Payee user Communication Payee user receives communication from its PSP.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payee) Message PSP of the payee sends a message to the DICT, changing the status of the request to “Completed”, with result “Accepted total”, “Accepted partial” or “Rejected”, as the case may be. If the result is “Rejected”, the reason for rejection must be identified.
24 DICT Message DICT receives message.
25 DICT Action DICT makes the request available, with status “Completed”.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payer) Action PSP with direct access periodically consults the DICT for the list of return requests with status “Completed” that refer to transactions initiated by clients of the PSP of the payer.
PSP with direct access to DICT
(responsible or liquidator of the PSP of the payer) Communication PSP with direct access sends communication with the result of the return request.
28 PSP of the payer Communication PSP of the payer receives communication with the result of the return request.
102 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
18 Security information query flow
The query for security information must be made for the purpose of feeding the fraud analysis mechanisms of participants. It can be used even in processes that are not directly related to Pix. Access to the endpoint must be made exclusively by the participant itself, and it is prohibited to make the functionality available to end users. In the DICT API, the endpoint is called “Statistics” (statistics). The statistics query can be linked to a Pix key (getEntryStatistics) or to a user (getPersonStatistics). Security information is updated with a maximum delay of 12 hours, counted from the occurrence of the last event, whose date is indicated by the watermark field. The query for security information linked to CPF or CNPJ (getPersonStatistics) can be carried out at the discretion of each participant. The DICT response will contain the following information:
a. number of settlements as payee in SPI (Settlements); b. confirmed infringement notifications and created transactional fraud flags, with fraud of the type “ideological falsity” (ApplicationFrauds);
c. confirmed infringement notifications and created transactional fraud flags, with fraud of the type “mule account” (MuleAccounts);
d. confirmed infringement notifications and created transactional fraud flags, with fraud of the type “scammer account” (ScammerAccounts); e. confirmed infringement notifications and created transactional fraud flags, with fraud of the type “others” (OtherFrauds); f. confirmed infringement notifications without identification of fraud type (UnknownFrauds) 25; g. total value of confirmed notifications (TotalFraudTransactionAmount) 26; h. number of distinct participants that confirmed at least one notification against the key or the CPF/CNPJ queried (DistinctFraudReporters);
i. number of notifications still open at the time of the query (OpenReports);
j. number of distinct participants that have notifications still open at the time of the query (OpenReportsDistinctReporters); k. total rejected infringement notifications, including notifications without identification of the fraud type (RejectedReports); and
l. number of CPF or CNPJ accounts linked to Pix keys (when a user is queried); or number of distinct accounts to which the key was associated (when a key is queried) (RegisteredAccounts).
The information set forth in letters “a” to “h” and “k” will be returned for the following periods:
a. last 90 days;
25 Open notifications in versions prior to version 2.0 of the DICT API.
26 Infringement notifications with fraud of the type “ideological falsity” do not enter the calculation, at the user level.
103 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
b. last 12 months (excluding the month in which the query is carried out); and
c. last 60 months (excluding the month in which the query is carried out).
When a key is queried (getEntryStatistics), the information set forth in letters “a” to “l” will be returned both for the queried key and for the CPF/CNPJ linked to the queried key. When a CPF or CNPJ is queried (getPersonStatistics), the information set forth in letters “a” to “l” will be returned only for the queried CPF/CNPJ. For the purpose of counting the periods of confirmed notifications, the initial date is considered the date on which the notification was accepted. Any action that may result in modifications to the keys (deletion, alteration, portability, or claim of ownership) does not remove or invalidate the infringement notification information. The infringement notification information by key and by user are independent of each other. Thus, if a key is deleted and subsequently registered, the infringement notification information will be inherited by the new registration, provided that the set of information related to the key and the user are exactly equal to the set of information linked to the deleted key. The security information made available by the DICT must be used by each Pix participant, at its discretion, in its internal risk management processes.
18.1 Security information query flow for the Pix participant with direct access to DICT
Layer Type Description
104 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
1 PSP Action PSP identifies the need to query security information 2 PSP Message PSP sends a query message for security information to the DICT, identifying the Pix key or the CPF/CNPJ to be queried. 3 DICT Message DICT receives message with query request. 4 DICT Action DICT verifies if the institution is authorized to perform queries. 5 DICT Action DICT verifies if there is information for the Pix key or for the queried CPF/CNPJ. 6 DICT Action If information exists, DICT creates a response message, which must contain the security information linked to the Pix key or to the queried CPF/CNPJ. 7 DICT Action If no information exists, DICT creates an error message informing the non-existence of information for the Pix key or for the queried CPF/CNPJ. 8 DICT Message DICT sends response message to the query. 9 PSP Message PSP receives message with the response to the query. End of process.
18.2 Security information query flow for the Pix participant with indirect access to DICT
105 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
PSP with indirect access Action PSP with indirect access identifies the need to query security information PSP with indirect access Communication PSP with indirect access sends communication to the PSP with direct access requesting a query for security information, identifying the Pix key or the CPF/CNPJ to be queried. PSP with direct access Communication PSP with direct access receives communication. PSP with direct access Message PSP with direct access sends a query message for security information to the DICT, identifying the Pix key or the CPF/CNPJ to be queried. 5 DICT Message DICT receives message with query request. 6 DICT Action DICT verifies if the institution is authorized to perform queries. 7 DICT Action DICT verifies if there is information for the Pix key or for the queried CPF/CNPJ. 8 DICT Action If information exists, DICT creates a response message, which must contain the security information linked to the Pix key or to the queried CPF/CNPJ.
106 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
9 DICT Action
If no information exists, DICT creates an error message informing the non-existence of information for the Pix key or for the queried CPF/CNPJ.
10 DICT Message DICT sends response message to the query.
11 PSP with direct access Message PSP with direct access receives message with the response to the query.
12 PSP with direct access Communication PSP with direct access sends communication to the PSP with indirect access with the response to the query.
13 PSP with indirect access Communication PSP with indirect access receives communication with the response to the query. End of process.
19 Buckets query
The DICT has an endpoint that allows participants to consult their request limits to the DICT API and the size of their buckets at the time of the query. This endpoint aims to allow participants to better manage their buckets, with the intent of avoiding their depletion. Participants can make two types of requests:
a. listing of limitation policies (policies_list): allows obtaining a list containing, for each request policy, the number of tokens available in the bucket at the time of the query, the maximum capacity of the bucket, the amount of periodic token replenishment, the token replenishment period, and the category in which the participant is classified (for the key query bucket); and b. consultation of limitation policy (policies_read): allows the participant to consult, for an individual request policy, the number of tokens available in the bucket at the time of the query, the maximum capacity of the bucket, the amount of periodic token replenishment, the token replenishment period, and the category in which the participant is classified (for the key query bucket). In the consultation of the limitation policy, the participant must inform as input the name of the request policy.
107 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
20 Funds Recovery Flow
Funds Recovery is an enhancement of the Special Return Mechanism for cases related to fraud and scams. This process allows tracking and blocking resources suspected of fraud not only in the destination account of the original transaction performed by the victim, but also in subsequent transactions, increasing the chances of recovery. This is made possible through the blocking of balances in accounts under suspicion, analysis by the involved participants, and subsequent return of the blocked values directly to the victim's account, if it is concluded that the transaction was indeed fraudulent. Funds Recovery can be used to contest a payment transaction (pacs.008) or a return transaction (pacs.004). The initiation of Funds Recovery must be made by the payment service provider of the payer user whenever there is identification of allegedly fraudulent conduct or receipt of a complaint from the client. The participant that initiates the process is called the recovering participant, and the transaction that gives rise to the request is called the root transaction, always having a client of its own as the payer. In the case of contesting a return transaction due to alleged fraud attributed to the payer user of the original transaction, the recovering participant becomes the PSP of the payee user who is requesting Funds Recovery, with the root transaction being the return transaction itself. The opening of Funds Recovery must occur immediately, right after the identification of the fraud suspicion or the receipt of the complaint by the user. The analysis of the merit of the request must be carried out after the initiation of the process, with the aim of accelerating the blocking of resources in accounts under suspicion. In the case of contesting a return transaction, however, the participant may carry out the merit analysis of the user's complaint before opening Funds Recovery. A Funds Recovery can have the following statuses in the DICT:
- Open (CREATED): Funds Recovery was opened by the PSP;
- Tracked (TRACKED): the transaction tracking graph of the Funds Recovery was created;
- Awaiting analysis (AWAITING_ANALYSIS): the generated infringement notifications are being analyzed by the receiving participants;
- Analyzed (ANALYSED): all generated infringement notifications have been closed;
- In refund phase (REFUNDING): refund stage in progress;
- Completed (COMPLETED): funds recovery concluded; or
- Cancelled (CANCELLED): Funds Recovery was cancelled by the PSP that opened it.
The fields of a Funds Recovery are as follows:
Field Mandatory Description
Root Transaction ID
(RootTransactionId)
Mandatory Identifier of the original transaction (EndToEndID) or identifier of the return transaction (RtrId), in case of contesting a return transaction.
Fraud Cause
(SituationType)
Mandatory Domains: - Scam: scam/fraud
- Account_takeover: unauthorized transaction
- Coercion: coercion crime
- Fraudulent_access: fraudulent access and authorization
- Other: others
Contact Information
(ContactInformation)
Mandatory Fields E-mail (Email) and phone (Phone) of the contact area of the participant that opened the Funds Recovery, to obtain clarifications about the case.
Comments (ReportDetails) Mandatory if
SituationType = “OTHER”
Free text field, with information that may assist the analysis of the notification by the other PSP involved in the transaction.
Tracking Graph Parameters
(TrackingGraphParameters)
Optional Subfields: - MinTransactionAmount: Minimum transaction value to be included in the graph.
- MaxTransactions: Maximum number of transactions.
- HopWindow: Maximum time window between transaction entering an account and transaction leaving.
- MaxHops: Maximum depth of the graph.
The “Email” and “Phone” fields (part of ContactInformation) must be filled with valid and updated information. The objective is to facilitate contact between PSPs for exchanging information and clarifications regarding the fraud suspicion in question. The depth of the tracking graph is given by its number of layers. The root transaction is considered the first layer. All transactions performed by the receiver of the root transaction compose the second layer; transactions made by the receivers of the second layer form the third layer, and so on.
20.1 General rules
A Funds Recovery has the following stages:
I - initiation: opening of the Funds Recovery procedure, requested by the recovering participant; II - tracking: selection of an ordered set of transactions from the contested root transaction, called the tracking graph; III - prioritization: selection of an ordered set of transactions from the tracking graph that represent the most likely path of dispersion of resources originating from the fraud or scam;
109 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
IV - blocking: opening of infringement notifications by the DICT and receipt by payment service providers of the transactions selected in the prioritization stage, with immediate blocking of the requested resources; V - analysis: evaluation, by the notified participants, regarding the validity of the fraud suspicion; VI - refund: sending of refund requests to participants that identified accounts of their clients involved in the dispersion of resources, in addition to the actual refund, in case of balance availability. After the initiation of Funds Recovery, the stages of tracking, prioritization, and blocking occur in sequence and without intervention of the recovering participant. The stages of analysis and refund require the interaction of participants with the DICT. The complete process is described in the following sections.
20.1.1 Initiation
The recovering participant initiates the process through the CreateFundsRecovery endpoint, informing the contested transaction and the TrackingGraphParameters parameters. The DICT will use these parameters to build a tracking graph, on which the prioritization of blocking paths will be performed, and to make the infringement notifications available, which will culminate in the analysis stage. When the participant informs, upon opening the Funds Recovery, a transaction of the type pacs.008, the DICT will consider that it is a Funds Recovery for return request, in which the fraud suspicion falls on the payee user. On the other hand, if the participant initiates a Funds Recovery informing a transaction of the type pacs.004, the DICT will assume that it is Funds Recovery for contesting a return transaction, in which the fraud suspicion falls on the payer user of the original transaction. Despite the difference in classification, the Funds Recovery process for both cases is exactly the same. The only restriction for contesting a pacs.004 is that it is not a return resulting from an operational failure. It is emphasized, finally, that it is not possible to open Funds Recovery for a pacs.008 transaction with purpose “IPRT”27 . The DICT will validate if the transaction is within the allowed period for contesting, which is 80 days for both the original transaction (pacs.008) and the return transaction (pacs.004). When the contested transaction is a return, the “SituationType” field of the Funds Recovery must be filled with “other”. Whenever this occurs, the “ReportDetails” field must contain a detailed explanation of the case. It is only possible to open a Funds Recovery per transaction, even in case of cancellation. If a Funds Recovery is cancelled, it is understood that the transaction did not fall within the scope of the MED, making it impossible to open again. Similarly, it is not possible to open a Funds Recovery for a transaction already contested directly through an infringement notification, even if that notification has been cancelled.
20.1.2 Tracking
27 Funds Recovery presupposes that there is suspicion of fraud on the payee user of the contested transaction. As the pacs.008 transaction with IPRT purpose is the return of a transaction identified in the tracking stage, it is not possible to attribute the suspicion of fraud to the payee user of this return, since he did not directly contest the transaction that was the object of the return.
110 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
The Central Bank will establish the minimum criteria for a transaction to be traceable. Participants will be notified of the current criteria and any changes.
Considering the minimum criteria mentioned above, based on the tracking graph parameters (TrackingGraphParameters), the DICT will search for transactions that meet the specified parameters. When a graph meeting the specified parameters is found, the DICT will respond with a tracking graph. Otherwise, the response will be empty. The tracking graph will contain only one transaction if only the root transaction is identified.
20.1.3 Prioritization
Using the response from the tracking stage, the DICT will define a prioritization of blocking paths using its own algorithm, in the prioritization stage.
The prioritization of blocking paths is a list of transactions, which must meet at least the following criteria:
- The root transaction is included;
- All transactions are part of the tracking graph;
- Acyclicity, or non-existence of cycles 28;
- Connectivity: all included transactions originate from accounts that are recipients of at least one included transaction.
20.1.4 Blocking Request
Upon completion of the prioritization stage, the blocking stage proceeds, in which the DICT will make infringement notifications available to the receiving PSPs of the prioritized transactions, referred to in this process as receiving participants. The DICT will simultaneously send the infringement notifications to the receiving participant of the root transaction and to the other receiving participants of the subsequent transactions. Upon receiving the notifications, they must immediately block the resources requested in their users' accounts, up to the limit of the available balance. The value requested for blocking corresponds to the value of the InfractionAmount field in the Infringement Notification, when it is filled in, or to the transaction value, if the InfractionAmount field is empty. Receiving participants must also perform new blocks if new resources enter and the blocked value is still lower than the requested amount.
It is possible that the same transaction is included in the tracking graph of different Funds Recoveries. If this happens, the PSP may receive more than one Infringement Notification for the same transaction. In this case, the total value to be blocked will be the sum of the blocking values requested in the received infringement notifications, limited to the transaction value.
20.1.5 Analysis
During the analysis stage, each receiving participant analyzes the infringement notifications and evaluates whether the suspicion of their client's participation in the dispersion of funds from fraud is confirmed.
28 A graph is acyclic when it has no loops or paths that form a circle. That is, when following the path of the money — from who sent to who received — one never returns to a previous point passing through other intermediaries.
111 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Even if there is no balance in the account, if the receiving participant concludes that the transaction was part of the fraud money dispersion scheme, they must accept the notification to allow subsequent transactions to be subject to the subsequent return stage.
The PSP can identify the layer of the tracking graph corresponding to the transaction under analysis by the TransactionDepth attribute of the Infringement Notification. In the case of the root transaction, the value will be 1. For subsequent transactions, the value will correspond to the level at which the transaction is located in the tracking graph. Infringement notifications not linked to a Funds Recovery (i.e., created in the original version of the MED) will have the attribute TransactionDepth = 1.
It is important to note that the same transaction can be prioritized and included in the tracking graph of several Funds Recoveries. In this situation, the PSP receives several infringement notifications, each referring to a distinct Funds Recovery. In this case, the PSP must analyze each infringement notification in the context of the respective Funds Recovery and with all information available at the time of analysis.
It should also be highlighted that the ReporterParticipant field of the Infringement Notification always corresponds to the paying PSP of the transaction linked to the notification (TransactionId field). Thus, in the case of an infringement notification for a subsequent transaction, the ReporterParticipant is the PSP that effectively made the payment of the transaction, and not the PSP recovering the Funds Recovery.
Accepting a notification generates a fraud marking for the receiving user of the underlying transaction, regardless of whether the refund is carried out or not. Rejecting an infringement notification generates the immediate cancellation, by the DICT, of subsequent infringement notifications that are no longer connected to the payer of the root transaction. The analysis stage ends when there are no more infringement notifications pending analysis.
The recovering participant must also perform a merit analysis of the paying user's complaint and cancel the Funds Recovery if they understand that it is not a case of fraud or scam. The cancellation must be made even if the notifications have already been analyzed and closed by the receiving PSPs. To cancel the Funds Recovery, the recovering PSP must follow the provisions in section 20.1.10 “Cancellation of Funds Recovery”.
During the analysis stage, the recovering participant must periodically consult the ListEventNotifications endpoint to verify the closure of this stage, indicated by the FUNDS_RECOVERY_ANALYSED event of the FUNDS_RECOVERY entity. All participants who have accepted the infringement notifications must wait for the receipt of the refund request, the closure, or the cancellation of the Funds Recovery to unblock the resources in their users' accounts.
If all infringement notifications are rejected or cancelled, the Funds Recovery is automatically completed and moves to the COMPLETED status.
Further details involving procedures related to the infringement notification can be found in section 10.1 “Infringement notification for refund request”.
20.1.6 Refund
112 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
As soon as the analysis stage has been fulfilled, if the Funds Recovery has not been completed by the DICT due to the impossibility of having a refund, the recovering participant has up to 72 hours to initiate the refund stage, via the RefundFundsRecovery endpoint. During this period, the recovering PSP can continue to analyze the merit of the Funds Recovery.
If the recovering PSP identifies that the request should not have been opened, for any reason, they must cancel the Funds Recovery and not initiate the refund stage, even if the receiving PSPs have accepted the notifications. In case of cancellation, the provisions in section 20.1.10 “Cancellation of Funds Recovery” must be followed. The DICT will automatically complete, moving to the COMPLETED status, the Funds Recovery whose refund stage was not initiated within the 72-hour deadline.
Once the refund stage is initiated, the DICT builds the refund graph based on the transactions whose infringement notifications were accepted and that are connected to the root transaction through a continuous path of also accepted notifications.
Refund requests are carried out sequentially, with each one sent after the completion of the previous one, in the order established by the DICT. The value of each request will be, cumulatively, less than or equal to:
- the value to be blocked (InfractionAmount) of the infringement notification associated with the transaction subject to the refund;
- the outstanding value, given by the value of the root transaction minus the total value of refunds effectively carried out up to that moment in the Funds Recovery process.
All refunds must be effected through Pix transactions in favor of the paying user of the root transaction, up to the limit of the blocked value.
The RefundAccount field will be reported empty when the refund request refers to the root transaction itself. In this hypothesis, the refund must be made through a pacs.004 message, except when the root transaction is already a pacs.004, in which case the refund must be carried out through a pacs.008 message filled with the data of the paying and receiving users of the root transaction, in inverted positions.
For the other transactions identified in the tracking stage (subsequent transactions to the root transaction), the RefundAccount field will be filled. In these cases, receiving participants must debit their users' accounts and send a Pix transaction through a pacs.008 message, in which the PSP effecting the refund must appear as the payer. In addition, the finalidadeDaTransacao field must be filled with the value “IPRT”. The correct filling of this pacs.008 message is fundamental, as the DICT will validate the characteristics of the transaction at the time of closing the refund request.
When closing the refund request, the receiving participant must inform the DICT of the effectively refunded value through the EffectiveRefundedAmount field. There is no longer a need for the participant to monitor the account after the completion of the refund request, in case of partial refund or rejection of the request due to lack of balance. Until the MonitorAccount attribute is definitively excluded from the API, the DICT will always send the value “false” in this field.
Further details involving procedures related to the refund request can be found in section 17 “Refund request flow”.
113 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
20.1.7 Unblocking of Resources
The unblocking of resources by the receiving participant must occur only at the following moments:
- after rejecting the infringement notification;
- after completing the refund request; or
- if the Funds Recovery is cancelled or closed.
The receiving PSP must immediately notify their user about the unblocking of resources, according to the provisions of the Minimum Requirements Manual for User Experience.
20.1.8 Funds Recovery for Transactions Settled in Participants' Systems
It is possible to institute a Funds Recovery for a Pix transaction settled outside the SPI, provided it meets the minimum criteria to be traceable and the parameters that allow the generation of the tracking graph. If the transaction is identified, the process occurs normally.
Operations settled outside the SPI that are outside these limits are not recognized by the Funds Recovery process. In these cases, the participant must conduct the refund request through a procedure that does not involve the DICT, but that is still in compliance with the MED rules. In the case of a transaction within the same participant, they must be responsible for blocking the balance, analyzing the occurrence of scam or fraud, and processing the refund according to their conclusion. In the case of transactions between distinct participants, but under the same clearing house, the intermediation of the refund, following the guidelines established by the MED, must be the responsibility of the clearing participant.
In these situations, if there is confirmation that a receiving user was involved in some fraudulent transaction, the participant must register the fraud marking in the DICT, through the infringement notification for transactional fraud marking, as described in section 10.2 Infringement notification for transactional fraud marking.
20.1.9 Contestation of Refund Transaction for Fraud
The receiving user can contest any refund transaction, provided it was not carried out for the refund of an operational failure. Non-exhaustively, some examples of legitimate contestation of a refund are:
- refund of the root transaction in a Funds Recovery that was opened by the paying user with the purpose of defrauding the receiving user;
- proactive refund under coercion.
The contestation can be made within 80 days after the refund transaction.
In this case, the PSP of the receiving user must open a Funds Recovery and inform the refund transaction (pacs.004) that is being contested. The PSP can analyze the merit of the user's request before opening the Funds Recovery. The flow is exactly the same as the Funds Recovery for refund request, and the contested refund transaction will be the root transaction of the new Funds Recovery.
114 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
If the PSP receiving the refund transaction accepts the infringement notification, they must cancel the Funds Recovery opened previously, if it exists, so that the fraud markings generated improperly can be cancelled by the DICT (see section 20.1.10 Cancellation of Funds Recovery), and return the received resources, including resources from subsequent transactions.
20.1.10 Cancellation of Funds Recovery
A Funds Recovery can be cancelled at any time, even after it has been completed.
Only the recovering PSP that opened the Funds Recovery can cancel it. They must do this in the following situations:
- if they identify that the Funds Recovery was opened improperly, not fitting the situations of reimbursement for fraud of the MED; or
- after accepting an infringement notification for contestation of a refund transaction, whose original transaction corresponds to the root transaction of the Funds Recovery opened by them.
After cancelling the Funds Recovery, the recovering PSP must return the received resources to each of the receiving PSPs, provided there is sufficient balance in the user's account to enable the refunds. If the recovering PSP receives a refund request for a transaction already refunded, they must accept it, informing the identifier of the transaction carried out and the effectively refunded value. In this way, the DICT uses the information of the already refunded value (EffectiveRefundedAmount) to deduct from the amount to be requested in the new Funds Recovery.
If the recovering PSP returns the transaction to a receiving PSP of a subsequent transaction, this must credit the resources in their client's account, since the refund of the pacs.008 must result in the return of resources to the account of the PSP itself, which was who appeared as the payer of the original pacs.008.
All PSPs that received infringement notifications and did not reject them will be notified about the cancellation of the Funds Recovery through the FUNDS_RECOVERY_CANCELLED event (see section on Events Related to Funds Recovery). In addition, upon receiving a request to cancel the Funds Recovery, the DICT will cancel all infringement notifications linked to it. If the funds recovery is in the refund stage, the DICT will cancel the refund requests that are open and interrupt the refund stage, changing the status of the Funds Recovery to CANCELLED.
The cancellation of a Funds Recovery is definitive, as it is not permitted to open a new Funds Recovery for the same transaction, even if the previous one was cancelled.
20.1.11 Alteration of Funds Recovery
If the recovering PSP wishes to alter or complement the information of the Funds Recovery, they can do so through the updateFundsRecovery endpoint. It is possible to alter a Funds Recovery that is in the “CREATED”, “TRACKED” or “AWAITING_ANALYSIS” states. The DICT API will indicate which fields can be altered.
Participants will become aware of the alteration through the “FUNDS_RECOVERY_INFORMATION_UPDATED” event (see section 21 Event Notifications). The alterations made to the Funds Recovery are not replicated in the Infringement Notifications. In case of
115 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
receipt of the above event, the PSP must consult the Funds Recovery to see the updated information.
20.2 Flow of Institution and Blocking Request
For clarity, this flow illustrates only the case for direct participants. In the case of participants who access the DICT indirectly, communication with the DICT is intermediated by a direct participant, as agreed between the parties.
116 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
117 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
1 Paying User Action
Start of the process. Paying user accesses service channel and requests opening of the MED regarding a specific transaction due to fraud or scam.
2 Paying User Communication Paying user sends request to open the MED.
3 Recovering PSP Communication Recovering PSP receives request to open the MED.
4 Recovering PSP Action Recovering PSP retrieves data of the root transaction.
5 Recovering PSP Decision Recovering PSP checks if the root transaction was carried out in the last 80 calendar days (both for PACS.008 and for PACS.004).
If the transaction occurred longer ago than allowed, the recovering PSP must proceed to step 6.
Otherwise, they must proceed to step 9.
6 Recovering PSP Action Recovering PSP rejects the refund request.
7 Recovering PSP Communication Recovering PSP sends notification, informing the paying user about the rejection of the refund request.
8 Paying User Communication Paying user receives the notification regarding the rejection of the refund request. End of process.
9 Recovering PSP Communication If the transaction was settled outside the SPI, such as in the case between users with accounts in the same participant or in participants of the same clearing house and does not fit the operational limits to be tracked, the recovering PSP must resolve the refund internally, as explained in section 20.1.8 Funds Recovery for Transactions Settled in Participants' Systems. In other cases, the recovering PSP sends communication requesting the creation of Funds Recovery in the DICT through the message “Funds Recovery / Create Funds Recovery”, informing the Tracking Graph Parameters. 10 DICT Communication DICT receives message requesting the creation of Funds Recovery.
118 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5 11 DICT Action DICT creates Funds Recovery with Status “CREATED” and builds tracking graph and calculates Prioritization of Blocking Paths. 12 DICT Action DICT makes Infringement Notifications available to the receiving PSPs of the transactions in the calculated Prioritization of Blocking Paths, with status "Open" and updates the Status of the Funds Recovery to “WAITING_ANALYSIS”. 13 DICT Message DICT sends message to the recovering PSP, indicating the success of the transaction. 14 Recovering PSP Communication Recovering PSP receives the success message of the transaction and all proceed to the analysis stage. End of process.
20.3 Analysis Flow
For clarity, this flow illustrates only the case for direct participants. In the case of participants who access the DICT indirectly, communication with the DICT is intermediated by a direct participant, as agreed between the parties.
This flow refers to the analysis stage of the Funds Recovery, which begins with the availability of infringement notifications to the receiving PSPs by the DICT and ends when all notifications are completed. The flow described in the "Receiving PSP" lane represents the analysis flow of the infringement notification that each receiving PSP must follow upon receiving a notification. This includes both the receiving PSP of the root transaction and the receiving PSPs of subsequent transactions.
119 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
1 DICT Action
Start of the process. DICT makes infringement notifications available to the receiving PSPs of the transactions in the calculated prioritization of blocking paths, with status "Open". 2 Receiving PSP Action Receiving PSP periodically consults the DICT for the list of infringement notifications with state “Open” and reason “Refund Request”, through the message “Infringement Notification / List Infringement Notifications”. 3 Receiving PSP Action Receiving PSP identifies infringement notification with state “Open” and changes its state to “Received” through the message “Infringement Notification / Receive Infringement Notification”. 4 Receiving PSP Action Receiving PSP immediately blocks the total amount of the transaction in the receiving user's account. If the available amount in the receiving user's account is less than the transaction value
120 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
root, the PSP of the receiver blocks the total available amount.
5 PSP of the receiver Decision
The PSP of the receiver analyzes the infraction notification.
As determined by the Pix Times Manual, it has seven days to inform the DICT of the result of the analysis. If the notification is not accepted, the flow follows to step 6. If the notification is accepted, the flow follows to step 7.
6 PSP of the receiver Action The PSP of the receiver unblocks resources that had been blocked in the receiver user's account.
7 PSP receiver Message
The PSP of the receiver sends a message to the DICT, changing the status of the infraction notification to "Completed" through the message "Infraction Notification / Close Infraction Notification".
8 DICT Message DICT receives message, requesting status change to "Completed".
9 DICT Action
DICT makes the infraction notification available, with status "Completed". If the notification was rejected, DICT cancels the infraction notifications linked to subsequent transactions that do not form a connected path from the payer of the root transaction.
10 DICT Decision
DICT checks if all infraction notifications have already been completed.
If there is/are notification(s) that is/are not completed, the flow follows to step 11.
If all notifications are completed, the flow follows to step 12.
11 DICT Action DICT waits for the completion of the remaining notifications.
The flow returns to step 10.
12 DICT Action DICT completes the Analysis stage. End of process.
20.4 Refund Flow
For clarity purposes, this flow illustrates only the case for direct participants. In the case of participants that access the DICT indirectly, communication with the DICT is intermediated by a direct participant, as agreed between the parties. Similarly, for clarity in viewing the flow, the refund process was divided into two stages: root transaction refund stage and subsequent transactions refund stage. Thus, the two flows are complementary and the second starts immediately after the completion of the first.
121 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5 Root transaction refund stage:
122 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
1 PSP recoverer Action
Start of the process. PSP recoverer identifies the occurrence of the FUNDS_RECOVERY_ANALYSED event in periodic consultation to the DICT events endpoint, referencing the Funds Recovery initiated.
2 PSP recoverer Message PSP recoverer sends message "Funds Recovery/ Request Refund" to the DICT.
3 DICT Message DICT receives message to start refund in Funds Recovery.
4 DICT Action
DICT identifies, among the PSPs that accepted the infraction notifications, which form the largest connected graph from the root transaction, i.e., what is the largest chain of transactions with accepted infraction notifications that form a continuous path from the root transaction.
5 DICT Decision
DICT checks if the graph contains any transaction.
If it contains no transactions, it proceeds to step 6.
If this graph contains at least one transaction, it proceeds to step 10.
6 DICT Action DICT makes available on the events endpoint the conclusion of the Funds Recovery.
7 PSP recoverer Action
PSP recoverer identifies the occurrence of the event FUNDS_RECOVERY_COMPLETED in periodic consultation to the DICT events endpoint, referencing the Funds Recovery initiated.
8 PSP recoverer Message PSP recoverer notifies the payer user about the completion of the Funds Recovery process.
9 Payer user Communication
Payer user receives notification about the completion of the Funds Recovery process.
End of process.
10 DICT Action DICT makes Refund Request available to the PSP receiver of the root transaction.
11 PSP of the receiver of the root transaction Action PSP of the receiver of the root transaction identifies refund request with state "Open" in periodic consultation to the DICT, referencing the transaction received by the receiver user of the root transaction.
12 PSP of the receiver of the root transaction Decision PSP of the receiver of the root transaction checks if there are available resources in the receiver user's account. If there are resources, PSP of the receiver proceeds to step 13.
123 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5 If there are no available resources in the account, the flow proceeds directly to step 16.
13 PSP of the receiver of the root transaction Action PSP of the receiver of the root transaction sends refund order (sending of pacs.004) immediately.
In the case where the root transaction is already a PACS.004, a PACS.008 must be used.
14 PSP of the receiver of the root transaction Communication PSP of the receiver of the root transaction sends communication to the receiver user of the root transaction, informing about the refund.
15 Receiver user of the root transaction Communication Receiver user of the root transaction receives communication from their PSP. End of process.
16 PSP of the receiver of the root transaction Message PSP of the receiver of the root transaction sends message to the DICT, changing the state of the request to "Completed", with result "Accepted total", "Accepted partial" or "Rejected", as the case may be. If the result is "Rejected", the reason for rejection must be identified.
17 DICT Message DICT receives message of completion of the refund.
18 DICT Action DICT updates the refunded balance in the Funds Recovery. End of process.
124 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5 Subsequent transactions refund stage:
125 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Layer Type Description
1 DICT Action
DICT checks if there is remaining balance from the Funds Recovery and receivers in the sequence, following the prioritization defined by the DICT. If affirmative, the flow proceeds to step
2. If there is no remaining balance or
receivers in the sequence, it proceeds to step 11.
2 DICT Message DICT makes Refund Request available to the PSP receiver of the subsequent transaction.
PSP of the receiver of the subsequent transaction Action PSP of the receiver of the subsequent transaction identifies refund request with state "Open" in periodic consultation to the DICT, referencing the transaction received by the receiver user of the subsequent transaction. PSP of the receiver of the subsequent transaction Decision PSP of the receiver of the subsequent transaction checks if there are available resources in the receiver user's account. If there are resources, PSP of the receiver proceeds to step 5. If there are no available resources in the account, the flow proceeds directly to step 8. PSP of the receiver of the subsequent transaction Action PSP of the receiver of the subsequent transaction immediately debits the blocked resources from the account of its user and performs refund in favor of the payer user of the root transaction, through pacs.008 message in which the PSP itself figures as payer (and not its user). PSP of the receiver of the subsequent transaction Communication PSP of the receiver of the subsequent transaction sends communication to its user, informing about the refund. Receiver user of the subsequent transaction Communication Receiver user of the subsequent transaction receives communication from the PSP of the receiver of the transaction subsequent. End of process. PSP of the receiver of the subsequent transaction Message PSP of the receiver of the subsequent transaction sends message to the DICT, changing the state of the request to "Completed", with result "Accepted total", "Accepted partial" or "Rejected", as the case may be. If the result is "Rejected", the reason for rejection must be identified.
9 DICT Message DICT receives message of completion of the refund.
10 DICT Action DICT updates the refunded balance in the Funds Recovery and returns to step 1.
126 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
11 DICT Action DICT makes available on the events endpoint the conclusion of the Funds Recovery.
12 PSP recoverer Action
PSP recoverer identifies the occurrence of the event FUNDS_RECOVERY_COMPLETED in periodic consultation to the DICT events endpoint, referencing the Funds Recovery initiated.
13 PSP recoverer Message PSP recoverer notifies the payer user about the completion of the Funds Recovery process.
14 Payer user Communication
Payer user receives notification about the completion of the Funds Recovery process.
End of process.
127 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
21 Event Notifications
The events endpoint is a centralized way to consult the occurrence of events in the DICT that require the action of a PSP. Initially, only the Funds Recovery events will be consulted through this channel. The input parameters are as follows:
Field Mandatory Description
Participant ISPB
(Participant)
Mandatory ISPB of the direct or indirect participant interested Cursor (Cursor) Optional Used to access a specific pagination of the participant's notification history. The participant will send a request to the ListEventNotifications endpoint, informing its ISPB in the Participant field. The response, described in the DICT API, will list the notifications of the last 7 days in cascending order by date. A "true" value in the HasMoreElements field indicates that there are other notifications, and the NextCursor field provides the identifier of the next one. To obtain it, the PSP must send the request also filling in the Cursor field, with the received identifier. This cursor will always point to the same notification while it is within the 7-day window, returning empty from the moment it leaves. Each notification has the following fields, which always come filled in:
Field Description
Notification ID (Id) Identifier of that specific event in the DICT Event being notified (Event) Domains:
- FUNDS_RECOVERY_ANALYSED: indicates that the analysis stage of
Funds Recovery, referencing the EntityId provided, has been completed. - FUNDS_RECOVERY_INFORMATION_UPDATED: indicates that
the Funds Recovery, referencing the EntityId provided, has been altered: - FUNDS_RECOVERY_COMPLETED: indicates that the process of
Funds Recovery, referencing the EntityId provided, has been finalized. - FUNDS_RECOVERY_CANCELLED: indicates that the Funds
Recovery was cancelled.
Type of event that was notified
(EntityType)
Domain: - FUNDS_RECOVERY, when it concerns events
related to the Funds Recovery process
Event type ID (EntityId) Identifier of the entity described in EntityType, for example the FundRecoveryId in the case of a Funds Recovery.
Moment of creation of the event by the
DICT (Timestamp)
Presented in ISO8601 format.
128 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
21.1 Existing Events
21.1.1 Related to Funds Recovery
FUNDS_RECOVERY_ANALYSED
- Meaning: The Funds Recovery identified by the EntityId of the notification had its status
updated to ANALYSED. - Who receives: Recoverer participant of the Funds Recovery.
FUNDS_RECOVERY_INFORMATION_UPDATED
- Meaning: The Funds Recovery identified by the EntityId of the notification had its
detailing (ReportDetails) or contact data (ContactInformation) updated by the recoverer participant. - Who receives: Recoverer participant of the Funds Recovery, receiver participants
who have received notification(s) and who have not refused all of them.
FUNDS_RECOVERY_COMPLETED
- Meaning: The Funds Recovery identified by the EntityId of the notification had its status
updated to COMPLETED. - Who receives: Recoverer participant of the Funds Recovery, receiver participants
who have received notification(s) and who have not refused all of them.
FUNDS_RECOVERY_CANCELLED
- Meaning: The Funds Recovery identified by the EntityId of the notification had its status
updated to CANCELLED. - Who receives: Recoverer participant of the Funds Recovery, receiver participants
who have received notification(s) and who have not refused all of them.
129 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
22 Revision History
Date Version Description of changes
11/8/2020 1.0
10/9/2020 1.1 Section 6: Adjustments in the wording of the claim flow, to make its operation clearer:
- 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 the possession of the key, cancelling 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 until 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 make clear that the synchronization check does
not need to be performed daily. It needs to be performed at maximum intervals of 36 hours, according to the Pix Times Manual.
Section 10: adjustment to provide that the infraction notification can be
cancelled at any time.
Section 10.1: adjustment in the nomenclature of the messages sent to the
DICT.
Section 10.2: adjustment in the nomenclature of the messages sent to the
DICT.
13/11/2020 2.0 Structure: insertion of section 15 "Limitation of requests to the DICT API".
130 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 5: insertion of a footnote to explicitly state 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 explicitly state that it is possible
to update account data linked to the key while the status of the claim of possession request is "Open" or "Awaiting Resolution".
Section 9: insertion of text to detail how the process of
correction of divergent key after a synchronization check should be.
Section 10: removal of the "Reason" field in the process of opening an
infraction notification.
Section 14: removal of the information, which the DICT stores, related to
transactions with suspicion of violation of regulations against money laundering and terrorist financing.
17/11/2020 2.1 Section 9: guidance for any discrepancies found between the internal database and the DICT, after a synchronization check process, to 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 existence of Pix key".
Section 7.1: adjustment in the flow and in the 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 in the 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 that details the rate limit policy, with the inclusion of the limits for the 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 of refund request (Pix participants with direct access to the DICT)" and 10.4 "Flow of infraction notification for opening of refund request (Pix participants with indirect access to the DICT)".
Section 5: provision for the possibility of cancellation of a
portability with status "Confirmed" by the claiming PSP.
131 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 10: insertion of the "Reason" field and detailing of the fields in
opening an infraction notification; detailing of the fields in closing an infraction notification; and detailing of the operation of the infraction notification flow for opening of refund request.
Section 10.1: change of the section name to "Flow of infraction notification between Pix participants with direct access to the DICT, for
reason 'fraud'".
Section 10.1: maximum deadline for opening infraction notification
becomes eighty calendar days (step 2).
Section 10.1: maximum deadline for analysis of an infraction notification
becomes seven days (step 7).
Section 10.2: change of the section name to "Flow of infraction notification between Pix participants with indirect access to the DICT, for
reason 'fraud'".
Section 10.2: maximum deadline for opening infraction notification
becomes eighty calendar days (step 2).
Section 10.2: maximum deadline for analysis of an infraction notification
becomes seven days (step 14).
Section 13: maximum size of the end user's bucket becomes 1,000 tokens, with temporal increment of 2 tokens per minute; maximum
size of the participant's bucket becomes 20,000 tokens, with temporal increment of 6,000 tokens per minute; and insertion of text to give flexibility to the Central Bank of Brazil in the management of 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 make clear the date from
which the deadlines related to infraction notification will start to apply.
132 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 13: insertion of read attack prevention mechanisms for participants who provide payment transaction initiation service.
Section 15: inclusion of footnote 10, to make clear that the
same limits for verification of registered Pix keys are applicable to initiator participants.
24/8/2021 4.3 Section 10: insertion of footnote to make clear that the infraction notification for opening of refund request will be available only from November 16, 2021, in accordance with BCB Resolution No. 103.
Section 13: adjustments in the read attack prevention mechanisms of
the DICT. Queries without settlement for all types of keys now consume tokens in the buckets, both for end users and for 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 of
formation of the PayerId field.
Section 15: creation of a specific bucket for the updateEntry endpoint.
With this, the bucket of createEntry and deleteEntry was decreased.
Section 18: adjustment in footnote, to make clear that the refund request will be available only from November 16, 2021,
in accordance with BCB Resolution No. 103.
21/9/2021 4.4 Section 10: insertion of text to make clearer the operation of the functionality.
Section 10.3: insertion of footnotes to make clear the cases in
which the Special Refund Mechanism cannot be triggered.
Section 10.4: insertion of footnotes to make clear the cases in
which the Special Refund Mechanism cannot be triggered.
Section 13: adjustments in the read attack prevention mechanisms of
the DICT. Separation of buckets for PF and PJ user queries, with defined differentiated parameters, through the identification of the type of person by the PayerID field. In addition, the buckets for participant queries now have categories with differentiated parameters of size and increment, in order to adapt to the needs of each participant.
Section 13: adjustment in footnote 13, to make clear the format to be
used in the PayerId field.
133 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 15: removal of the general entries.read policy and inclusion of footnote, to explain that this policy is being treated with more
detail in section 13. In addition, the parameters of the update.entries policy were reduced.
Section 18: insertion of text to make clearer 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 erroneously.
Section 18.4: adjustment in the flow, to fix step 6, which was
identifying a state erroneously.
Section 18.5: insertion of footnotes, to make clearer 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 alter the way of
identifying the payer user in the consultation (payer user must be identified by means of their CPF/CNPJ, and no longer by means of a pseudonymized identifier.
Section 8.1: alteration in step 9 of the flow, to alter the way of
identifying the payer user in the consultation (payer user must be identified by means of their CPF/CNPJ, and no longer by means of a pseudonymized identifier).
Section 10: adjustments in 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 the case of transactions settled outside the SPI and of rejected transactions.
Section 10.2: adjustments to explain how the flow should be interpreted
in the case of transactions settled outside the SPI and of rejected transactions.
Section 13: alteration in the way of identifying the payer user in
the consultation (payer user must be identified by means of their CPF/CNPJ, and no longer by means of a pseudonymized identifier).
134 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 14: alteration in the security information returned by the DICT whenever a key is consulted.
19/11/2021 5.1 Section 14: the security information will continue, provisionally, to be presented whenever a key is consulted.
Section 15: insertion of the limitation of requests to the “statistics_read” endpoint.
Section 18: insertion of a new domain in the “RefundRejectionReason” field.
Section 19: provision that information about rejected transactions that have undergone an 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’s PSP and the payee’s PSP have the same liquidator, the counterparty that did not open the notification is the one that closes it, agreeing or disagreeing.
Section 16.1: adjustment in the flow and the step-by-step table due to the possibility of verifying the registration of all types of Pix keys.
Section 16.2: adjustment in the flow and the step-by-step table due to the possibility of verifying the registration of all types of Pix keys.
Section 17: adjustments in the text due to the possibility of verifying the registration of all types of Pix keys.
11/2/2022 5.3 Section 13: alteration in the way of reconstructing the tickets of the DICT consultation buckets, which are now replenished after receiving the payment order from the SPI in PACS.008, and no longer after a settlement.
Section 15: inclusion of the information in a 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 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.
135 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 13: participants providing initiation services must now use the same endpoint for key consultation as participants providing transactional account services. As a consequence, the rules of limits and of ticket decrease and increase now apply equally to all participants.
Section 15: increase in the increment of the bucket and the maximum size of the bucket 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 make clear that there is no specification of a value to be returned in an infraction notification.
Section 10.4: adjustment in the step-by-step table (step 16), to make clear that there is no specification of a value to be returned in an infraction notification.
Section 13: (i) increase from 10 to 20 in the decrease of tickets per invalid consultation 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 ticket increment per minute of the buckets of categories A and B, respectively; and (iii) adjustment in the maximum bucket size for end users who are natural persons and legal entities.
Section 15: (i) alteration in the name of the rate limit policy of 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’s PSP must open the infraction notification in the DICT immediately after the payer user’s complaint.
Section 10.3: adjustment in the flow and the step-by-step table to remove the condition in which the PSP cannot activate the MED.
Section 10.4: adjustment in the flow and the step-by-step table to remove the condition in which the PSP cannot activate the MED.
Section 18: (i) adjustment in the text to clarify that the request for refund cancellation must be created by the payee’s PSP; (ii) inclusion of details on the monitoring to be carried out by the PSP in case of partial refunds; and (iii) removal of the condition in which the PSP cannot activate the MED.
Section 18.1: adjustment in the flow and the step-by-step table to remove the condition in which the PSP cannot activate the MED.
136 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 18.2: adjustment in the flow and the step-by-step table to remove the condition in which the PSP cannot activate the MED.
Section 18.3: adjustment in the flow and the step-by-step table to remove the condition in which the PSP cannot activate the MED.
Section 18.4: adjustment in the flow and the step-by-step table to remove the condition in which the PSP cannot activate 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 the creation of two subsections: one to detail the infraction notification for refund request or for refund cancellation; 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 the “refund cancellation” type between participants with direct access to the DICT and the infraction notification flow of the “refund cancellation” type 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 ticket credit policy in transactions involving initiation service providers and the detailing of the limitation policy for the new getEntryStatistics operation) 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 make clear 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.
137 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
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 on the statistics endpoint.
Section 18.1 (corresponds to section 19.1 of the previous version): adjustment in the title and the flow.
Section 18.2 (corresponds to section 19.2 of the previous version): adjustment in the title and the 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 a determination that the payer’s PSP, if it accepts the infraction notification for refund cancellation, 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 cancelled by the claiming PSP while the status of the request is “Open”.
Section 6: Adjustment in the text to inform that a claim of possession can be cancelled 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 a payments intermediary.
Section 10.1: Insertion of determination that the payer’s PSP must cancel the open refund request if it has cancelled the infraction notification that gave rise to it. If a refund has occurred, the payer’s PSP must return the resources to the payee’s 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 in the replenishment rate per consultation of any key after receiving the payment order from the SPI to 2 tickets for the PJ user bucket and increase in the temporal increment to 20 tickets 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 may be altered.
138 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 13.1: Inclusion of a passage in the footnote to make clear that requests for bucket category increase must be duly grounded in historical data, and not in future projections.
Section 17: Inclusion of a passage to allow the payee’s PSP to end the monitoring of the payee user’s account if the infraction notification for refund request is cancelled by the payer’s 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 the creation of a subsection 8.1 to detail which information must be displayed to the user in the 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 make clear 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 make clear 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 make clear 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 make clear 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 who makes the consultation.
139 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 13.1: Inclusion of explanatory text on the functioning of the bucket when it has few tickets (fewer tickets than the penalty of a consultation with a return of an 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 alteration of the parameter from 30% to 20% in user monitoring. Inclusion of text to make clear that the DICT checkKeys endpoint is for PSP use only, 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 make clear that the DICT checkKeys endpoint is for PSP use only.
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 the authorization of automatic Pix in the possibilities of fraud.
Section 17: Inclusion of the payer’s 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’s PSP. Inclusion in the table in the Reason field the description: payer’s PSP error in sending a payment order regarding Automatic Pix (pix_automatico). Inclusion of a footnote for explanation that operational error in an Automatic Pix transaction is not included in the payer’s PSP operational failure reason. Inclusion of a footnote for explanation of what can be considered as an error by the payer’s PSP in sending a payment order regarding Automatic Pix. Inclusion of text, in the table of fields for closing a refund request, that if the reason for the refund request is pix_automatico the Refund Transaction Identifier (RefundTransactionId) must be informed in a pacs.008. Inclusion of the text “In cases related to Automatic Pix transactions where there is an error by the payer’s PSP in sending the payment order, there is no need for monitoring by the payee’s PSP in case of partial refund or rejection of the request”. Inclusion of a footnote explaining that refund requests related to cases of payer’s PSP operational failure and cases involving Automatic Pix transactions do not require the prior creation of infraction notifications. Creation of subsection 17.6 to detail the flow of refund request due to error by the payer’s PSP in sending a payment order regarding Automatic Pix. Creation of subsections
140 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
17.6.1 with the flow of refund request due to error by the payer’s PSP in sending a payment order regarding Automatic Pix for Pix participants with direct access to the DICT and 17.6.2 for Pix participants with indirect access to the DICT.
09/12/2024 7.4 Section 1.1: insertion of text to make clear that, if a judicially blocked key is consulted in an internal transaction, the PSP must return the blocking information to the user, without displaying the permitted information of the key.
Section 2: validation of possession becomes subsection 2.1, and addition of subsections detailing how the user’s registration status with the Federal Revenue impacts the creation and deletion of Pix keys.
Section 4: creation of subsection “4.1. Deletion of key due to incompatibility of data with the Federal Revenue”, with the guidance on the code to be used in the deletion of keys in these situations. The previous flows 4.1, 4.2, 4.3 and 4.4 were renumbered to 4.2, 4.3, 4.4 and 4.5, respectively.
Section 10.1: Inclusion of contact information (email and phone) of the PSP that opens the infraction notification.
Section 12: Increase in the maximum cache period for consulted keys to 180 seconds.
Section 17: creation of subsection “17.1 – Refund request due to operational failure”, with guidance on the opening and analysis of this type of refund request. The previous flows 17.1 and 17.2 were renumbered to 17.1.1 and 17.1.2. Subsections 17.3, 17.4, 17.5 and 17.6 of the previous version were transformed into 17.2, 17.3, 17.4 and 17.5, respectively.
01/04/2025 Sections 3.1, 3.2, 5.1, 5.2, 6.1, 6.2, 7.1 and 7.2: inclusion of a step for validation of user data and registration status with the Federal Revenue.
Section 17: obligation to fill in the RefundDetails field for refund request due to operational failure, and the RefundAnalysisDetails field in cases of rejection of refund request due to operational failure.
19/03/2025 7.5 Section 2.2: details made in the text of the section to include the processes of alteration, portability and claim of Pix keys and to detail the registration situations considered irregular.
Section 2.3: previously “2.3. Deadline for regularization of registration with the Federal Revenue”, was transformed into “2.3. Validation of names linked to Pix keys”.
141 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 4.1: clarifications on the provision of information to the user.
Sections 7.1 and 7.2: alteration of the text of step 1 of the diagram to encompass any change in the information linked to the key initiated by the PSP.
Inclusion of section 7.3 with clarifications on the provision of information to the user.
Section 12: alteration of obligation to recommendation regarding the use of internal cache for consultations of the same key by the same participant within the validity period.
Section 13.2.2: alteration of the term “equivalent” to “equal” regarding the limitation policy of participant consultations in relation to the DICT token bucket policy.
01/07/2025 Sections 3.1, 3.2, 7.1 and 7.2: alteration of the effective date of the step for validation of user data and registration status with the Federal Revenue during the registration and alteration of keys. 01/10/2025 Sections 5.1, 5.2, 6.1 and 6.2: alteration of the effective date of the step for validation of user data and registration status with the Federal Revenue during the portability and claim of possession of key. 28/08/2025 8.0 Section 6: improvement of wording.
Section 8: clarification that the social name must be present in the CPF to be able to be registered in a Pix key of a natural person.
Section 9: clarification on the reason “reconciliation” for updating information.
Section 13.1: clarification that the payer-ID informed in the consultation to the DICT must be the same identifier of the payer user of the related Pix transaction and inclusion of the need for approval by the participant’s cybersecurity director (when applicable) for requests for increase of DICT consultation bucket category.
Section 13.2.3: inclusion of the need for monitoring in longer periods and the non-permitted purpose as an anomalous situation.
Section 17: correction of the paragraph about the result of the analysis of a refund request to consider the settlement, and not the issuance, of a pacs.004 or of a pacs.008, in cases of Automatic Pix or cancellation of refund.
142 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Section 17.1: clarification on the sending of information by the PSP that opens the refund request due to operational failure.
01/10/2025 Section 10.1: clarification that it is permitted for the payer’s PSP to edit the infraction notification while it is in the states “open” or “received”.
23/11/2025 Enhancements to the rules and functionalities related to the MED:
- Changes in sections 10 “Infraction Notification”; 10.1 “Infraction notification for refund request or for refund cancellation”; and 17 “Refund request flow”.
- Creation of Section 20: “Value Recovery Flow”
- Creation of Section 21: “Event Notifications”
02/02/2026 8.1 Enhancements to the rules and functionalities related to the MED: - Section 10: Infraction Notification Flow
Adjustments in the text of sections 10 “Infraction Notification Flow” and 10.1 “Infraction notification for refund request or for refund cancellation” to include aspects of the infraction notification created through Value Recovery; Creation of section 10.1.5 “Flow of analysis of infraction notification in Value Recovery.” - Section 17: Refund Request Flow
Adjustments in the text of sections 17 and 17.1 to include aspects of the refund request for fraud created through Value Recovery; Inclusion of the field EffectiveRefundedAmount; Correction of the numbering of sections 17.1.1 and 17.1.2; Adjustments in the text of sections 17.2, 17.3, 17.4 to include aspects of the refund request for fraud created through Value Recovery;
Section “17.5 Flow of refund request due to error by the payer’s PSP in sending a payment order regarding Automatic Pix”: Clarification that, in the flow of refund request due to error by the payer’s PSP in Automatic Pix, the PSP must return to its client, using its own resources, the value of the transaction not yet recovered;
Correction of the numbering of sections 17.5.1 and 17.5.2; - Section 20: Value Recovery Flow
General adjustments in the text of the entire chapter; Inclusion of the detailing of the states of a Value Recovery;
143 • Operational Manual of the Directory of Transactional Account Identifiers (DICT) – Version 8.5
Removal of the FlowType field and the texts related to the interactive flow;
Section 20.1.1 was renamed to “Initiation”;
Section 20.1.2 was renamed to “Tracking”;
Section 20.1.3 was renamed to “Prioritization”;
Section 20.1.4 was renamed to “Request for blocking”;
Removal of Section 20.1.5 “Initiation in the automated flow”;
Section 20.1.6 was renumbered to 20.1.5 and renamed to “Analysis”;
Section 20.1.7 was renumbered to 20.1.6 and renamed to “Refund”;
Section 20.1.8 “Unblocking of resources” was renumbered to 20.1.7;
Section 20.1.9 “Value recovery for transactions settled in the participants’ systems” was renumbered to 20.1.8;
Creation of section “20.1.9 Cancellation of refund”; Creation of section “20.1.10 Cancellation of Value Recovery”; Creation of section “20.1.11 Alteration of Value Recovery”; Removal of section “20.2 Flow of initiation and request for blocking in the interactive flow”;
Section 20.3 was renumbered to 20.2 and renamed to “Flow of initiation and request for blocking”
Renumbering of sections 20.4 and 20.5 to 20.3 and 20.4, respectively; Review of flow 20.3 “Analysis flow”;
- Section 21: Event Notifications
Inclusion of the events
FUNDS_RECOVERY_INFORMATION_UPDATED and
FUNDS_RECOVERY_CANCELLED;
Alterations in the text;
Creation of Section 21.1 “Existing events”;
Creation of Section 21.1.1 “Related to Value Recovery”; Other alterations: - Section “2.3 Validation of names linked to Pix keys”:
Inclusion of a rule for the use of a single space instead of characters not accepted by the DICT API; - Section “6.1 Flow of claim of possession for the claiming PSP with direct access to the DICT”: Correction in the direction of case II of step 6.
144 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.5 11/05/2026 8.2 Improvements to rules and functionalities related to MED:
- Section 10: Infringement Notification Flow
Sections 10 and 10.1:
1 - Exclusion of the opening of infringement notification via the “Create Infringement Notification” endpoint; 2 - Exclusion of mentions of refund cancellation, which will now be executed via the opening of Value Recovery; 3 - Update of the rules for the infringement notification linked to Value Recovery.
Section 10.1.1: change in the section name to “Infringement notification flow for opening refund request”, adjustment in the text and removal of the flow.
Exclusion of sections 10.1.2, 10.1.3, 10.1.4 and 10.1.5. - Section 17: Refund Request Flow
1 - Exclusion of the refundCancelled domain from the RefundReason field of the Refund Request.
2 - Adjustments in the section text to update the rules for the refund request linked to value recovery.
Section 17.1: adjustment in the text regarding conduct in case of fraud or scam.
Section 17.2: change in the section name to “Refund request flow for ‘founded suspicion of fraud’”, adjustment in the text and removal of the flow.
Exclusion of sections 17.3 and 17.4.
Previous Section 17.5 was renumbered to 17.3, including the subsections. - Section 20: Value Recovery Flow
Sections 20, 20.1.1, 20.1.5, 20.1.6, 20.1.9 and 20.1.10: adjustments in the text to update the rules on Value Recovery.
Section 20.1.9 “Cancellation of refund” renamed to “Contestation of refund transaction due to fraud”.
09/06/2026 8.3 Changes in case of rejection of an infringement notification: during Value Recovery, after the rejection of an infringement notification, the DICT will automatically cancel all infringement notifications linked to subsequent transactions for which it is not possible to identify a connected path from the root transaction. Sections altered: - Section 10.1 Infringement notification for refund request.
- Section 20.1.5 Analysis.
- Section 20.1.6 Refund: clarification that the refund stage will occur only if the value recovery has not been completed automatically after the analysis stage.
- Section 20.3 Analysis Flow: change in step 9.
01/07/2026 8.4 Section 1: Change in the CNPJ key format to alphanumeric standard.
Section 17: exclusion of the need to monitor the account after partial refund or rejection of refund requests with RefundReason = FRAUD, minor adjustments in the text for clarification purposes.
Section 20: correction of the mandatory field TrackingGraphParameters.
Section 20.1.1: clarification on the types of pacs.004 transactions that can be contested.
Section 20.1.4: review of the text and clarification on the total value to be blocked in case of receipt of several infringement notifications linked to the same transaction.
Section 20.1.5: clarification on the possibility of receiving several infringement notifications associated with the same transaction and on the ReporterParticipant field of the Infringement Notification.
Section 20.1.6: clarification that the DICT will automatically finalize value recoveries whose refund stage has not been initiated by the Recovering PSP within the allowed period and exclusion of the need to monitor the account.
Section 20.1.9: clarification on which types of refund transactions can be contested.
Section 20.1.10: clarification that value recovery can be cancelled at any time.
146 • Operational Manual of the Transactional Account Identifiers Directory (DICT) – Version 8.5
Section 20.1.11: clarification that the change in Value Recovery is not replicated in the Infringement Notifications.
Section 20.3: change in the text of step 12.
01/09/2026 8.5 Extension of the period for contestation of refund transaction to 80 days:
- Section 20.1.1 Establishment;
- Section 20.1.9 Contestation of refund transaction due to fraud;
- Section 20.2 Establishment and blocking request flow: change in step 5.
26/10/2026 Inclusion of information, in the infringement notification, about the layer of the tracking graph corresponding to the transaction under analysis: - Section 10.1 Infringement notification for refund request: inclusion of the attribute “Graph Depth” (TransactionDepth);
Section 20.1.5 Analysis.
Read the rest free
Source: Banco Central do Brasil — original document · Summary generated with machine assistance and reviewed before publication; the authoritative text is the regulator's original document. How RegAlert works