974 lines
33 KiB
Markdown
974 lines
33 KiB
Markdown
# 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`
|