repo redirection
This commit is contained in:
alex wiesner
19
docs/countries/README.md
Normal file
19
docs/countries/README.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Country Notes
|
||||
|
||||
Core planning docs in `docs/` should stay geography-agnostic. Country-specific launch assumptions, payout rails, partner choices, regulatory notes, and go-to-market details belong in this directory.
|
||||
|
||||
## Current dossiers
|
||||
|
||||
- `brazil.md` - Brazil-specific notes in pt-BR, centered on `Pix`, local partner choices, and launch considerations
|
||||
- `switzerland.md` - Switzerland-specific notes in English, centered on bank-based payouts, compliance expectations, and launch considerations
|
||||
|
||||
## Supporting reports
|
||||
|
||||
- `brazil-partners.md` - Expanded partner landscape for Brazil, including Dock, QI Tech, Bankly, Pismo, Celcoin, and specialist watchlist options
|
||||
- `switzerland-partners.md` - Expanded partner landscape for Switzerland, including HBL Solutions, Yapeal, SIX b.Link, Swisscom, and adjacent options
|
||||
|
||||
## Guidance
|
||||
|
||||
- Add new countries as separate files rather than baking local assumptions into the core docs.
|
||||
- Keep the core product thesis, ledger model, and employer workflow consistent across countries.
|
||||
- Document local rails, regulation, partner dependencies, and target verticals here.
|
||||
973
docs/countries/brazil-partners.md
Normal file
973
docs/countries/brazil-partners.md
Normal file
@@ -0,0 +1,973 @@
|
||||
# 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`
|
||||
191
docs/countries/brazil.md
Normal file
191
docs/countries/brazil.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# Tese para o mercado brasileiro
|
||||
|
||||
## Resumo
|
||||
|
||||
A melhor entrada para esta ideia no Brasil e uma plataforma B2B2C que conecta recebimento, calculo de comissao, ledger interno e acesso instantaneo ao saldo via `Pix`.
|
||||
|
||||
O produto inicial nao deve ser vendido como banco digital nem como credito ao consumidor. A tese mais forte e:
|
||||
|
||||
`transformar cada venda validada em saldo de comissao disponivel quase em tempo real`
|
||||
|
||||
## Por que o Brasil primeiro
|
||||
|
||||
- `Pix` ja criou expectativa de movimentacao instantanea e barata.
|
||||
- O mercado convive com atraso no pagamento de comissoes e com o uso informal de `vales`.
|
||||
- Existem instituicoes financeiras, cooperativas, BaaS e emissores abertos a parcerias.
|
||||
- Ha muitos segmentos com equipes comerciais comissionadas e operacao digital crescente.
|
||||
- O argumento de valor e simples: menos atraso, menos friccao operacional e mais retencao do time de vendas.
|
||||
|
||||
## Dor local que o produto resolve
|
||||
|
||||
### Para a empresa
|
||||
|
||||
- Calculo manual de comissao.
|
||||
- Fechamento mensal demorado.
|
||||
- Falta de visibilidade sobre passivo de comissao.
|
||||
- Uso informal de `vales`, com pouca governanca.
|
||||
- Dificuldade para reconciliar recebimento, comissao, estorno e repasse final.
|
||||
|
||||
### Para o vendedor
|
||||
|
||||
- Venda feita hoje, dinheiro disponivel so dias ou semanas depois.
|
||||
- Dependencia de `vale` para cobrir caixa pessoal.
|
||||
- Falta de transparencia sobre o que foi ganho, o que esta disponivel e o que ainda esta pendente.
|
||||
|
||||
## ICP inicial
|
||||
|
||||
O foco deve ser empresas brasileiras com time comercial comissionado e recebimento digital identificavel.
|
||||
|
||||
Segmentos promissores:
|
||||
|
||||
- franquias e operacoes de varejo com vendedores comissionados
|
||||
- clinicas de estetica, odontologia e procedimentos eletivos
|
||||
- academias e servicos recorrentes com equipe de vendas
|
||||
- escolas, cursos e educacao privada com captacao comercial
|
||||
- telecom, distribuicao e revendas com metas e bonificacao variavel
|
||||
|
||||
## Proposta de valor no Brasil
|
||||
|
||||
### Para a empresa
|
||||
|
||||
- Automatizar o calculo e o repasse de comissoes.
|
||||
- Reduzir dependencia de `vales` informais.
|
||||
- Melhorar retencao e motivacao do time.
|
||||
- Ter visao confiavel de performance comercial e custo de comissao.
|
||||
- Ganhar previsibilidade de caixa e de passivo.
|
||||
|
||||
### Para o colaborador
|
||||
|
||||
- Ver a comissao quase em tempo real.
|
||||
- Sacar instantaneamente via `Pix` quando o saldo estiver disponivel.
|
||||
- Ter mais clareza sobre metas, historico e projecao de ganhos.
|
||||
- No futuro, usar saldo por cartao sem precisar sacar tudo.
|
||||
|
||||
## Produto recomendado para o Brasil
|
||||
|
||||
### V1
|
||||
|
||||
- recebimento via parceiros de pagamento
|
||||
- motor de regras de comissao
|
||||
- ledger com estados `ganho`, `disponivel` e `liquidado`
|
||||
- saldo para colaborador e empresa
|
||||
- saque instantaneo via `Pix`
|
||||
- dashboard basico para empresa e vendedor
|
||||
- trilha de auditoria por transacao, comissao e ajuste
|
||||
|
||||
### V2
|
||||
|
||||
- saldo retido em carteira
|
||||
- analytics de performance e passivo de comissao
|
||||
- regras de reserva para estorno e chargeback
|
||||
- alertas e projecoes
|
||||
- piloto de adiantamento com respaldo do empregador
|
||||
|
||||
### V3
|
||||
|
||||
- cartao prepago ou debito
|
||||
- maior retencao de saldo na plataforma
|
||||
- integracoes com ERP, POS, CRM ou software vertical
|
||||
|
||||
## Parceiros locais que importam
|
||||
|
||||
### Infra financeira
|
||||
|
||||
- instituicao de pagamento, banco parceiro ou BaaS para custodia e movimento regulado
|
||||
- exemplos de infraestrutura para avaliar: `Dock`, `QI Tech`, `Celcoin`
|
||||
- cooperativas e bancos menores podem ser parceiros comerciais ou institucionais, incluindo nomes como `Sicredi`, dependendo do modelo
|
||||
|
||||
### Processamento de pagamentos
|
||||
|
||||
- parceiros para `Pix`, boleto e cartao
|
||||
- exemplos para avaliar: `Pagar.me`, `Stripe BR`, `Adyen`
|
||||
|
||||
### Emissao de cartao
|
||||
|
||||
- exemplos para avaliar: `Dock`, `Pomelo`, `Swap`
|
||||
|
||||
### KYC e KYB
|
||||
|
||||
- exemplos para avaliar: `idwall`, `BigDataCorp`
|
||||
|
||||
### Juridico e regulatorio
|
||||
|
||||
- escritorio com experiencia em instituicao de pagamento, arranjos de pagamento, `Pix`, LGPD e temas trabalhistas
|
||||
|
||||
## Consideracoes regulatorias
|
||||
|
||||
O produto encosta em varias frentes e precisa de mapeamento juridico desde cedo.
|
||||
|
||||
- Banco Central: estrutura de `Pix`, conta transacional, instituicao de pagamento, regras de reporte e compliance.
|
||||
- Direito do trabalho: natureza da comissao, reflexos em folha, desconto de adiantamentos, regras contratuais com empregador.
|
||||
- LGPD: dados financeiros e de performance do colaborador.
|
||||
- CDC e transparencia: fees, prazos, disponibilidade e regras de estorno.
|
||||
|
||||
Recomendacao pratica:
|
||||
|
||||
- comecar debaixo da licenca e da infraestrutura de um parceiro regulado
|
||||
- evitar custodia direta no inicio
|
||||
- evitar vender o produto inicial como emprestimo
|
||||
|
||||
## Como tratar `vales`
|
||||
|
||||
No Brasil, `vale` e um substituto informal para um problema real de liquidez. O produto pode reduzir esse comportamento sem virar credito agressivo logo no inicio.
|
||||
|
||||
Sequencia recomendada:
|
||||
|
||||
- acesso ao que ja foi ganho e validado
|
||||
- liberacao conservadora de parte do saldo antes da liquidacao total
|
||||
- adiantamento com respaldo do empregador
|
||||
- so depois, se fizer sentido, credito com underwriting proprio
|
||||
|
||||
Mensagem correta:
|
||||
|
||||
- nao: `emprestimo para vendedor`
|
||||
- sim: `acesso controlado a comissao ja gerada`
|
||||
|
||||
## Go-to-market no Brasil
|
||||
|
||||
### Primeiro movimento
|
||||
|
||||
- fechar 5 a 10 design partners com dor forte de comissao e operacao relativamente simples
|
||||
- priorizar empresas em que o evento de venda e facil de mapear ao pagamento
|
||||
- vender para dono, financeiro, operacoes e gestor comercial
|
||||
|
||||
### Canais de distribuicao
|
||||
|
||||
- venda direta para SMB e mid-market
|
||||
- parceria com software vertical, POS e adquirencia
|
||||
- grupos de franquia
|
||||
- escritorios contabeis e consultorias de operacao ou folha
|
||||
|
||||
### Pitch inicial
|
||||
|
||||
- reduza trabalho manual no fechamento de comissoes
|
||||
- de ao time acesso mais rapido ao que ja foi ganho
|
||||
- troque `vales` informais por um processo auditavel
|
||||
- tenha visao em tempo real de performance e passivo de comissao
|
||||
|
||||
## Modelo economico mais provavel
|
||||
|
||||
- fee de plataforma para a empresa
|
||||
- fee por volume processado ou por pagamento conciliado
|
||||
- fee por saque, ou plano com franquia de saques
|
||||
- camada premium de analytics
|
||||
- depois: interchange de cartao
|
||||
- depois: compartilhamento de economia financeira, se permitido pelo arranjo com parceiro
|
||||
|
||||
## Principais riscos no mercado brasileiro
|
||||
|
||||
- estorno ou chargeback depois da liberacao da comissao
|
||||
- disputa entre empresa e vendedor sobre regra de comissao
|
||||
- dependencia excessiva de um parceiro bancario ou de BaaS
|
||||
- classificacao regulatoria errada do produto
|
||||
- onboarding ruim para empresa e colaborador
|
||||
|
||||
## Tese final para o Brasil
|
||||
|
||||
O melhor posicionamento nao e `mais um app de EWA` e nem `mais um banco digital`.
|
||||
|
||||
O melhor posicionamento e:
|
||||
|
||||
`a infraestrutura de comissao em tempo real para empresas brasileiras, com saldo disponivel via Pix e visibilidade operacional para o empregador`
|
||||
728
docs/countries/switzerland-partners.md
Normal file
728
docs/countries/switzerland-partners.md
Normal file
@@ -0,0 +1,728 @@
|
||||
# Switzerland partner report
|
||||
|
||||
This report expands the initial Switzerland shortlist into a more practical partner view for our commission infrastructure thesis.
|
||||
|
||||
The goal is not to find a generic fintech vendor. The goal is to identify which Swiss partners could realistically support:
|
||||
|
||||
- a regulated launch structure without direct custody
|
||||
- employer and worker onboarding
|
||||
- auditable money movement tied to commission events
|
||||
- controlled payouts to linked bank destinations
|
||||
- a later move into stored balance and card-based retention tools
|
||||
|
||||
## Executive summary
|
||||
|
||||
### Correction to the original framing
|
||||
|
||||
The earlier version of this report leaned too quickly toward a single company for each infrastructure function.
|
||||
|
||||
A better Switzerland view is a **layered comparison set**, not a one-vendor-per-layer assumption.
|
||||
|
||||
### Regulated account and payout cluster
|
||||
|
||||
These are the most relevant candidates for the **regulated money layer**:
|
||||
|
||||
- **HBL Solutions / Hypothekarbank Lenzburg**
|
||||
- **Yapeal Embedded**
|
||||
- **InCore Bank**
|
||||
|
||||
HBL still has the strongest public-evidence fit today, but Yapeal and InCore should be in the core diligence set rather than treated as side notes.
|
||||
|
||||
### Connectivity and orchestration cluster
|
||||
|
||||
These are the most relevant candidates for **bank connectivity, payment submission, or orchestration across providers**:
|
||||
|
||||
- **SIX b.Link**
|
||||
- **Swisscom**
|
||||
- **additiv**
|
||||
|
||||
These should be viewed as enabling layers, not automatic substitutes for the regulated bank partner.
|
||||
|
||||
### Card and employee spend cluster
|
||||
|
||||
These are the most relevant candidates for a later **employee card / spend / retention** layer:
|
||||
|
||||
- **Yapeal**
|
||||
- **HBL**
|
||||
- **additiv + regulated issuer setup**
|
||||
|
||||
### Adjacency watchlist
|
||||
|
||||
These are worth tracking, but should not anchor the first Swiss build:
|
||||
|
||||
- **Swissquote** for treasury, corporate banking, and institutional adjacency
|
||||
- **Nuvei** for broader payments and payout orchestration adjacency
|
||||
|
||||
### Main conclusion
|
||||
|
||||
For Switzerland, the right move is to compare a **cluster of viable partners per layer**:
|
||||
|
||||
1. compare **HBL, Yapeal, and InCore** for the regulated account and payout layer
|
||||
2. compare **SIX, Swisscom, and additiv** only if connectivity or orchestration complexity appears early
|
||||
3. keep **Swissquote** and **Nuvei** as adjacency/watchlist rather than first-wave launch dependencies
|
||||
|
||||
That is more consistent with the thesis in `docs/countries/switzerland.md` and avoids over-committing to one provider too early.
|
||||
|
||||
---
|
||||
|
||||
## What our product needs from a Swiss partner
|
||||
|
||||
### Must-have at launch
|
||||
|
||||
1. **Regulated money movement**
|
||||
- We should launch under a licensed partner structure rather than taking direct custody.
|
||||
- The partner must be comfortable supporting an employer-operated payout workflow and employee verification.
|
||||
|
||||
2. **Employer and worker onboarding**
|
||||
- Employer KYB, worker KYC, sanctions/AML controls, and operational monitoring need to be workable from day one.
|
||||
|
||||
3. **API-first payout operations**
|
||||
- We need APIs and webhooks that can support:
|
||||
- commission ledger updates
|
||||
- balance state changes
|
||||
- payout creation
|
||||
- payout status tracking
|
||||
- reversals or manual adjustments where allowed
|
||||
|
||||
4. **Bank-based payout support**
|
||||
- Switzerland should be approached conservatively.
|
||||
- We should not assume Brazil-style always-on bank-agnostic instant payouts from day one.
|
||||
- A strong Swiss launch may still be compelling if payouts are fast, auditable, and predictable.
|
||||
|
||||
5. **Support for internal controls**
|
||||
- Employer approval rules
|
||||
- payout thresholds
|
||||
- holdbacks and reserves
|
||||
- audit trails
|
||||
- separation of employer funds and employee-visible balances
|
||||
|
||||
### Important, but can come later
|
||||
|
||||
1. **Stored balance behavior**
|
||||
2. **Debit/prepaid card issuance**
|
||||
3. **Wallet or limited-acceptance spend controls**
|
||||
4. **Richer employer analytics and benchmark reporting**
|
||||
|
||||
### Not worth over-optimizing for yet
|
||||
|
||||
1. credit products
|
||||
2. consumer-neobank positioning
|
||||
3. standalone card programs without a solid payout and ledger core
|
||||
|
||||
---
|
||||
|
||||
## Switzerland market reality for partner selection
|
||||
|
||||
Compared with Brazil, Switzerland appears to have a narrower pool of obvious end-to-end fintech infrastructure partners for this use case.
|
||||
|
||||
That matters because it changes how we should think about the stack.
|
||||
|
||||
### What seems most likely
|
||||
|
||||
- the launch partner will probably be a **bank-led BaaS provider**, not just a fintech API layer
|
||||
- open-finance connectivity may sit in a **separate layer** from custody and payout execution
|
||||
- the card program may also sit in a **separate layer** from the initial payout product
|
||||
|
||||
### What that implies for us
|
||||
|
||||
The cleanest Swiss setup is likely one of these:
|
||||
|
||||
1. **Single regulated-bank launch**
|
||||
- one partner covers onboarding, accounts, payouts, and possibly cards later
|
||||
|
||||
2. **Bank + card specialist**
|
||||
- one bank-led partner for custody and payouts
|
||||
- one card-led partner later for employee spend and retention
|
||||
|
||||
3. **Bank + open-finance or orchestration layer**
|
||||
- one bank-led partner for regulated money movement
|
||||
- one enabling layer for bank connectivity, payment initiation, or multi-provider orchestration
|
||||
|
||||
---
|
||||
|
||||
## Evaluation criteria
|
||||
|
||||
We should judge Swiss partners against the same decision framework, not just brand familiarity.
|
||||
|
||||
| Criterion | Why it matters for us |
|
||||
| --- | --- |
|
||||
| Regulatory standing | We want a licensed-partner structure rather than direct custody |
|
||||
| Account and payout support | The launch wedge depends on controlled disbursement, not just payment acceptance |
|
||||
| API maturity | We need a programmable workflow, not manual ops hidden behind a sales deck |
|
||||
| Onboarding and compliance tooling | Employer KYB and worker KYC can become the real bottleneck |
|
||||
| Card readiness | Important later, but not the deciding factor for v1 |
|
||||
| Fit with commission workflow | The partner must support approvals, reversals, reserves, and traceability |
|
||||
| Time-to-market risk | Small teams need partners that can actually get a pilot live |
|
||||
|
||||
---
|
||||
|
||||
## Layered partner map
|
||||
|
||||
| Infrastructure layer | Stronger current options | Alternative / adjacency options | How to think about it |
|
||||
| --- | --- | --- | --- |
|
||||
| Regulated account + payout core | **HBL**, **Yapeal**, **InCore Bank** | Swissquote | This is the real Swiss launch decision layer |
|
||||
| Connectivity + payment submission | **SIX b.Link**, **Swisscom** | Swissquote | Useful if employers bank elsewhere and we need external-bank workflows |
|
||||
| Embedded-banking orchestration | **additiv**, Swisscom | SIX | Useful if we combine multiple providers rather than relying on one bank stack |
|
||||
| Employee card / spend layer | **Yapeal**, HBL | additiv + issuer setup | Important later, not first |
|
||||
| Global payments adjacency | Nuvei | Swissquote | More relevant for later expansion than launch |
|
||||
|
||||
---
|
||||
|
||||
## Public-evidence scorecards
|
||||
|
||||
**Legend:** `High` = strong fit from reviewed official materials, `Medium` = partial fit or important gaps still unclear, `Low` = weak public evidence for this use case.
|
||||
|
||||
### Regulated account and payout layer
|
||||
|
||||
| Partner | Regulatory anchor | Employer / worker onboarding fit | Account / payout fit | API / programmability | Card path | Current priority |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| **HBL** | High | High | High | High | Medium | **Priority 1** |
|
||||
| **Yapeal** | Medium | Medium | Medium | Medium | High | **Priority 1/2** |
|
||||
| **InCore Bank** | High | Medium | Medium | Low | Low | **Priority 2** |
|
||||
| **Swissquote** | Medium | Medium | Low-Medium | Low | Low | Watchlist |
|
||||
|
||||
### Connectivity and orchestration layer
|
||||
|
||||
| Partner | Bank connectivity | Payment submission / workflow | Orchestration depth | Embedded-finance fit | Current priority |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| **SIX b.Link** | High | High | Medium | Medium | **Priority 2** |
|
||||
| **Swisscom** | High | Medium | High | Medium | **Priority 2** |
|
||||
| **additiv** | Medium | Medium | High | High | **Priority 2** |
|
||||
| **Swissquote** | Low-Medium | Low-Medium | Low | Low-Medium | Watchlist |
|
||||
|
||||
### Card and employee spend layer
|
||||
|
||||
| Partner | Issuing evidence | Workforce / employee use-case fit | Spend-control fit | Need for extra regulated layer | Current priority |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| **Yapeal** | High | High | High | Medium | **Priority 1/2** |
|
||||
| **HBL** | Medium | Medium | Medium | Low | **Priority 2** |
|
||||
| **additiv + issuer setup** | Medium | Medium | Medium | High | Watchlist |
|
||||
|
||||
---
|
||||
|
||||
## Shortlist at a glance
|
||||
|
||||
| Partner | Type | Strongest role in our stack | Public-evidence launch fit | Public-evidence later fit | Overall priority |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| **HBL Solutions / Hypothekarbank Lenzburg** | Regulated bank-backed BaaS | Regulated Swiss banking and payout core | **High** | High | **Priority 1** |
|
||||
| **Yapeal Embedded** | Embedded finance / cards-as-a-service | Card layer and alternative regulated-partner path | Medium | **High** | **Priority 1/2** |
|
||||
| **InCore Bank** | Swiss B2B transaction bank | Alternative regulated bank-led core | Medium | Low-Medium | Priority 2 |
|
||||
| **SIX b.Link** | Open-finance infrastructure | Bank connectivity and payment submission | Medium-Low | Medium | Priority 2 |
|
||||
| **Swisscom** | Open-finance / managed banking integration | Middleware and ecosystem integration | Medium-Low | Medium | Priority 2 |
|
||||
| **additiv** | Finance-as-a-service orchestration platform | Orchestration layer across regulated providers | Low as standalone regulated core | Medium | Priority 2 |
|
||||
| **Swissquote** | Corporate / institutional banking and treasury | Treasury, banking, and institutional adjacency | Low-Medium | Low-Medium | Watchlist |
|
||||
| **Nuvei** | Payments and payout infrastructure | Global payments adjacency | Low | Medium | Watchlist |
|
||||
|
||||
---
|
||||
|
||||
## Detailed partner assessments
|
||||
|
||||
## 1. HBL Solutions / Hypothekarbank Lenzburg
|
||||
|
||||
### What it is
|
||||
|
||||
HBL Solutions is the BaaS and embedded-finance offering backed by **Hypothekarbank Lenzburg AG**.
|
||||
|
||||
Its official materials are the clearest Swiss evidence we found of a bank-led partner that could support a regulated commission payout product.
|
||||
|
||||
### What the official materials clearly show
|
||||
|
||||
HBL states that:
|
||||
|
||||
- it is backed by Hypothekarbank Lenzburg as a **regulated Swiss bank**
|
||||
- it provides access to its **banking license** for partner products
|
||||
- it has an onboarding tool with **over 160,000 account openings**
|
||||
- its REST API has **more than 200 endpoints**
|
||||
- it supports areas including **customer onboarding, cards, accounts, payments, and pensions**
|
||||
- it offers a **sandbox** for testing
|
||||
- partner funds can be available **within seconds** when payments move inside the HBL setup, while transfers to third-party banks may take longer
|
||||
|
||||
### Why it fits our thesis
|
||||
|
||||
This is very close to what we need for Switzerland:
|
||||
|
||||
- a regulated institution that can sit behind the initial product
|
||||
- programmable banking features, not just consulting
|
||||
- onboarding and compliance already built into the stack
|
||||
- account and payment primitives that look adaptable to our commission ledger workflow
|
||||
|
||||
It also aligns with the conservative Swiss positioning in `docs/countries/switzerland.md`:
|
||||
|
||||
- employer control
|
||||
- auditability
|
||||
- bank-based payouts
|
||||
- no need to lead with consumer credit or wallet hype
|
||||
|
||||
### Best role in our stack
|
||||
|
||||
**Primary launch partner** for:
|
||||
|
||||
- regulated account structure
|
||||
- employer and worker onboarding
|
||||
- payout execution
|
||||
- account and transaction data
|
||||
- support for later card expansion if the commercial model works
|
||||
|
||||
### What we still need to validate
|
||||
|
||||
1. Can HBL support a structure where we maintain our own internal commission ledger while they maintain the regulated money layer?
|
||||
2. Can they support **employer master account + worker-level views or sub-accounts**, or do they expect a different account model?
|
||||
3. What does worker KYC look like in a B2B2C employer-sponsored flow?
|
||||
4. Can payout approvals, holdbacks, and reserve logic be implemented cleanly?
|
||||
5. Are payout timelines acceptable when moving to **third-party Swiss banks**?
|
||||
6. What card setup is actually available for a later employee card program?
|
||||
7. What are the commercial minimums, implementation time, and support model?
|
||||
|
||||
### Assessment
|
||||
|
||||
**Strongest Swiss first-call candidate.**
|
||||
|
||||
If we were prioritizing outreach today, HBL would be the obvious first meeting.
|
||||
|
||||
---
|
||||
|
||||
## 2. Yapeal Embedded
|
||||
|
||||
### What it is
|
||||
|
||||
Yapeal positions itself around embedded finance and cards-as-a-service in Switzerland.
|
||||
|
||||
Its public materials are especially interesting because they are not framed only around generic consumer banking. They point to specific embedded use cases.
|
||||
|
||||
### What the official materials clearly show
|
||||
|
||||
Public Yapeal materials indicate:
|
||||
|
||||
- it offers **Cards-as-a-Service** for banks and fintech companies
|
||||
- it offers **embedded finance for digital platforms**
|
||||
- it highlights branded cards and **limited-acceptance cards**
|
||||
- it explicitly mentions use cases such as **employee benefits**, **mobility**, and targeted spending categories
|
||||
- one public testimonial references the ability to provide **employee credit cards** quickly and easily
|
||||
|
||||
### Why it fits our thesis
|
||||
|
||||
Yapeal maps especially well to our **later roadmap**:
|
||||
|
||||
- employee card access to stored balances
|
||||
- employer-controlled spend programs
|
||||
- targeted or limited-use card products
|
||||
- retention and platform utility beyond bank payouts alone
|
||||
|
||||
That makes it relevant even if it is not the first partner we sign.
|
||||
|
||||
### Best role in our stack
|
||||
|
||||
**Phase 2 or phase 3 partner** for:
|
||||
|
||||
- prepaid/debit/card-led access to balances
|
||||
- employee spend controls
|
||||
- employer-branded or platform-branded card programs
|
||||
- specialized spend use cases tied to commissions, benefits, or mobility
|
||||
|
||||
### Main uncertainty
|
||||
|
||||
The accessible public materials are clearer on the **card proposition** than on the full **banking and payout proposition**.
|
||||
|
||||
We still need to know:
|
||||
|
||||
1. whether Yapeal can be the main regulated partner for employer-funded payout flows
|
||||
2. whether it supports the account architecture we need for commission balances
|
||||
3. whether it is best used as a standalone partner or as a specialist card layer on top of a bank-led core
|
||||
4. whether payout and reconciliation tooling is as strong as its embedded card story
|
||||
|
||||
### Assessment
|
||||
|
||||
**Most interesting Swiss card-led option, but not yet the default primary launch partner.**
|
||||
|
||||
If cards remain intentionally later, Yapeal should be a second-wave diligence item rather than the very first dependency.
|
||||
|
||||
---
|
||||
|
||||
## 3. SIX b.Link
|
||||
|
||||
### What it is
|
||||
|
||||
SIX b.Link is open-finance infrastructure for the Swiss market.
|
||||
|
||||
It matters because our product will eventually need reliable access to account information and payment submission workflows, especially if employers keep their main operating accounts at different banks.
|
||||
|
||||
### What the official materials clearly show
|
||||
|
||||
SIX describes b.Link as:
|
||||
|
||||
- the Swiss open-banking platform connecting **banks and fintechs** through standardized APIs
|
||||
- a platform that supports **payment submission** from third-party applications into customer e-banking
|
||||
- a way to retrieve payment status and connect related services such as **account information**
|
||||
- an implementation of common Swiss API standards
|
||||
|
||||
### Why it matters to us
|
||||
|
||||
This is useful for two parts of our product:
|
||||
|
||||
1. **Reconciliation and visibility**
|
||||
- We may want account data from employer bank accounts for commission creation and payout confirmation.
|
||||
|
||||
2. **Payment initiation / submission**
|
||||
- We may want to let employers approve or submit payouts from within our workflow rather than leaving the platform.
|
||||
|
||||
### Where it does not fit well
|
||||
|
||||
b.Link does **not** look like the primary answer for:
|
||||
|
||||
- regulated custody
|
||||
- employer and worker onboarding
|
||||
- issuing employee cards
|
||||
- running the full B2B2C payout stack on its own
|
||||
|
||||
### Best role in our stack
|
||||
|
||||
**Open-finance connectivity layer** if we later need:
|
||||
|
||||
- multi-bank employer account connectivity
|
||||
- account information feeds
|
||||
- payment submission flows into external bank channels
|
||||
|
||||
### Assessment
|
||||
|
||||
**Important ecosystem layer, not the primary launch bank.**
|
||||
|
||||
We should understand it, but probably not make it the first integration unless bank-data fragmentation becomes central to the pilot.
|
||||
|
||||
---
|
||||
|
||||
## 4. Swisscom
|
||||
|
||||
### What it is
|
||||
|
||||
Swisscom appears to operate at the infrastructure and managed-services layer of Swiss open finance.
|
||||
|
||||
### What the official materials clearly show
|
||||
|
||||
Swisscom describes:
|
||||
|
||||
- an **Open Business Hub** as a central access point to API ecosystems for financial services
|
||||
- several hundred interfaces and support for standards such as **Common API** and **OpenWealth API**
|
||||
- a **Managed Finance Ecosystem** that can support banking operations and connect third-party solutions
|
||||
- a SaaS-style operating model intended to reduce integration and maintenance burden
|
||||
|
||||
### Why it matters to us
|
||||
|
||||
Swisscom may become relevant if our Swiss stack needs:
|
||||
|
||||
- middleware between multiple banking and data systems
|
||||
- standardized ecosystem integration
|
||||
- managed banking infrastructure around a partner bank setup
|
||||
- enterprise-grade interface management
|
||||
|
||||
### Main concern
|
||||
|
||||
Swisscom looks more like a **banking-enablement and integration layer** than the clean regulated partner we want for an early wedge product.
|
||||
|
||||
For an early-stage company, there is a real risk that this becomes too broad or too enterprise-heavy before we have proved the core workflow.
|
||||
|
||||
### Best role in our stack
|
||||
|
||||
**Secondary infrastructure layer** if we later need more complex bank and ecosystem integration.
|
||||
|
||||
### Assessment
|
||||
|
||||
Useful to understand, but probably **not a first-priority launch dependency**.
|
||||
|
||||
---
|
||||
|
||||
## 5. Nuvei
|
||||
|
||||
### What it is
|
||||
|
||||
Nuvei appears more naturally as a payments and payout infrastructure partner than as the core Swiss BaaS provider.
|
||||
|
||||
The search evidence we reviewed points to Swiss support for:
|
||||
|
||||
- CHF
|
||||
- pay-ins
|
||||
- payouts
|
||||
- refunds
|
||||
- recurring payments
|
||||
- chargeback handling
|
||||
|
||||
### Where it may help
|
||||
|
||||
Nuvei could matter if we later need:
|
||||
|
||||
- merchant payment acceptance alongside payout operations
|
||||
- broader multi-country payment orchestration
|
||||
- payout rails beyond a purely Swiss bank-led setup
|
||||
- issuing adjacency at a global level
|
||||
|
||||
### Why it is not the lead Swiss recommendation
|
||||
|
||||
For our current thesis, Nuvei looks less directly aligned with:
|
||||
|
||||
- employer/worker onboarding
|
||||
- the regulated-account layer
|
||||
- B2B2C commission ledger integration
|
||||
- a Swiss employer workflow product anchored around a local bank partner
|
||||
|
||||
### Assessment
|
||||
|
||||
**Watchlist / adjacent partner**, not the top Swiss launch candidate.
|
||||
|
||||
---
|
||||
|
||||
## Additional Swiss alternatives to diligence
|
||||
|
||||
### InCore Bank
|
||||
|
||||
What the reviewed public materials clearly show:
|
||||
|
||||
- InCore describes itself as a **Swiss B2B transaction bank** for banks, financial intermediaries, and companies
|
||||
- it emphasizes **banking and technology from one hand**
|
||||
- its positioning is clearly B2B and infrastructure-oriented rather than consumer-led
|
||||
|
||||
Why it matters:
|
||||
|
||||
- it is a credible **alternative regulated bank-led core** for a Swiss launch
|
||||
- it looks particularly relevant if we want a more transaction-bank profile and are comfortable doing more diligence on product specifics
|
||||
|
||||
Main gap versus HBL:
|
||||
|
||||
- the public materials we reviewed are much less explicit on embedded-finance APIs, onboarding tooling, sandbox access, and employer/worker payout flows
|
||||
|
||||
### additiv
|
||||
|
||||
What the reviewed public materials clearly show:
|
||||
|
||||
- additiv positions `addBanking` as a platform that can orchestrate **onboarding, accounts, payments, and compliance**
|
||||
- it supports **white-label, managed-service, and embedded** operating models
|
||||
- it can source services through an **open ecosystem of regulated providers** rather than replacing the underlying regulated stack
|
||||
|
||||
Why it matters:
|
||||
|
||||
- additiv is a serious **orchestration-layer alternative** if we want flexibility across banks or providers
|
||||
- it is particularly relevant if the Swiss stack becomes multi-provider rather than single-bank
|
||||
|
||||
Main gap versus HBL / Yapeal:
|
||||
|
||||
- additiv is not itself the obvious regulated balance holder for launch, so it should be paired with a bank or issuer rather than treated as the sole Swiss launch partner
|
||||
|
||||
### Swissquote
|
||||
|
||||
What the reviewed public materials clearly show:
|
||||
|
||||
- Swissquote offers **multi-currency business accounts**, transfers, treasury tools, and institutional partner services
|
||||
- its institutional materials describe **segregated client and corporate accounts**, reporting, and institutional infrastructure
|
||||
|
||||
Why it matters:
|
||||
|
||||
- Swissquote could matter as a **treasury and banking adjacency** for employer-side banking, multi-currency handling, or institutional partnership discussions
|
||||
|
||||
Main gap for our use case:
|
||||
|
||||
- public evidence for an employer-funded, worker-beneficiary commission payout stack is weaker than for HBL and less card-specific than Yapeal
|
||||
|
||||
---
|
||||
|
||||
## Recommended stack options for Switzerland
|
||||
|
||||
## Option A: regulated-bank comparison wave
|
||||
|
||||
**HBL or Yapeal or InCore**
|
||||
|
||||
Use the first diligence wave to choose the regulated Swiss core after comparing:
|
||||
|
||||
- account model
|
||||
- worker onboarding model
|
||||
- payout speed to external bank accounts
|
||||
- reserve and holdback support
|
||||
- card optionality
|
||||
|
||||
### Why this is attractive
|
||||
|
||||
- avoids premature lock-in to one Swiss bank stack
|
||||
- reflects the reality that Switzerland has a small but meaningful comparison set
|
||||
- gives us a cleaner basis for commercial negotiation
|
||||
|
||||
### Main risk
|
||||
|
||||
- takes slightly longer than assuming one default winner from the start
|
||||
|
||||
---
|
||||
|
||||
## Option B: bank-led launch, card-led expansion
|
||||
|
||||
**HBL or InCore + Yapeal**
|
||||
|
||||
- HBL or InCore for regulated banking and payout operations
|
||||
- Yapeal later for cards, spend controls, or employee retention products
|
||||
|
||||
### Why this is attractive
|
||||
|
||||
- preserves the conservative bank-led launch
|
||||
- keeps optionality for a stronger employee card experience later
|
||||
- reduces pressure to force cards into v1
|
||||
|
||||
### Main risk
|
||||
|
||||
- multi-vendor coordination
|
||||
- overlap and responsibility boundaries need early clarification
|
||||
|
||||
---
|
||||
|
||||
## Option C: bank core plus connectivity or orchestration layer
|
||||
|
||||
**HBL or InCore + SIX or Swisscom or additiv**
|
||||
|
||||
- one bank-led partner for regulated money movement
|
||||
- one enabling layer for bank connectivity, payment submission, or multi-provider orchestration
|
||||
|
||||
### Why this is attractive
|
||||
|
||||
- useful if employers keep their main accounts at multiple Swiss banks
|
||||
- useful if reconciliation and treasury visibility across banks becomes a pilot requirement
|
||||
|
||||
### Main risk
|
||||
|
||||
- probably too much complexity for the very first pilot unless bank fragmentation is already a real blocker
|
||||
|
||||
---
|
||||
|
||||
## Recommended outreach order
|
||||
|
||||
### Priority 1: regulated-layer comparison
|
||||
|
||||
- **HBL Solutions / Hypothekarbank Lenzburg**
|
||||
- **Yapeal Embedded**
|
||||
- **InCore Bank**
|
||||
|
||||
Goal of first calls:
|
||||
|
||||
- compare regulated account structures
|
||||
- compare payout mechanics and payout timing
|
||||
- compare B2B2C onboarding assumptions
|
||||
- understand card optionality, implementation timelines, and minimums
|
||||
|
||||
### Priority 2: enabling layers
|
||||
|
||||
- **SIX b.Link**
|
||||
- **Swisscom**
|
||||
- **additiv**
|
||||
|
||||
Goal of first calls:
|
||||
|
||||
- decide whether a connectivity or orchestration layer is needed before the pilot or only later
|
||||
- identify whether external-bank account information and payment submission are likely blockers
|
||||
|
||||
### Watchlist
|
||||
|
||||
- **Swissquote**
|
||||
- **Nuvei**
|
||||
|
||||
Goal:
|
||||
|
||||
- keep institutional banking, treasury, and global payments adjacencies warm without making them first-wave dependencies
|
||||
|
||||
---
|
||||
|
||||
## Questions to ask every Swiss partner
|
||||
|
||||
1. Can you support an **employer-funded** payout product where employees are beneficiaries but not the buyer?
|
||||
2. What account models do you support: pooled account, named individual accounts, virtual sub-accounts, or another structure?
|
||||
3. Can we maintain our own commission ledger while using your regulated money-movement layer?
|
||||
4. What worker KYC level is required before a user can receive payouts?
|
||||
5. Can payouts be sent to an external Swiss bank account or IBAN controlled by the worker?
|
||||
6. What are the expected settlement speeds for same-bank and third-party-bank payouts?
|
||||
7. How are reversals, disputes, freezes, and suspicious-activity reviews handled?
|
||||
8. Can employer approval workflows, reserve rules, and payout limits be encoded in the API workflow?
|
||||
9. What webhooks, event streams, reconciliation exports, and reporting tools are available?
|
||||
10. What are the commercial minimums, onboarding timelines, and implementation support model?
|
||||
11. If we later add cards, can you support prepaid/debit issuance and wallet tokenization?
|
||||
12. What data residency and operational support commitments do you provide?
|
||||
|
||||
---
|
||||
|
||||
## What a good Swiss partner outcome looks like
|
||||
|
||||
A strong Swiss partner decision should let us build this sequence:
|
||||
|
||||
1. validate payment or invoice event
|
||||
2. create commission entry in our own ledger
|
||||
3. mark a portion as available under employer policy
|
||||
4. trigger payout through a regulated partner
|
||||
5. give the employer and worker a clear audit trail
|
||||
6. add stored-balance or card behavior only after the payout workflow is working reliably
|
||||
|
||||
If a partner is strong on cards but weak on the above sequence, it is not the right first partner.
|
||||
|
||||
---
|
||||
|
||||
## Recommended next steps
|
||||
|
||||
### Commercial
|
||||
|
||||
- Open conversations with **HBL, Yapeal, and InCore** in the first wave.
|
||||
- Run a second architecture wave with **SIX, Swisscom, and additiv** only if design partners need multi-bank connectivity or orchestration.
|
||||
- Prepare a short partner memo describing:
|
||||
- employer buyer
|
||||
- worker beneficiary
|
||||
- payout-to-bank first model
|
||||
- later optional card layer
|
||||
- no direct custody at launch
|
||||
|
||||
### Product and technical
|
||||
|
||||
Create a partner diligence worksheet covering:
|
||||
|
||||
- account model
|
||||
- KYC/KYB flow
|
||||
- payout methods and timing
|
||||
- webhook/event coverage
|
||||
- reversal and holdback support
|
||||
- reporting and reconciliation
|
||||
- card optionality
|
||||
- sandbox quality
|
||||
- pricing and minimums
|
||||
|
||||
### Legal and compliance
|
||||
|
||||
Map with counsel:
|
||||
|
||||
- which party is merchant/employer/platform in the flow
|
||||
- whether employee balances are treated as claims, stored value, or simple payout instructions under the chosen structure
|
||||
- who owns AML monitoring, suspicious-activity handling, and customer support obligations
|
||||
|
||||
---
|
||||
|
||||
## Evidence reviewed
|
||||
|
||||
### Official and primary materials
|
||||
|
||||
- HBL Solutions Banking-as-a-Service: https://www.hblsolutions.ch/en/
|
||||
- Yapeal embedded finance for digital platforms: https://yapeal.ch/en/yapeal-embedded/solutions/embedded-finance-for-digital-platforms/
|
||||
- Yapeal cards-as-a-service: https://yapeal.ch/en/yapeal-embedded/solutions/cards-as-a-service-for-banks/
|
||||
- Yapeal homepage / client examples: https://yapeal.ch/en/
|
||||
- InCore Bank: https://www.incorebank.ch/en/
|
||||
- SIX b.Link payment submission: https://blink.six-group.com/en/services/payment-submission
|
||||
- SIX b.Link docs: https://docs.blink.six-group.com/docs/whats-blink/
|
||||
- Swisscom Open Business Hub: https://www.swisscom.ch/en/business/enterprise/offer/banking/open-finance-ecosystem/open-business-hub.html
|
||||
- Swisscom Managed Finance Ecosystem: https://www.swisscom.ch/en/business/enterprise/offer/banking/managed-finance-ecosystem.html
|
||||
- additiv addBanking: https://www.additiv.com/addbanking
|
||||
- additiv platform: https://www.additiv.com/platform/
|
||||
- Swissquote companies: https://www.swissquote.com/en/institutional/clients/companies
|
||||
- Swissquote banks / institutional partners: https://www.swissquote.com/en/institutional/clients/banks
|
||||
|
||||
### Supporting source used for adjacency only
|
||||
|
||||
- Nuvei Swiss payments overview: https://www.nuvei.com/apm/swiss-payments
|
||||
|
||||
---
|
||||
|
||||
## Bottom line
|
||||
|
||||
For Switzerland, we should optimize for **regulated bank-backed execution first**, but without forcing the infrastructure map into one obvious company per role.
|
||||
|
||||
That means the current recommendation is:
|
||||
|
||||
- **Run first-wave diligence across HBL, Yapeal, and InCore for the regulated layer**
|
||||
- **Treat SIX, Swisscom, and additiv as optional enabling layers rather than default launch dependencies**
|
||||
- **Keep Swissquote and Nuvei as adjacency watchlist names**
|
||||
- **Avoid designing the Swiss launch around cards before the payout workflow is proven**
|
||||
167
docs/countries/switzerland.md
Normal file
167
docs/countries/switzerland.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# Switzerland market note
|
||||
|
||||
## Summary
|
||||
|
||||
Switzerland is a plausible country dossier for this idea if the company wants to test the product in a high-trust, compliance-heavy market with commission-driven employers.
|
||||
|
||||
The product thesis stays the same:
|
||||
|
||||
`turn each validated sale into an auditable commission balance, then let employers decide how quickly the eligible portion can be paid out`
|
||||
|
||||
The initial product should not be sold as a bank account or a consumer credit product. The stronger thesis is commission infrastructure with fast, controlled payouts and strong employer auditability.
|
||||
|
||||
## Why Switzerland matters
|
||||
|
||||
- Employers often have high expectations around accuracy, auditability, and operational reliability.
|
||||
- Commission-heavy teams exist across insurance, brokerage, recruiting, financial advisory, property-related sales, medical services, and B2B sales organizations.
|
||||
- A strong employer workflow product can matter even if the worker-liquidity wedge is less dramatic than in markets with a stronger informal-advance culture.
|
||||
- The market can test whether the thesis works in a more compliance-intensive environment.
|
||||
- A premium operating product may resonate with Swiss SMB and mid-market buyers if it reduces errors and admin load.
|
||||
|
||||
## Local pain that the product solves
|
||||
|
||||
### For the employer
|
||||
|
||||
- Commission rules often live across spreadsheets, CRM exports, accounting workflows, and payroll handoffs.
|
||||
- Month-end reconciliation is slow and error-prone.
|
||||
- Finance teams lack a live view of commission liability and pending adjustments.
|
||||
- Disputes are harder to resolve when calculation logic and payout history are fragmented.
|
||||
|
||||
### For the employee
|
||||
|
||||
- Commission visibility often arrives late.
|
||||
- There is limited transparency around what has been earned, what is available, and what is still pending.
|
||||
- Payout timing can feel opaque even when the employer intends to pay fairly.
|
||||
- Faster access to eligible balances may improve trust, even when immediate liquidity is not the only pain point.
|
||||
|
||||
## Initial ICP
|
||||
|
||||
The best initial targets are Swiss SMB and mid-market employers with commission-heavy teams and clearly attributable payment or invoice events.
|
||||
|
||||
Promising segments:
|
||||
|
||||
- insurance brokerages and advisory networks
|
||||
- staffing and recruiting firms
|
||||
- property-related sales organizations
|
||||
- clinics, medical services, or elective-care businesses with trackable payment events
|
||||
- subscription and field-sales businesses with clear seller attribution
|
||||
|
||||
## Value proposition in Switzerland
|
||||
|
||||
### For the employer
|
||||
|
||||
- automate commission calculation and payout operations
|
||||
- reduce spreadsheet dependence and manual reconciliation
|
||||
- create a clear audit trail across sales, commissions, payouts, and adjustments
|
||||
- improve visibility into commission liability and team performance
|
||||
- reduce payout disputes and exception handling
|
||||
|
||||
### For the employee
|
||||
|
||||
- see earned commissions sooner
|
||||
- understand what is available versus still pending
|
||||
- receive eligible payouts faster through the linked bank destination
|
||||
- track earnings history and payout activity in one place
|
||||
|
||||
## Recommended product for Switzerland
|
||||
|
||||
### V1
|
||||
|
||||
- payment reconciliation through local PSP, banking, or invoice data
|
||||
- commission rules engine
|
||||
- ledger with states `earned`, `available`, and `settled`
|
||||
- balances for employee and employer
|
||||
- payout request workflow to linked bank destination
|
||||
- basic employer and employee dashboards
|
||||
- audit trail by payment event, commission result, payout, and adjustment
|
||||
|
||||
### V2
|
||||
|
||||
- clearer reserve and holdback rules for reversals
|
||||
- analytics for team performance and commission liability
|
||||
- alerts and anomaly reporting
|
||||
- stored balance behavior if partner structure and economics justify it
|
||||
- pilot of employer-backed advances only after the ledger is reliable
|
||||
|
||||
### V3
|
||||
|
||||
- card or spend product only if local partner economics justify it
|
||||
- deeper ERP, CRM, POS, or payroll integrations
|
||||
- multi-entity support for larger organizations
|
||||
|
||||
## Partners that matter locally
|
||||
|
||||
### Financial infrastructure
|
||||
|
||||
- regulated bank, BaaS, or payment partner for safeguarded funds, payouts, and compliance
|
||||
- payout partner that can support employer and worker money movement without forcing direct custody at launch
|
||||
|
||||
### Payment and reconciliation infrastructure
|
||||
|
||||
- PSPs, acquirers, billing tools, or invoice-reconciliation partners that can provide reliable payment-event data
|
||||
|
||||
### Identity and compliance
|
||||
|
||||
- KYC, KYB, AML, and sanctions tooling for employer and employee onboarding
|
||||
- legal and compliance advisors with Swiss financial-regulation and labor-workflow experience
|
||||
|
||||
### Card issuance
|
||||
|
||||
- only later, if the product proves balance retention is worth pursuing
|
||||
|
||||
## Regulatory and operating considerations
|
||||
|
||||
The product touches several regulated and operational areas and should be mapped carefully.
|
||||
|
||||
- start under a licensed partner structure rather than direct custody
|
||||
- map the FINMA-related regulatory perimeter and partner responsibilities early
|
||||
- understand employer onboarding, AML, and worker verification requirements
|
||||
- map how commissions, deductions, payroll timing, and adjustments should be reflected in employer workflows
|
||||
- make availability, reversals, and clawback logic explicit to employers and employees
|
||||
- keep employer-backed advances as a later feature, not the initial wedge
|
||||
|
||||
## Go-to-market in Switzerland
|
||||
|
||||
### First move
|
||||
|
||||
- win 3 to 5 design partners with strong commission admin pain and clean payment attribution
|
||||
- prioritize employers where commission rules are painful but not too custom to support in v1
|
||||
- sell to finance, operations, founders, and sales leadership
|
||||
|
||||
### Distribution channels
|
||||
|
||||
- direct sales to design partners
|
||||
- referrals from accounting, payroll, or finance consultants
|
||||
- vertical SaaS and payment-partner relationships
|
||||
- operator networks or industry groups where commission plans are common
|
||||
|
||||
### Initial pitch
|
||||
|
||||
- remove spreadsheet commission work
|
||||
- improve auditability and payout reliability
|
||||
- give teams clearer and faster access to eligible earnings
|
||||
- reduce payout disputes and manual exception handling
|
||||
|
||||
## Most likely economic model
|
||||
|
||||
- employer platform fee
|
||||
- fee per processed or reconciled payment event
|
||||
- payout fee or bundled payout plan
|
||||
- premium analytics tier for larger employers
|
||||
- later card or retained-balance economics if the partner model supports them
|
||||
|
||||
## Key risks in Switzerland
|
||||
|
||||
- smaller domestic market than some larger launch geographies
|
||||
- stronger compliance expectations can slow onboarding and iteration
|
||||
- local labor and payroll expectations may require careful configuration
|
||||
- payout speed expectations may vary by partner and bank behavior
|
||||
- employer demand for worker-liquidity features may be weaker than in markets with more visible advance behavior
|
||||
|
||||
## Final thesis for Switzerland
|
||||
|
||||
The best positioning is not a neobank and not an employee-wallet-first app.
|
||||
|
||||
The best positioning is:
|
||||
|
||||
`commission operations infrastructure for Swiss employers, with auditable ledgers, bank-based payouts, and strong employer control`
|
||||
Reference in New Issue
Block a user