alex/rwo-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b63baa8959196c0ab50cf58f98f2c20e68322f82
rwo-docs/docs/countries/brazil-partners.md
alex wiesner b63baa8959 repo redirection
2026-04-09 16:13:59 +01:00

33 KiB
Raw Blame History

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

Supporting watchlist and adjacency sources

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

Reference in New Issue View Git Blame Copy Permalink