PIX Brazil: Instant Transfers

1) What PIX is and why it matters iGaming

• high user coverage (mobile banks/wallets),
• low commission and lack of chargebacks like cards,
• instant cash-in/cash-out with strict compliance.

2) Key Elements of the PIX Ecosystem

Chave PIX (key): recipient identifier - CPF (physical person), CNPJ (Jurassic person), e-mail, telephone or random key.

DICT - PIX Centralized Key Registry

QR codes: static (fixed details) and dynamic (includes amount/purpose/TTL/parameters).
E2E ID/TxID - Unique transaction/account IDs for mapping and reconciliation.
Pix Cobrança: "invoice due" with date, penalties/discounts, similar to invoice.
Request for Payment (cobV/cobrança com vencimento): request payment to the payer with TTL.

3) iGaming User Cases

3. 1 Deposits (inbound)

Generate a dynamic QR or RfP with TxID = 'payment _ id'.
Reception to operator's CNPJ via PSP/bank; auto-enrollment with webhook.
Recommendation: include payment purpose and amounts in QR, TTL 10-30 minutes.

3. 2 Payments (outbound)

Payment for the player's PIX key (CPF/e-mail/phone/random) or directly by account details.
Before sending - validate the key in DICT, verify CPF ↔ full name (name-match), keep whitelist details with TTL.

3. 3 Service scenarios

Deposit return = new PIX transaction (reference to original 'payment _ id' in remittance).
VIP cashout: ETA "seconds/minutes" at the recipient's online bank.

4) Limits, night windows and risk policy

Basic limits per-tx/per-period are set by the bank/PSP and the customer profile; for B2C transfers there are "night" restrictions (usually evening to early morning) with reduced mouthguards to reduce social engineering.
The user can raise limits in his bank, but the delay of entry (anti-fraud) is applied.
On the merchant side: RBA limits by segment (new player/high risk/VIP), velocity by CPF/device/IP, geo-patterns.

5) Returns and MED (Mecanismo Especial de Devolução)

There is no classic chargeback, but there is MED - a special return mechanism for suspected fraud/operational errors.
Scheme: the recipient's bank can block and return funds at the request of the sender's bank if there is an incident (phishing/extortion, etc.).

• temporary blocking (up to ~ 72 h) for anomaly analysis;
• extended window for confirmed fraud cases (up to several weeks/months).
• Practice for iGaming: store verification artifacts (logs, KYC, consent), quickly respond to PSP requests, keep a log of MED outcomes.

6) Compliance: KYC/AML/sanctions/taxes

KYC: CPF (personality) and CNPJ (counterparty/affiliate) validation, PEP/adverse media screening.
AML/KYT: anomalies (rapid in→out, split amounts, new keys, "mules"), limits and manual review.
Sanctions/OFAC-analogue: local and international lists - check before sending/enrollment.
Data storage: PII minimization, tokenization, separate PII-vault, retention by law.

7) Integration and architecture

7. 1 Layers

Payments Core: invoices, statuses, limits, idempotence.
PIX Gateway (abstraction over PSP): QR/RfP generation, DICT validation, statuses, retry/failover.
Banking/PSP Layer: CNPJ settlement account, webhook/statement API.
Risk & Compliance: RBA/AML/KYT, MED orchestration.
Accounting & Recon: leyger, mepping 'payment_id ↔ e2e/TxID ↔ psp_ref'.
Monitoring: SLA, degradation alerts, MED cases.

7. 2 Flows

Deposit (QR/RfP): 'create an invoice → QR/RfP (TxID = payment _ id) → confirmation at the bank → webhook → crediting → reconciling'.
Payout: 'application → KYC/AML/DICT/name-match → sending → status posted → notification → reconsilation'.

7. 3 Orchestration and Feilover

Two or more PSPs to Brazil; if degradation is a fallback on boleto/TED/card push (as an extreme case).
Idempotence ('payment _ id/within _ id'), retry with backoff + jitter, signed webhooks.

8) Validation and error reduction

DICT key check and status (active/transferred).
Name-match: Reconciles the CPF/CNPJ name with the recipient's bank.
QR hygiene: checking the structure of the EMV field, amount, TTL, prohibiting the reuse of dynamic QR.
UX anti-phishing: show recipient name/amount large before confirmation, social engineering warnings.

9) Lager and Reconsilation

Identifiers: keep TxID, e2e ID, psp_ref, amount/commission/time.
T + 0/T + 1-reconciliation: Match PSP webhooks to bank statements/feeds.
Unmatched rows → unmatched queue with SLA.
Returns (including MED) - as separate movements, connect to the original 'payment _ id'.

10) Economy and SLA

Cost: Usually below cards; count Cost per Approved (all-in) = PSP tariff + opera time (MED/manual cases) + fallback share.
SLA: p50 "seconds," p95 "minutes"; at night additional checks are possible with banks - put it in ETA.

11) UX patterns (conversion and trust)

Auto-select PIX for Brazil, clear ETA ("usually seconds").

Button "Copiar código PIX" and QR; TTL timer and "create new account."

Clear statuses: "waiting for confirmation → credited/rejected/expired."

For payments - visual name-match: "We send João Silva (CPF... 123-45)."

12) Metrics and OKR

Approval/Success Rate for deposits and payments.
Time-to-Funds / Time-to-Payout p50/p95.
MED rate and success/failure rate average processing time.
DICT/name-match fail%, QR/TTL errors.
Unmatched recon%, share of manual cases, cost per approved.
Uptime PSP, webhook delays.

13) Anti-patterns

One PSP without reserve (SPOF).
Reception of "static" QR on mass streams without TTL/TxID → scattered reconsilation.
Absence of DICT/name-match and whitelist → errors/fraud.
No idempotency and signed webhooks → doubles/out of sync.
Ignoring "night" limits and RBA thresholds → a surge in MEDs and locks.
Mixing PII and payment logs without tokenization/RBAC.

14) Implementation checklist (short)

• 2 + PSP Contracts; support for dynamic QR/RfP, DICT, webhooks.
• TxID = payment_id, TTL for invoices; in remittance - reference to invoice.
• KYC (CPF/CNPJ), PEP/adverse, KYT/velocity, sanctions; whitelist details.
• DICT validation of keys and name-match before payments.
• MED playbook: roles, artifacts, response SLAs, outcome log.
• Lager and T + 0/T + 1-reconcilation; unmatched queue and deadlines.
• Idempotency, backoff + jitter, signed webhooks; fallback (boleto/TED/card).
• Дашборды: AR, Time-to-Funds/-Payout, MED, DICT/name-match fail, unmatched, cost.
• UX: code copy, QR, TTL timer, statuses; anti-fairy tales against social engineering.
• Support training: MED, night limits, frequent QR/DICT errors.

15) Summary

PIX is Brazil's workhorse for instant A2A payments. Build a multi-PSP loop with dynamic QR/RfP, DICT/name-match, strict RBA limits (including night), MED playbook, and reliable T + 0/T + 1 reconsilation. Such a stack will give you fast deposit conversion, second payments and controlled risks in Latin America's largest market.