DICT

Learn how DICT, BACEN’s Pix key directory, handles CPF, email, phone, and EVP key registration, portability claims, and account ownership.

The DICT (Directory of Transactional Account Identifiers) is the national registry of the Central Bank of Brazil (BACEN). It manages Pix keys and provides secure, interoperable addressing for the Pix ecosystem.

Pix keys let users receive payments with simple identifiers, such as a phone number or email. Users do not expose full banking details. DICT keeps these keys unique, auditable, portable, and correctly linked to the legitimate account holder.

This page gives an overview of DICT: key types, lifecycle, claims, validation rules, and the compliance rules for institutions that integrate Pix.

What DICT does

---

DICT is the backbone of Pix’s usability and security. It provides:

Addressing

Maps each Pix key to a specific transactional account.

Uniqueness

Prevents duplicate registrations across the entire Brazilian financial system.

Portability

Lets users move their keys between institutions and keep the same identifier.

Ownership integrity

Supports dispute flows when a key links to the wrong user.

Regulated lookup

Institutions can securely fetch recipient information before they process a transfer.

One key, one account. Always.

In Pix, a Pix key links to only one transactional account at a time. You cannot reuse the same key across multiple accounts or institutions at the same time.

DICT enforces this strict one-to-one rule. The rule is fundamental to:

• prevention of fund misrouting
• clear ownership
• system-wide consistency and auditability

DICT keeps Pix simple for users and interoperable for institutions.

Key types

---

Pix keys are unique identifiers that link a user’s bank account to the Pix payment system.

They let others send or receive instant payments without full account details. The sender uses an alias such as a CPF, email, phone number, or random key (EVP).

BACEN defines four official key types:

1. CPF / CNPJ (Registration Number / Tax Identifier)

---

What it is:

Uses the customer’s official tax identification number (CPF for individuals, CNPJ for businesses) as the Pix key.

Format:

• CPF: 11 digits → 12345678901
• CNPJ: 14 digits → 12345678000195

Characteristics:

• No confirmation required
• One key per document
• Easily identifiable but exposes personal data

Validation:

• Must match the account owner’s legal document
• Follows BACEN validation algorithms

2. Email

---

What it is:

Links a valid email address to the customer’s Pix account.

Format:

• Up to 77 characters
• Follows standard format → [e-mail]
• Case-insensitive

Characteristics:

• Requires token confirmation to the email address
• Easy to share and remember
• Does not expose personal data

Registration flow:

1. The customer requests an email key through Pix Switch
2. The institution sends a confirmation token to the email address
3. The customer confirms the token
4. The key becomes active in DICT

Validation:

• Requires confirmation within 5 calendar days
• Token is unique per request

Best for:

• Freelancers or professionals (e.g., [e-mail])
• Companies with multiple email addresses

3. Phone number

---

What it is:

Uses a mobile number in international format as a Pix key.

Format:

• E.164 international standard → [phone]
• +55 (country) + area code + number

Characteristics:

• Requires confirmation via SMS token
• Widely recognized and easy to use
• Doesn’t expose personal data

Rules:

• Accepts only mobile phones (no landlines)
• Requires confirmation within 5 calendar days
• Can register multiple numbers per account

Common use cases:

• Small business owners or service providers
• Customers who prefer simplicity (“Pix to my phone number”)

4. Random key (EVP)

---

What it is:

A system-generated unique identifier (UUID v4) for maximum privacy.

Format:

123e4567-e89b-12d3-a456-426614174000

Characteristics:

• No confirmation required
• Does not reveal any personal or business data
• Available instantly
• Hard to memorize manually

When to use:

• Privacy-focused users
• Large companies or franchises that need separate receiving accounts
• One-off or temporary payment flows

Rules:

• Generated automatically by the provider
• Unique and non-reusable
• Up to five keys total per account across all types (BACEN regulation)

Key limits and rules (BACEN Regulation)

---

Type	Limit
Total Pix keys per account	5
CPF / CNPJ	1 per account
Phone	1 per number
Email	1 per address
EVP	Unlimited, within the 5-key limit

Key lifecycle

---

A Pix key follows a standardized lifecycle from BACEN. The lifecycle keeps consistency, security, and interoperability across all participating institutions.

1. Registration

A user or institution registers a Pix key. The request associates an identifier — a CPF, email, phone number, or random key — with a specific transactional account.

At this stage, the key enters a pending state. It waits for validation according to its type.

2. Confirmation

Some Pix keys require explicit confirmation of ownership before they become active:

• Email / Phone number → Confirmation token sent to the contact method
• CPF / CNPJ → Automatically validated and confirmed
• EVP (Random key) → Automatically generated and confirmed

This step makes sure the identifier truly belongs to the user.

3. Activation

Once confirmed, the Pix key becomes active.

At this point, the key can:

• Appear in DICT lookups
• Receive Pix transfers
• Work with QR Codes and payment flows

4. Update

Certain changes may require new validations or confirmations. Examples include a change to the linked account or the ownership details. The exact requirement depends on the key type and the update.

5. Removal

Two parties can remove a Pix key:

• The user removes it voluntarily.
• The institution removes it for compliance, account closure, or regulatory reasons.

Once removed, the key becomes unavailable for new transactions.

6. Synchronization

Institutions must continuously synchronize their local state with the BACEN DICT.

This guarantees that:

• Key status remains consistent across the ecosystem
• Portability and ownership claims stay correct
• No outdated or invalid keys remain active

Ongoing synchronization is mandatory for regulatory compliance and operational reliability.

Figure 1. Pix key creation flow

Portability & Ownership claims

---

Pix key claims are official requests in the BACEN DICT. A claim modifies the ownership or association of a Pix key.

They keep every key — phone, email, CPF, or CNPJ — correctly linked to its legitimate owner and financial institution.

Pix Switch automates the claim process, from request to confirmation. It provides secure ownership validation, institutional interoperability, and traceability under the BACEN DICT standard.

Claim types

---

In the Pix ecosystem, a claim is a formal request in the DICT. A claim changes the ownership or association of a Pix key.

There are two distinct types of claims. Each type serves a different purpose and follows specific business logic:

Portability (PORTABILITY)

What it is:

Applies when a customer wants to transfer an existing Pix key — an email, phone number, CPF, or CNPJ — from one financial institution (Bank A) to another (Bank B).

Goal:

Keep the same Pix key identifier and change the linked institution. This is similar to mobile number portability.

Example:

A user closes their account at Bank A and opens a new account at Bank B.

They want to keep the same phone number as their Pix key.

→ Bank B initiates a portability claim with DICT.

→ DICT notifies Bank A to release the key.

→ Once confirmed, ownership moves to Bank B.

Key points:

• Requires customer confirmation in the original institution.
• Involves both institutions (old and new).
• Result: the key changes institution but keeps the same identifier.

Ownership (OWNERSHIP)

What it is:

Applies when a Pix key links to the wrong account or institution. This is a dispute over who truly owns the key.

Goal:

Correct an erroneous key registration so the legitimate owner regains control of the identifier.

Example:

The telecom provider recycles a phone number that belonged to a user.

When a new user registers the same number, DICT identifies that the number already belongs to someone else.

→ The institution initiates an ownership claim to check and correct the key’s rightful owner.

Key points:

• Focused on ownership integrity, not migration.
• Starts from a system validation or a user report.
• May require verification documents or confirmation from both parties.
• Result: the key remains in the same institution, but ownership moves to the rightful owner.

Summary table

Claim Type	Purpose	Triggered by	Result
PORTABILITY	Move key from one institution to another.	Customer request at new institution.	Key transferred to new institution.
OWNERSHIP	Correct ownership when a key is wrongly linked.	Conflict detection or customer report.	Key remains in same institution, with corrected owner.

Figure 2. How to choose the right claim type

Claim flow — Portability & Ownership

---

Pix claims manage key reassignment and portability requests within BACEN’s DICT.

They keep every Pix key correctly linked to its legitimate owner and financial institution.

Pix Switch handles two types of claims:

• Portability: transfers a Pix key between institutions and keeps the same holder.
• Ownership Claim: corrects the key’s ownership when it links to the wrong user.

Both processes share the same DICT API flow and endpoints. They differ only in business logic and validation rules.

Participants

• Claimant Institution (Bank B): initiates the claim — either to transfer a key (Portability) or to correct ownership (Ownership Claim).
• Current Institution (Bank A): receives the DICT notification and must confirm or reject the request.

Scenario 1 — You are the Claimant Institution (Bank B)

In this case, the customer belongs to Bank B (you), which will receive the key.

Bank B creates, tracks, and cancels the claim when necessary.

1. Create Claim

The customer requests a Pix key change. The change transfers the key from another institution or corrects its ownership.

Bank B initiates the claim in DICT.

Result:

• The claim starts with status OPEN.
• DICT notifies Bank A (current owner) to validate or reject the request.

2. Monitor Claim status

Bank B tracks the claim lifecycle through periodic queries or webhook notifications from DICT.

Possible transitions:

OPEN → WAITING_RESOLUTION → CONFIRMED → COMPLETED

3. Complete Claim

After approval, DICT finalizes the process and synchronizes the change across institutions.

• For Portability, the key becomes inactive in Bank A and active in Bank B.
• For Ownership Claim, the key remains in the same institution, but ownership moves to the legitimate owner.

4. Cancel Claim (optional)

If the customer or institution decides not to proceed, they can cancel the claim while it waits for resolution.

Figure 3. Bank B request for Pix key claim

Scenario 2 — You are the Current Institution (Bank A)

In this scenario, the customer belongs to Bank A (you). Bank A currently holds the key that another institution requests.

Bank A must validate the claim request from DICT.

1. Receive notification

DICT notifies Bank A about the claim request from Bank B.

The claim appears with status WAITING_RESOLUTION.

2. Validate Claim

When DICT notifies Bank A of an incoming claim, the institution must check the request.

The claim type sets the next step. It may require customer confirmation or document review.

Result:

• If approved → DICT transfers the key to Bank B.
• If denied → the claim status becomes CANCELLED.

3. Completion

After approval, DICT finalizes the process and synchronizes the change across institutions.

• For Portability, the key becomes inactive in Bank A and active in Bank B.
• For Ownership Claim, the key remains in the same institution, but ownership moves to the legitimate owner.

Figure 4. Bank A handling Pix key claim

Security requirements (BACEN + Market Standards)

---

Institutions must enforce:

• End-to-end encryption of key data
• Rate limits for registration attempts
• Token expiration and one-time usage
• Strict validation of CPF/CNPJ, phone, and email
• Internal audit logs for all DICT operations
• Event tracking for confirmation, cancellation, and deletion

Institutions must minimize PII exposure in logs and user interfaces.

Synchronization & Reconciliation

---

DICT requires strong consistency between institutions and BACEN.

Institutions must implement:

Periodic Sync

Pull updates for all keys that belong to the institution.

Event-Driven Sync

Listen to DICT notifications for:

• Key activation
• Key deletion
• Claim creation/resolution

Conflict Resolution

If a mismatch appears:

• Institution must update its records
• The institution must replace older or conflicting data
• Audit logs must record the transition

Use cases

---

Registering a Pix Key

A freelancer registers an email key for business payments.

Porting a Key

A user moves a phone number key from one institution to another during a bank switch.

Correcting Ownership

The institution reassigns a recycled mobile number to the new legitimate owner.

Removing an Old Key

Business updates its EVP keys for accounting segmentation.

Regulatory reference

This page gives a practical overview of how Pix works. For deeper technical, legal, and regulatory details, always refer to the official documentation from the Central Bank of Brazil (BACEN). It covers rule changes, deadlines, and official requirements.

BACEN’s materials are the authoritative source for Pix regulations. They contain the most complete and current specifications.