rwo-docs/docs/countries/brazil-partners.md

# Brazil partner report

This report expands the initial Brazil shortlist into a more decision-useful view of the partner landscape for our commission infrastructure thesis.

Brazil is structurally different from Switzerland.

Because `Pix` already sets strong expectations around real-time money movement, the most important question is not whether the market understands instant payouts. It does. The question is which partners can let us deliver that experience with:

- a compliant launch structure under a regulated partner
- reliable employer and worker onboarding
- auditable commission-ledger integration
- 24/7 `Pix` cash-out to the worker
- later support for stored balance and card issuance

## Executive summary

### Best one-provider launch cluster

If we want the fastest route to live pilots with the fewest moving parts, the strongest Brazil candidates are now better framed as a **cluster**, not just a top three:

- **Dock**
- **QI Tech**
- **Bankly**
- **Celcoin**

These are the clearest current candidates for the regulated account, `Pix`, and later-card story in one operating setup.

### Strong additional alternatives worth diligence

The strongest additional names to add to the comparison set are:

- **FitBank**
- **Z.ro Bank**
- **Zoop**

These are not all equal in fit, but they are credible enough to keep in the active Brazil landscape.

### Best modular architecture option

If we want a more configurable stack rather than a single all-in-one vendor, the strongest architecture path is still:

- **Pismo** as the modern core technology layer
- **Celcoin** as the licensed BaaS layer

That pairing remains notable because Pismo's own documentation explicitly says it is **not a licensed bank** and works with BaaS partners such as **Celcoin**.

### Specialist adjacencies to keep warm

- **Pomelo** for card specialization
- **Transfeera** for payout and collections operations
- **PagBrasil** for local payments and Automatic Pix adjacencies

### Main conclusion

For Brazil, the right structure is:

1. run a one-provider comparison wave across **Dock, QI Tech, Bankly, and Celcoin**
2. keep **FitBank** and **Z.ro Bank** in the alternative set
3. evaluate **Pismo + Celcoin** in parallel if we want a split-stack architecture
4. treat **Pomelo, Transfeera, Zoop, and PagBrasil** as specialists or adjacencies unless the pilot shape pulls them forward

---

## What our product needs from a Brazil partner

### Must-have at launch

1. **24/7 `Pix` payouts**
   - Our wedge is access to earned commissions through the local instant rail.
   - The partner must support high-volume, always-on `Pix` disbursement.

2. **PF and PJ onboarding**
   - Employer KYB and worker KYC need to be production-grade.
   - Weak onboarding will kill pilot velocity.

3. **Programmable ledger-adjacent workflows**
   - We keep our own commission ledger logic.
   - The partner must expose enough API surface to support:
     - balance creation and movement
     - payout requests
     - payout status
     - transaction eventing
     - reversals, disputes, and adjustments where applicable

4. **Reserve and exception handling**
   - Brazil requires explicit handling for:
     - refund requests
     - `Pix` infractions
     - chargebacks when commission creation is tied to card payments
     - employer clawback and holdback logic

5. **External account cash-out**
   - At launch, the worker should be able to receive money in an existing account through `Pix`.
   - We should not require the worker to adopt a new full banking relationship just to use the product.

### Important, but can come later

1. stored balance / wallet behavior
2. debit or prepaid card issuance
3. limited-use or incentive-style card products
4. employer-backed advance products
5. deeper acquiring or bill-collection integration

### Not worth leading with

1. consumer lending
2. generic digital-bank positioning
3. a card-first user story before the `Pix` payout workflow works well

---

## Brazil market reality for partner selection

Brazil is a much richer partner environment than Switzerland for this thesis.

### Why that matters

There are more credible ways to assemble the stack:

- all-in-one BaaS
- bank-licensed API platforms
- core-banking-plus-licensed-partner combinations
- card specialists that can be added later
- payout and collections specialists that can support a narrower launch scope

### What this means for us

We should be explicit about which route we prefer.

## Route A: fastest path to launch

Pick a single partner that can cover:

- accounts
- `Pix`
- onboarding and compliance support
- reporting
- later cards

This is the most attractive route if speed and operational simplicity matter more than technical purity.

## Route B: most configurable architecture

Use:

- a modern core platform for accounts, events, `Pix`, cards, and controls
- a licensed BaaS provider for the regulated layer

This is attractive if we want more control over product behavior and are comfortable managing two vendors.

## Route C: narrower `Pix`-first launch scope

Use a payout-led or payment-led provider when the pilot scope is intentionally narrow:

- external `Pix` cash-out first
- limited or no stored-balance behavior at launch
- cards explicitly later

This can be viable for some design-partner pilots, but only if it does not weaken the core commission-ledger thesis.

---

## Evaluation criteria

| Criterion | Why it matters for us |
| --- | --- |
| `Pix` execution and uptime | The core user promise in Brazil is instant access to earned money |
| Regulatory structure | We want to launch under a regulated partner rather than direct custody |
| PF/PJ onboarding | Employer and worker onboarding speed affects pilot success |
| API and event maturity | We need programmable workflows, not manual back office dependence |
| Reversals / disputes / fraud controls | Essential when payouts can happen before final settlement certainty |
| Card readiness | Important for later retention, but not the launch wedge |
| Sandbox and developer docs | Important for rapid iteration and partner diligence |
| Commercial fit | Minimums and implementation complexity can kill an otherwise good choice |

---

## Public-evidence scorecards

**Legend:** `High` = strong fit from reviewed official materials, `Medium` = partial fit or meaningful gaps still unclear, `Low` = weak public evidence for this use case.

### Full-stack / launch-core scorecard

| Partner | Regulated layer | `Pix` depth | Accounts / KYC fit | API / docs quality | Card path | Current priority |
| --- | --- | --- | --- | --- | --- | --- |
| **Dock** | High | High | High | Medium | High | **Priority 1** |
| **QI Tech** | High | High | High | Medium | Medium | **Priority 1** |
| **Bankly** | High | High | High | High | Medium | **Priority 1** |
| **Celcoin** | High | High | High | High | High | **Priority 1/2** |
| **FitBank** | Medium | High | Medium | High | Medium | **Priority 2** |
| **Z.ro Bank** | Medium | High | Low-Medium | High | Low | **Priority 2/3** |
| **Zoop** | Medium | Medium-High | Medium | High | Medium | **Priority 3** |

### Split-stack / specialist scorecard

| Partner | Best role | Regulated layer | `Pix` / payout depth | Card depth | API / docs quality | Current priority |
| --- | --- | --- | --- | --- | --- | --- |
| **Pismo** | Core technology platform in split stack | Low as standalone | High | High | High | **Priority 1 for split-stack** |
| **Pomelo** | Card issuing / processing specialist | Low | Low | High | Medium | Watchlist |
| **Transfeera** | `Pix` payouts / collections adjunct | Medium | High | Low | High | Priority 3 |
| **PagBrasil** | Local payments / Automatic Pix adjunct | Low | Medium | Low | Medium | Watchlist |

---

## Shortlist at a glance

| Partner | Type | Best role in our stack | Public-evidence launch fit | Public-evidence later fit | Overall priority |
| --- | --- | --- | --- | --- | --- |
| **Dock** | Full-stack banking, `Pix`, cards, fraud, acquiring | Single-provider launch partner | **High** | **High** | **Priority 1** |
| **QI Tech** | BaaS and regulatory / tech infrastructure | Single-provider launch partner | **High** | High | **Priority 1** |
| **Bankly** | BaaS platform with banking license and direct `Pix` participation | Single-provider launch partner | **High** | High | **Priority 1** |
| **Celcoin** | Licensed BaaS / core banking / cards | Single-provider alternative or licensed layer behind Pismo | High | High | **Priority 1/2** |
| **Pismo** | Core banking / cards / `Pix` technology platform | Technology core in split-stack model | Medium as sole partner | **High** | Priority 1 for split-stack |
| **FitBank** | BaaS / `Pix` / onboarding / prepaid card infrastructure | Alternative one-provider path | Medium | Medium-High | Priority 2 |
| **Z.ro Bank** | Digital bank, Pix-as-a-Service, gateway, crypto / payments infrastructure | Alternative `Pix`-first path | Medium-Low | Medium | Priority 2/3 |
| **Zoop** | Banking + payments + split infrastructure | Alternative if payment splits and marketplace logic matter | Medium-Low | Medium | Priority 3 |
| **Transfeera** | Payments API / `Pix` / boleto / payout ops | Payout and collections adjunct | Low as sole core | Medium | Priority 3 |
| **Pomelo** | Card issuing / processing specialist | Later-stage card specialist | Low | High | Watchlist |
| **PagBrasil** | Local payments / `Pix` specialist | Collection or local payment adjunct | Low | Medium | Watchlist |

---

## Detailed partner assessments

## 1. Dock

### What it is

Dock is the clearest all-in-one Brazil option in the current shortlist.

Its public materials show meaningful breadth across:

- digital accounts
- `Pix`
- cards and processing
- fraud prevention
- treasury and reconciliation support
- white-label financial products

### What the official materials clearly show

Dock states that it offers:

- white-label digital banking with digital account, cards, `Pix`, slips, and related features
- a base of **over 75 million active accounts**
- `Pix` capabilities including:
  - becoming an **indirect participant**
  - QR code generation
  - `Pix` as payment method
  - `Pix` on bills and slips
  - automatic `Pix`
- more than **1 billion `Pix` transactions** processed in the last year according to its `Pix` materials
- white-label cards with:
  - physical and virtual cards
  - branded cards
  - prepaid and debit options
  - Visa, Mastercard, Amex, and Elo access
- card-processing support including settlement, reconciliation, chargeback management, and balance-impacting transaction management
- support for **multi-benefit cards** and other workforce-adjacent products

### Why it fits our thesis

Dock matches our roadmap unusually well:

- `Pix`-first payout wedge
- later stored-balance and card layer
- employer workflow potential
- regulatory and operational cover under a third-party provider

The workforce-adjacent products are especially interesting.

Its multi-benefit and payroll-adjacent materials suggest it already understands employer-to-worker financial flows, even if our product is a commission infrastructure product rather than a classic benefits card.

### Best role in our stack

**Single-provider launch partner** for:

- accounts and balances
- `Pix` disbursement
- onboarding support
- future prepaid/debit card program
- treasury and reconciliation support

### Main questions to validate

1. Can Dock support an employer-funded commission access model without forcing a full consumer-bank UX on day one?
2. Can we keep our own commission ledger while using Dock only for regulated balances and money movement?
3. What account structure works best: employer master account plus worker accounts, or a pooled model with payout instructions?
4. How configurable are payout rules, approval steps, and holdbacks?
5. Can we start with `Pix`-out only and add cards later without re-architecting?
6. What are the commercial minimums and implementation timelines for an early-stage company?

### Assessment

**Strongest all-in-one Brazil candidate.**

If we want one partner that can plausibly get us from pilot to later card products, Dock is the first call.

---

## 2. QI Tech

### What it is

QI Tech presents itself as a BaaS platform with both technology and regulatory infrastructure.

### What the official materials clearly show

QI Tech states that its BaaS offering can support:

- card issuing
- payments
- digital accounts
- credit
- individual or linked accounts
- broader financial operations through a single BaaS setup

Its `Pix` materials also highlight:

- a solution to operate as an **indirect `Pix` participant**
- **high-availability APIs**
- **direct connection to the Central Bank**
- regulatory and compliance support
- modular account architecture or use of QI Tech's own core
- dedicated onboarding, implementation, and support squads

### Why it fits our thesis

QI Tech looks like a strong middle ground between:

- a pure full-stack provider like Dock
- and a more modular architecture like Pismo + Celcoin

It appears capable of supporting the launch wedge directly while still offering architectural flexibility.

### Best role in our stack

**Single-provider launch partner** for:

- `Pix`
- account infrastructure
- onboarding and compliance support
- later cards
- potentially more advanced financial products if we ever need them

### Main questions to validate

1. How opinionated is the account architecture for a B2B2C employer-sponsored use case?
2. What does worker onboarding look like in practice for a commission payout flow?
3. Can we run `Pix` cash-out without forcing full-featured digital accounts from day one?
4. How strong are reporting, webhooks, and reconciliation for employer operations?
5. What are the real implementation timelines for a startup-scale pilot?

### Assessment

**Top-tier Brazil candidate.**

QI Tech deserves to be in the first wave of outreach, especially if we want a serious regulated partner that still feels modern and API-first.

---

## 3. Bankly

### What it is

Bankly is especially notable because its official materials explicitly describe it as a **technology company with a banking license**.

That makes it one of the cleaner one-partner stories in Brazil.

### What the official materials clearly show

Bankly states that it offers:

- a BaaS platform with **more than 30 APIs**
- a complete digital account
- card issuing within Mastercard's network
- bank slip issuance
- TED transfers
- sandbox access
- individual and business account opening
- individual and business KYC
- direct participation in **`Pix`**
- connection to the **Brazilian Payment System (SPB)** with a settlement account and bank number

### Why it fits our thesis

Bankly checks many launch boxes cleanly:

- regulated story
- direct `Pix` participation
- PF and PJ onboarding
- cards later
- documented API surface and sandbox

That is particularly compelling for a company that wants to ship a commission infrastructure product without managing too many counterparties.

### Best role in our stack

**Single-provider launch partner** for:

- worker payouts by `Pix`
- employer and worker onboarding
- account support
- card issuance later
- core banking primitives for the regulated layer

### Main questions to validate

1. How flexible is Bankly's model for employer-funded balances and worker-visible earnings?
2. Can payouts be done to external `Pix` keys without requiring a full account-first experience?
3. What controls exist for reserves, payout limits, and employer approval chains?
4. How mature is support for webhook-driven operational workflows?
5. How does Bankly compare commercially with Dock and QI Tech for an early-stage pilot?

### Assessment

**Strong first-wave candidate.**

Bankly looks particularly attractive if we want a simple story: bank-licensed infrastructure, direct `Pix`, cards later, documented APIs.

---

## 4. Pismo

### What it is

Pismo is a modern core banking, cards, and payments technology platform.

But the key nuance is important:

**Pismo explicitly says it is not a licensed bank and does not directly implement BaaS.**

That means Pismo should not be evaluated as a standalone regulated partner.

### What the official materials clearly show

Pismo's official documentation states that, with a partnering BaaS provider, it can support:

- organization, program, and account setup
- `Pix` instant payments
- boleto payments
- P2P transactions
- cash-out transfers to external accounts
- reporting and eventing
- transaction validation, anti-fraud, and KYC-related support

Its `Pix` documentation also shows unusually rich operational depth, including:

- `Pix` key management
- `Pix` in and out
- reversals
- scheduled and recurring `Pix`
- infraction reports
- refund requests
- anti-fraud webhooks
- dynamic QR and BR code generation

Its card documentation shows support for:

- physical and virtual cards
- prepaid, debit, credit, and private label
- tokenization and wallet support
- configurable limits and lifecycle controls

### Why it fits our thesis

Pismo is attractive if we want a highly programmable core that can support:

- internal commission-ledger logic on our side
- flexible event-driven workflows
- deep `Pix` operations
- future card issuance with strong controls

### Best role in our stack

**Technology core** in a split-stack model, typically with a regulated BaaS partner such as Celcoin.

### Main drawback

Pismo adds architectural power, but also more complexity.

We would need to coordinate at least:

- the core technology provider
- the licensed BaaS partner
- commercial and operational responsibility boundaries between them

### Assessment

**Excellent technology platform, but not the sole launch partner.**

Pismo makes the most sense if we intentionally choose a split-stack architecture.

---

## 5. Celcoin

### What it is

Celcoin is important for two reasons:

1. it appears to be a capable BaaS and core-banking provider in its own right
2. it is explicitly named by Pismo as one of the BaaS partners used to enable banking services

That makes Celcoin strategically relevant even if we never choose Pismo.

### What the official materials clearly show

Celcoin's documentation states that BaaS clients can integrate using **Celcoin's banking license** and infrastructure.

The official docs and product pages show support for:

- onboarding and KYC
- account creation and management
- balance and statement reporting
- webhooks
- `Pix` in and `Pix` out
- `Pix` key registration and portability
- TED transfers
- collections and bill payments
- white-label card issuance
- physical and virtual cards
- prepaid and postpaid cards
- recurring and temporary virtual cards
- combined card modes in some setups

Its BaaS product page also emphasizes:

- integrated onboarding
- Open Finance support
- transfer and bill-payment capabilities
- Visa credit-card support
- developer-oriented documentation, samples, and real-time webhooks

### Why it fits our thesis

Celcoin can be viewed in two ways:

1. **standalone candidate** for launch
2. **licensed layer** in a more modular architecture

That flexibility is valuable.

### Best role in our stack

Either:

- **single-provider launch partner** if commercial and operational fit is good enough
- or **licensed BaaS layer behind Pismo** if we want a more configurable stack

### Main questions to validate

1. How strong is Celcoin as the main operator for a B2B2C employer-driven payout workflow?
2. Can it support the separation we need between our commission ledger and the regulated balance layer?
3. How much product logic can be encoded without custom services work?
4. If paired with Pismo, where do responsibilities split for support, fraud, reversals, and reconciliation?

### Assessment

**High-value candidate and important architecture enabler.**

Even if we do not choose Celcoin alone, it belongs in the first serious architecture conversations.

---

## 6. Pomelo

### What it is

Pomelo appears strongest as a card issuing and processing specialist for Latin America.

The evidence we reviewed points to:

- issuing and processing
- BIN sponsorship
- risk management
- support for prepaid, debit, credit, business, and virtual cards

### Why it matters to us

Pomelo is relevant if cards move up the roadmap earlier than planned, or if we eventually want a more specialized card partner than a full-stack BaaS provider.

### Why it is not a top launch pick

For our initial wedge, the main challenge is not card issuance. It is:

- `Pix` payouts
- worker onboarding
- employer controls
- regulated money movement tied to the commission ledger

Pomelo looks better for **later card specialization** than for the first launch dependency.

### Assessment

**Keep warm as a phase 2 or phase 3 card watchlist candidate.**

---

## 7. PagBrasil

### What it is

PagBrasil looks more like a strong local payment and `Pix` specialist than a full BaaS answer.

The official materials we reviewed emphasized **Automatic Pix** and developer-oriented local payment integration.

### Why it matters to us

PagBrasil may become relevant if we later care about:

- recurring collections
- local payment acceptance
- payment-event ingestion for employer sales or invoice flows

### Why it is not a primary launch candidate

The current thesis requires more than a payment rail.

We also need:

- regulated account structure
- onboarding
- balance management
- payout orchestration
- later card optionality

### Assessment

**Adjacency / rail specialist, not the core Brazil launch answer.**

---

## Additional Brazil alternatives to diligence

### Z.ro Bank

What the reviewed public materials clearly show:

- Z.ro describes itself as a **Brazilian digital bank** and crypto exchange
- its docs homepage highlights **Pix as a Service**, **Zro Gateway**, a **Crypto API**, and a **Payments Gateway API**
- the PaaS docs show API credentials, test environment URLs, and Pix flows via **Pix key, dynamic QR code, or bank account**
- the Gateway docs show a useful control pattern for **whitelisting deposit and withdrawal accounts**, with BACEN-related constraints around the number of linked accounts

Why it matters:

- Z.ro is worth considering if we want a more tightly controlled **`Pix`-first wallet / gateway / external-account cash-out** setup
- the withdrawal-account controls are especially relevant to fraud and beneficiary-governance questions

Main gap versus the top one-provider candidates:

- public evidence is much stronger on `Pix`, gateway, and payments infrastructure than on broad PF/PJ onboarding, employer workflow tooling, and later card depth

### FitBank

What the reviewed public materials clearly show:

- FitBank describes `Fit$ Cash` as a comprehensive financial-services API platform
- the docs explicitly mention **PIX**, boleto collection, utilities and taxes payments, online balance and statement, **digital onboarding**, and **prepaid card** in a white-label experience
- the PIX docs state that **FitBank is a direct participant with PIX**

Why it matters:

- FitBank is the strongest newly added **all-round alternative** to the original one-provider set
- it deserves real diligence if pricing, implementation speed, or commercial fit from the top four is weak

### Zoop

What the reviewed public materials clearly show:

- Zoop's banking docs cover **digital accounts**, **PIX**, **P2P transfers**, **TED**, webhooks, and both **physical and virtual cards**
- Zoop's Pix product page emphasizes **automatic split of payments** and payment flows embedded in branded journeys

Why it matters:

- Zoop becomes more interesting if employer cash flows, receivables, and split logic are central to the design-partner use case
- it may be especially relevant if commission creation is tightly linked to marketplace-like payment flows

Main gap for our thesis:

- the public story is more payments / commerce / split-led than employer-funded commission-infrastructure-led

### Transfeera

What the reviewed public materials clearly show:

- Transfeera positions itself as an **authorized payment institution** with API and platform support for **Pix** and **boleto**
- the public materials reference **sandbox**, **subaccounts**, **multicontas**, **payment split**, batch payments, and a **Pix infraction panel**
- it publishes availability and transaction-volume metrics and seems especially strong in finance-ops execution

Why it matters:

- Transfeera is a serious **payout and collections specialist** if we want strong finance-ops tooling without making it the full BaaS core

Main gap for our thesis:

- it is not the obvious choice if we also want account creation, card issuance, and broader embedded-banking behavior in the same stack

---

## Recommended stack options for Brazil

## Option A: one-provider comparison wave

Choose from the main one-provider set:

- **Dock**
- **QI Tech**
- **Bankly**
- **Celcoin**

Keep **FitBank** as the strongest additional all-round alternative.

### Why this is attractive

- fastest route to market
- fewer responsibility boundaries
- simpler operations during pilot stage
- easier partner management for a small team

### Best fit when

- we want to prove employer demand quickly
- we do not yet need deep custom infrastructure decisions
- we want `Pix` first and cards later

### Current recommendation inside this option

- **Dock** if we want the strongest visible full-stack breadth
- **Bankly** if we want a very clean bank-licensed and direct-`Pix` story
- **QI Tech** if we want a strong regulated/API-first middle ground
- **Celcoin** if we want a stronger modularity bridge toward a later split-stack path
- **FitBank** as the next alternative if commercial fit or implementation speed is better

---

## Option B: configurable split stack

**Pismo + Celcoin**

- Pismo as core platform for accounts, events, cards, and `Pix` logic
- Celcoin as the licensed BaaS layer

### Why this is attractive

- potentially better control over architecture
- strong developer depth
- cleaner path if we want a highly programmable core
- explicit compatibility signal because Pismo names Celcoin as a BaaS partner

### Main risk

- more implementation complexity
- two commercial relationships
- possible ambiguity around support ownership and operational accountability

### Best fit when

- we already know we want a more custom platform architecture
- we have enough product clarity to justify higher integration overhead

---

## Option C: narrower `Pix`-first pilot

**Z.ro Bank or Transfeera** for a limited-scope pilot, if:

- the employer-funded use case is mostly external `Pix` cash-out
- we are not launching cards in v1
- we do not need a rich stored-balance product on day one

### Why this is attractive

- can be useful for a tightly scoped design-partner pilot
- keeps focus on the strongest immediate user promise: fast `Pix` access to earned commissions

### Main risk

- risks under-building the broader account, onboarding, and balance-management layer we will eventually need

---

## Option D: one-provider launch + specialist later

**Dock or QI Tech or Bankly or Celcoin or FitBank now** + **Pomelo later if needed**

### Why this is attractive

- keeps the launch simple
- preserves optionality if we later want a more differentiated card program

### Main risk

- later rework or multi-vendor complexity

---

## Recommended outreach order

### Priority 1: one-provider comparison wave

- **Dock**
- **QI Tech**
- **Bankly**
- **Celcoin**

Goal:

- compare the strongest regulated one-provider launch paths
- understand pricing, pilot minimums, timeline, and onboarding complexity

### Priority 2: architecture and alternatives

- **Pismo**
- **FitBank**
- **Z.ro Bank**

Goal:

- evaluate whether the extra flexibility of a split stack is worth the added complexity
- compare serious alternatives if the top one-provider set is too expensive, too slow, or too opinionated

### Priority 3: specialists and adjacencies

- **Zoop**
- **Transfeera**
- **Pomelo**
- **PagBrasil**

Goal:

- keep optionality for payment-split use cases, payout-ops tooling, specialized cards, or local collection workflows

---

## Questions to ask every Brazil partner

1. Can you support an **employer-funded commission access** product rather than a consumer-first banking app?
2. What account structures do you support: named worker accounts, virtual accounts, pooled balance structures, or another model?
3. Can workers receive `Pix` payouts to an **external key** without using a full bank-account UX from day one?
4. What KYC/KYB steps are mandatory before first payout?
5. What webhooks and event streams are available for:
   - account changes
   - `Pix` status changes
   - failures
   - reversals
   - fraud or infraction cases
6. How do you handle `Pix` refunds, infractions, MED-related flows, and suspicious activity?
7. Can employer approval workflows, reserve rules, and payout limits be enforced programmatically?
8. How do reconciliation exports and statements work for finance teams?
9. Can we start with `Pix` and add cards later without changing the core regulated setup?
10. What are the commercial minimums, implementation fees, and expected pilot timeline?
11. Do you support both PF and PJ onboarding natively?
12. What support model exists for incidents on nights, weekends, and holidays?

---

## What a good Brazil partner outcome looks like

A strong Brazil partner should let us support this operational sequence:

1. ingest a payment or validated sale event
2. create a commission entry in our own ledger
3. apply employer rules and reserve logic
4. mark an eligible amount as available
5. send a `Pix` payout on demand to the worker
6. handle failures, infractions, or clawbacks without breaking the audit trail
7. add stored balance and cards later if economics and retention justify them

If a partner is great at cards but weak at steps 4 through 6, it is not the right first partner.

---

## Recommended next steps

### Commercial

Run a first comparison wave across **Dock, QI Tech, Bankly, and Celcoin**.

Keep **FitBank** and **Z.ro Bank** as active alternates if the main one-provider set is too expensive, too slow, or too rigid for an early pilot.

Use the same briefing memo for each:

- employer is the buyer
- worker is the beneficiary
- `Pix` payout is the launch wedge
- our own commission ledger remains the source of truth
- stored balance and cards are later features
- direct custody is not the launch model

### Technical

Prepare a diligence worksheet covering:

- account model
- `Pix` in and out coverage
- PF/PJ onboarding
- webhook coverage
- exception handling
- reporting
- sandbox quality
- card readiness
- implementation timeline

### Architecture

In parallel, hold one architecture session on **Pismo + Celcoin** specifically to answer:

- what extra flexibility do we gain?
- what extra integration burden do we accept?
- which responsibilities sit with which party?

### Legal and compliance

Map with counsel:

- employer vs worker money-flow roles
- whether balances are treated as payment-account balances, instructions, or another claim structure under the partner setup
- labor-law treatment of commission availability and deductions
- who owns customer support and fraud handling under the chosen partner model

---

## Evidence reviewed

### Official and primary materials

- Pismo BaaS docs: https://developers.pismo.io/pismo-docs/docs/banking-as-a-service
- Pismo `Pix` docs: https://developers.pismo.io/pismo-docs/docs/pix-instant-payments
- Pismo cards docs: https://developers.pismo.io/pismo-docs/docs/cards-overview-1
- Dock white-label digital banking: https://dock.tech/en/solution/white-label-digital-banking-platform/
- Dock white-label cards: https://dock.tech/en/solution/white-label-cards/
- Dock `Pix` overview: https://dock.tech/solucoes-pix/
- QI Tech BaaS: https://qitech.com.br/en/baas/
- QI Tech indirect `Pix`: https://conteudo.qitech.com.br/pix-indireto/
- Bankly BaaS: https://www.bankly.com.br/en
- Celcoin BaaS docs: https://developers.celcoin.com.br/docs/sobre-o-baas
- Celcoin BaaS product page: https://www.celcoin.com.br/solucoes/banking-as-a-service/
- Celcoin card product page: https://www.celcoin.com.br/cel_card
- Celcoin card issuance docs: https://developers.celcoin.com.br/docs/emiss%C3%A3o-de-cart%C3%B5es
- Z.ro Bank docs overview: https://docs.zrobank.io/overview/introduction
- Z.ro Bank PaaS docs: https://docs.zrobank.io/paas/api-overview/introduction
- Z.ro Bank Gateway docs: https://docs.zrobank.io/gateway/api-overview/how-to-use
- FitBank developer docs: https://dev.fitbank.com.br/
- FitBank PIX intro: https://dev.fitbank.com.br/docs/1-introdu%C3%A7%C3%A3o
- Zoop Pix product page: https://zoop.com.br/pix/
- Zoop banking docs: https://docs.zoop.com.br/docs/
- Transfeera API payments: https://transfeera.com/solucoes/api-de-pagamentos/
- Transfeera Pix solution: https://transfeera.com/solucoes/pague-receba-pix/

### Supporting watchlist and adjacency sources

- Pomelo issuing and processing: https://pomelo.la/latam/cards/
- PagBrasil Automatic Pix integration guide: https://www.pagbrasil.com/blog/pix/pagbrasils-automatic-pix-integration-guide-for-developers/

---

## Bottom line

For Brazil, the key decision is not just **which partner is good**.

It is **which architecture path and launch scope we want**.

Current recommendation:

- **Run first-wave commercial diligence with Dock, QI Tech, Bankly, and Celcoin** as the strongest one-provider launch set
- **Keep FitBank and Z.ro Bank in the active alternative set**
- **Evaluate Pismo + Celcoin in parallel** as the strongest split-stack architecture path
- **Use Zoop, Transfeera, Pomelo, and PagBrasil as specialists or adjacencies**, not default launch anchors

That approach keeps the launch aligned with the core thesis:

`commission infrastructure first, instant Pix access second, cards later`