repo redirection

AGENTS.md

@@ -8,12 +8,13 @@ The startup thesis is a B2B2C fintech platform that processes or reconciles cust
 
 ## Current strategic thesis
 
-- Start in Brazil.
-- Lead with `Pix`-based instant access to earned commissions.
+- Keep the core product geography-agnostic.
 - Use a regulated financial partner for custody, payouts, card issuance, and compliance.
+- Lead with fast access to earned commissions over the relevant local payout rail.
 - Treat cards and stored balances as later retention tools, not the initial wedge.
 - Treat advances as a later employer-backed feature, not the first product.
 - Build employer analytics from payment-linked data.
+- Keep market-specific assumptions in `docs/countries/`.
 
 ## What this company is
 
@@ -36,21 +37,19 @@ The startup thesis is a B2B2C fintech platform that processes or reconciles cust
 ## Key documents
 
 - `docs/core-idea.md` - canonical summary of the product and business model
-- `docs/brazil-market.md` - Brazil-specific thesis and go-to-market notes in pt-BR
 - `docs/market-memo.md` - competitor map, differentiation, and investor-style memo
 - `docs/positioning-and-landing-copy.md` - messaging and homepage copy directions
 - `docs/year-one-roadmap.md` - phased roadmap for the first year
+- `docs/prototype-plan.md` - prototype scope, flows, and build sequence
 - `docs/ideas-for-review.md` - review file for ideas not yet integrated into the core docs
+- `docs/countries/brazil.md` - Brazil-specific thesis and go-to-market notes in pt-BR
+- `docs/countries/switzerland.md` - Switzerland-specific thesis and go-to-market notes
 
 ## Language conventions
 
 - Write in English by default.
-- Keep `docs/brazil-market.md` in pt-BR.
-- Keep fintech terminology consistent: `Pix`, `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`.
-
-## Transcripts
-
-- Transcripts of previous sessions are available under the sessions/ subdir, in case extra context is necessary.
+- Country-specific docs may use local language where helpful.
+- Keep fintech terminology consistent: `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`, `instant payout rail`.
 
 ## Product assumptions to preserve
 
@@ -59,6 +58,7 @@ The startup thesis is a B2B2C fintech platform that processes or reconciles cust
 - The payment event is the source of truth for commission creation whenever possible.
 - The employer buyer needs controls, auditability, and analytics, not just a payout rail.
 - The employee experience matters because faster access and later card usage can improve retention and platform utility.
+- Country-specific differences should be layered on top of the same core ledger and workflow model.
 
 ## Reference competitors and adjacent players
 
@@ -69,22 +69,21 @@ Use this current market framing unless new evidence clearly changes it:
 - `PayQuicker`
 - `Hyperwallet`
 - `CaptivateIQ`
-- `Caju`
-- `Dock`
 
-These companies validate parts of the stack, but the current thesis is that few combine payment-linked commissions, worker liquidity, employer controls, and Brazil-native rails into one product.
+Country-specific employer-finance apps, PSPs, BaaS providers, and issuers should be documented in the relevant country notes rather than the core docs.
 
 ## Prioritization guidance for future agents
 
-- Prioritize docs and plans that sharpen the Brazil-first wedge.
+- Prioritize docs and plans that sharpen the geography-agnostic core product.
+- Keep country-level launch assumptions, partners, and regulation in `docs/countries/`.
 - Keep the distinction between `earned access` and `credit` very clear.
 - Prefer practical operator language over generic fintech buzzwords.
 - If you extend product plans, sequence features conservatively: ledger and instant payouts first, analytics and stored balance second, cards third, employer-backed advances later.
 
 ## Open areas worth exploring later
 
-- deeper regulatory mapping for Brazil launch structure
-- partner comparison across BaaS, payment processors, and card issuers
+- deeper regulatory mapping for Brazil, Switzerland, and future launch structures
+- partner comparison across local banking, payment processing, and card issuance stacks
 - pricing design for employers versus workers
 - reserve rules for refunds, disputes, and chargebacks
 - target vertical selection and design-partner outreach strategy

README.md

@@ -1,28 +1,31 @@
-# Payroll Planning Workspace
+# Commission Infrastructure Planning Workspace
 
-Documentation-first workspace for a Brazil-first B2B2C fintech concept focused on payment-linked commissions, instant access to earned balances, and employer controls around payouts and analytics.
+Documentation-first workspace for a location-independent B2B2C fintech concept focused on payment-linked commissions, fast access to earned balances, and employer controls around payouts and analytics.
 
 ## Document index
 
 - `docs/core-idea.md` - canonical summary of the product, operating model, and money flow
-- `docs/brazil-market.md` - Brazil-specific thesis, local constraints, and go-to-market notes in pt-BR
 - `docs/market-memo.md` - market gap, competitor map, differentiation, and business model framing
 - `docs/positioning-and-landing-copy.md` - messaging directions, landing-page copy, and narrative structure
 - `docs/year-one-roadmap.md` - phased plan for the first year of product and partner execution
 - `docs/prototype-plan.md` - proposed scope, flows, architecture, and build sequence for a first product prototype
 - `docs/ideas-for-review.md` - ideas from external conversations that are not yet part of the core docs
+- `docs/countries/README.md` - index for country-specific market notes
+- `docs/countries/brazil.md` - Brazil-specific thesis, local constraints, and go-to-market notes in pt-BR
+- `docs/countries/switzerland.md` - Switzerland-specific thesis, local constraints, and go-to-market notes
 
 ## Suggested reading order
 
 - `docs/core-idea.md`
-- `docs/brazil-market.md`
 - `docs/market-memo.md`
 - `docs/positioning-and-landing-copy.md`
 - `docs/year-one-roadmap.md`
 - `docs/prototype-plan.md`
+- `docs/countries/README.md`
 
 ## Notes
 
-- Write in English by default; keep `docs/brazil-market.md` in pt-BR.
+- Write in English by default. Country-specific docs may use local language where helpful.
+- Keep fintech terminology consistent: `commission ledger`, `earned commission access`, `employer-backed advance`, `stored balance`.
+- Country-specific launch assumptions, partners, and regulatory notes belong in `docs/countries/`.
 - The repository currently holds strategy and planning documents, not production code.
-- Session transcripts live under `sessions/`.

docs/core-idea.md

@@ -53,7 +53,7 @@ The product sits between customer payment collection and employer payout.
 
 ### Instant access rails
 
-- Start with instant bank transfer or `Pix` cash-out.
+- Start with instant or fast bank-transfer cash-out on the relevant local rail.
 - Later add stored balance inside the app.
 - Later add a prepaid or debit card linked to the balance.
 
@@ -74,12 +74,12 @@ The safest early structure is partner-led custody.
 
 - A regulated bank or licensed financial partner holds funds.
 - The platform owns the application layer, commission logic, ledger, and payout orchestration.
-- Cards, `Pix`, KYC, and regulated money movement are handled through partners.
+- Cards, local payout rails, KYC, and regulated money movement are handled through partners.
 
 Example flow:
 
 ```text
-Customer pays R$1,000
+Customer pays 1,000 in local currency
         |
         v
 Partner-held account receives funds
@@ -87,8 +87,8 @@ Partner-held account receives funds
         v
 Commission engine calculates split
         |
-        +-- Employee commission: R$200
-        +-- Employer balance: R$800
+        +-- Employee commission: 200
+        +-- Employer balance: 800
         +-- Platform fee and reserve logic applied
         |
         v
@@ -189,9 +189,10 @@ The company is best understood as `commission infrastructure`.
 
 ## Current strategic recommendation
 
-- Start in Brazil.
-- Lead with `Pix`-based instant access to earned commissions.
+- Keep the core ledger, commission logic, and employer workflows geography-agnostic.
+- Choose launch markets based on payment-event traceability, employer pain, partner availability, and local payout rails.
 - Use partner-led custody and compliance.
+- Lead with fast access to earned commissions over the relevant local rail.
 - Treat stored balances and cards as retention tools, not the initial wedge.
 - Treat employer analytics as a second major value driver.
 - Delay true lending until the core ledger and payout engine are reliable.

docs/countries/README.md

@@ -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.

docs/countries/brazil-partners.md

@@ -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`

docs/countries/switzerland-partners.md

@@ -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**

docs/countries/switzerland.md

@@ -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`

docs/market-memo.md

@@ -2,13 +2,13 @@
 
 ## Thesis
 
-There is a clear product gap between commission software, faster worker payouts, and Brazil-native embedded finance.
+There is a clear product gap between commission software, faster worker payouts, and locally integrated money movement.
 
-Many companies solve one layer of the stack well. Very few appear to own the full loop from customer payment to commission calculation to worker access to funds. That creates an opening for a Brazil-first platform built around real-time commission availability.
+Many companies solve one layer of the stack well. Very few appear to own the full loop from customer payment to commission calculation to worker access to funds. That creates an opening for a location-independent platform built around real-time commission availability and localized country execution.
 
 ## The gap in the market
 
-Commission-heavy businesses still operate with delayed payroll cycles, spreadsheet-based commission workflows, and informal employee advances. Workers want faster access to earnings. Employers want control, auditability, and better visibility.
+Commission-heavy businesses still operate with delayed payroll cycles, spreadsheet-based commission workflows, and ad hoc employee advance requests. Workers want faster access to earnings. Employers want control, auditability, and better visibility.
 
 Existing vendors tend to split into separate categories:
 
@@ -16,21 +16,20 @@ Existing vendors tend to split into separate categories:
 - payout rails and disbursement infrastructure
 - commission calculation and analytics software
 - employee wallet or card experiences
-- Brazil payment and card infrastructure
+- local payment, banking, and compliance infrastructure
 
 The opportunity is to combine these into a single workflow built around a verified payment event.
 
 ## Competitor map
 
-| Company | What it does well | Missing piece relative to this idea |
+| Company or category | What it does well | Missing piece relative to this idea |
 |---|---|---|
 | `DailyPay` | Earned wage access, employee liquidity, employer integrations | Not centered on payment-linked commissions or commission-heavy teams |
 | `Branch` | Workforce payments, employee app, card, embedded finance | More generic worker finance than commission-specific infrastructure |
-| `PayQuicker` | Fast commission payouts, cards, payout portals | Weaker employer-side commission operating system and Brazil-specific positioning |
+| `PayQuicker` | Fast commission payouts, cards, payout portals | Weaker employer-side commission operating system |
 | `Hyperwallet` | Global payout orchestration | Infrastructure layer, not a commission system of record |
 | `CaptivateIQ` | Commission calculation, visibility, forecasting | No native money movement or worker access to balances |
-| `Caju` | Brazil employee finance and card experience | Not the source of truth for commission creation and payout logic |
-| `Dock` | Brazil financial infrastructure for accounts, cards, `Pix` | Not a direct competitor; more likely an enabling layer |
+| Local payment and BaaS partners | Country-specific rails, compliance coverage, and movement infrastructure | Usually not the employer-facing commission system of record |
 
 ## What is differentiated here
 
@@ -47,18 +46,6 @@ That positioning changes the product in important ways:
 - the employee gets liquidity without relying on informal advances
 - the company can monetize software, payment flow, and later retained balances
 
-## Why Brazil first
-
-Brazil is the more compelling launch market than Switzerland for this specific thesis.
-
-- `Pix` makes instant access behaviorally normal.
-- Informal paycheck advances or `vales` create a visible pain point.
-- Smaller financial institutions and infrastructure partners may be more open to collaboration.
-- Commission-heavy SMB and mid-market businesses are common.
-- The value proposition is concrete and easy to explain.
-
-Switzerland may still matter later, but Brazil provides the clearer wedge, larger behavioral advantage, and stronger infrastructure fit for instant commission access.
-
 ## Recommended wedge
 
 The initial product should avoid trying to become a broad payroll platform or a credit-led consumer app.
@@ -68,11 +55,36 @@ The recommended wedge is:
 - process or reconcile customer payments
 - calculate commissions in real time
 - make a safe portion of earned commissions available immediately
-- let workers cash out via `Pix`
+- let workers cash out over the relevant local payout rail
 - give employers dashboards, controls, and reporting
 
 This creates value for both sides without requiring the company to start as a full lending business.
 
+## Country strategy
+
+Country-specific launch assumptions should live in `docs/countries/`, not in the core product docs.
+
+The core product should stay constant across markets:
+
+- payment-linked commission creation
+- auditable ledger and balance states
+- employer controls and analytics
+- employee access to eligible balances
+- partner-led custody and regulated money movement
+
+The parts that should vary by country are:
+
+- payout rail and settlement behavior
+- partner stack
+- onboarding, KYC, and KYB workflow
+- regulatory and labor treatment
+- target verticals and go-to-market sequence
+
+Current country dossiers live in:
+
+- `docs/countries/brazil.md`
+- `docs/countries/switzerland.md`
+
 ## Differentiation versus adjacent players
 
 ### Versus `DailyPay` and `Branch`
@@ -89,11 +101,12 @@ This creates value for both sides without requiring the company to start as a fu
 ### Versus `PayQuicker` and `Hyperwallet`
 
 - own employer workflows and analytics, not just disbursement rails
-- focus on Brazil-native behavior and infrastructure
+- keep the employer-side commission ledger as the system of record
 
-### Versus `Caju`
+### Versus local infrastructure partners
 
-- own the commission event and payout logic, not only the employee finance interface
+- use them as enabling rails, not as the full product
+- keep portability by separating partner adapters from the core ledger and workflow logic
 
 ## Business model
 
@@ -118,9 +131,9 @@ The key is to avoid depending on balance-sheet lending to make the model work.
 
 ### Target customers
 
-- Brazil-based SMB and mid-market employers with commission-heavy teams
+- employers in the selected launch country with commission-heavy teams
 - businesses where payment events are digital and attributable
-- verticals such as franchise retail, clinics, education, auto, telecom, and other sales-led operations
+- verticals such as franchise retail, clinics, education, agencies, brokerages, recruiting, telecom, and other sales-led operations
 
 ### Buyer
 
@@ -132,16 +145,16 @@ The key is to avoid depending on balance-sheet lending to make the model work.
 ### Core pitch
 
 - reduce manual commission work
-- reduce informal advances
+- reduce informal advances or exception requests
 - help retain and motivate sales staff
 - create a trusted real-time view of commission liability and performance
 
 ### Distribution channels
 
 - direct sales to design partners
-- vertical SaaS and POS partnerships
-- franchise groups
-- accounting and payroll-adjacent referral channels
+- vertical SaaS and PSP partnerships
+- franchise or operator groups where relevant
+- accounting, payroll, and finance-adjacent referral channels
 
 ## Defensibility
 
@@ -160,9 +173,10 @@ If the company succeeds, defensibility should come from workflow ownership and d
 - regulatory boundaries around custody, wage access, and credit
 - dependence on a single bank, BaaS, or card partner
 - low balance retention if the product offers no reason to keep funds in-platform
+- overfitting the core product to one country instead of keeping local assumptions modular
 
 ## Bottom line
 
 This idea is attractive because it sits in the overlap of three proven categories: commission software, worker liquidity, and embedded finance.
 
-The market does not appear empty, but it still looks fragmented. A Brazil-first product that turns every validated sale into an auditable, instantly accessible commission balance could occupy a distinct category: `real-time commission infrastructure`.
+The market does not appear empty, but it still looks fragmented. A location-independent product that turns every validated sale into an auditable, quickly accessible commission balance could occupy a distinct category: `real-time commission infrastructure`.

docs/prototype-plan.md

@@ -4,7 +4,7 @@
 
 Build the smallest functional prototype that proves the core wedge for this company:
 
-`a verified customer payment can become an auditable commission balance, and a safe portion of that balance can be accessed instantly via Pix`
+`a verified customer payment can become an auditable commission balance, and a safe portion of that balance can be accessed quickly through the relevant local payout rail`
 
 This prototype should validate three things at once:
 
@@ -27,7 +27,7 @@ That means:
 
 ## Core hypothesis
 
-If a Brazil-based employer with a commission-heavy team can see commissions generated from payment events in near real time, and if employees can access the available portion of those commissions through `Pix`, then the company will have a strong design-partner wedge.
+If an employer with a commission-heavy team can see commissions generated from payment events in near real time, and if employees can access the available portion of those commissions through the relevant local payout rail, then the company will have a strong design-partner wedge.
 
 ## Primary prototype users
 
@@ -52,7 +52,7 @@ Needs to:
 - see what has been `earned`
 - see what is `available`
 - understand what is still pending or held in reserve
-- request a `Pix` cash-out
+- request a payout to a linked bank destination
 - trust that the numbers are correct
 
 ### Internal ops admin
@@ -134,10 +134,10 @@ Mobile-first web experience that shows:
 - current `earned`, `available`, and `settled` balances
 - transaction history
 - payout history
-- current `Pix` key on file
+- current payout destination on file
 - payout request button
 
-#### 6. `Pix` payout flow
+#### 6. Local payout flow
 
 For the prototype, use partner-led abstractions and manual controls.
 
@@ -191,19 +191,19 @@ Use one clear happy-path demo story.
 
 ### Example
 
-- employer: aesthetic clinic group in Brazil
+- employer: aesthetic clinic group
 - employee: seller named Ana
 - rule: 20 percent commission on completed payments
 - availability rule: 70 percent of commission becomes immediately `available`; 30 percent stays held until settlement
-- customer payment: `R$1,000`
+- customer payment: `1,000` in local currency
 
 System behavior:
 
-- payment received: `R$1,000`
-- commission calculated: `R$200 earned`
-- immediate availability: `R$140 available`
-- held amount: `R$60 pending settlement`
-- Ana requests `R$100` `Pix` cash-out
+- payment received: `1,000` in local currency
+- commission calculated: `200 earned`
+- immediate availability: `140 available`
+- held amount: `60 pending settlement`
+- Ana requests a `100` payout to her linked bank destination
 - employer dashboard updates liability and payout history
 
 This single scenario should work end to end before adding more complexity.
@@ -231,7 +231,7 @@ This single scenario should work end to end before adding more complexity.
 
 1. employee opens mobile web app
 2. employee sees `available` balance
-3. employee requests payout to registered `Pix` key
+3. employee requests payout to the registered bank destination
 4. payout request is validated
 5. payout is sent through mocked or manual partner adapter
 6. ledger records the payout and reduces `available`
@@ -306,7 +306,7 @@ A simple but durable architecture is enough.
 Define adapters even if they are mocked.
 
 - `PaymentProviderAdapter`
-- `PixPayoutAdapter`
+- `LocalPayoutAdapter`
 - `KycProviderAdapter`
 
 This keeps the prototype aligned with the long-term partner-led model and avoids hard-coding demo logic everywhere.
@@ -372,7 +372,7 @@ The prototype is successful if it can demonstrate all of the following in one co
 - an employer can be configured in under 30 minutes
 - a payment event generates a commission and updates balances automatically
 - an employee understands `earned` versus `available`
-- an employee can request a `Pix` payout from the `available` balance
+- an employee can request a payout from the `available` balance
 - a refund or reversal creates a visible adjustment without breaking the ledger story
 - an employer can view liability, payouts, and audit history without relying on spreadsheets
 
@@ -383,7 +383,7 @@ To move faster, these can be manual in the first prototype:
 - KYB and KYC review
 - employer contract setup
 - payment provider onboarding
-- actual `Pix` movement through a partner
+- actual payout movement through a partner
 - exception handling and customer support
 - settlement reconciliation edge cases
 
@@ -451,7 +451,7 @@ After this plan, the next useful documents would be:
 - a short product requirements doc for the prototype
 - wireframes for employer and employee flows
 - an event model spec for payments, commissions, payouts, and adjustments
-- a partner-interface spec for mocked `Pix`, KYC, and payment ingestion
+- a partner-interface spec for mocked local payouts, KYC, and payment ingestion
 
 ## Bottom line
 
@@ -459,4 +459,4 @@ The right prototype is not a broad fintech app.
 
 It is a narrow commission infrastructure demo that proves one loop extremely well:
 
-`payment event -> commission calculation -> earned and available balance -> Pix payout -> employer visibility and audit trail`
+`payment event -> commission calculation -> earned and available balance -> local payout -> employer visibility and audit trail`

docs/year-one-roadmap.md

@@ -21,14 +21,14 @@ The year-one target is not maximum feature breadth. It is proof of product-marke
 #### Objectives
 
 - validate the first customer segment
-- choose partner model for custody, payouts, and compliance
+- choose the initial market and partner model for custody, payouts, and compliance
 - lock the ledger and commission system design
 
 #### Workstreams
 
 - run design-partner interviews with target employers
 - map employer commission workflows and exception cases
-- choose payment and banking partner shortlist
+- choose the market-specific payment and banking partner shortlist
 - define balance states: `earned`, `available`, `settled`
 - define reserve and holdback logic for reversals
 - specify onboarding flows for employers and employees
@@ -44,7 +44,7 @@ The year-one target is not maximum feature breadth. It is proof of product-marke
 
 - 5 to 10 serious design partners in pipeline
 - clear v1 scope that does not depend on lending
-- chosen path for `Pix` and custody infrastructure
+- chosen path for the local payout rail and custody infrastructure
 
 ## Core ledger and instant payout access
 
@@ -65,7 +65,7 @@ The year-one target is not maximum feature breadth. It is proof of product-marke
 - internal ledger
 - employee balance with `earned`, `available`, and `settled`
 - employer settlement scheduling
-- instant payout access via `Pix` or equivalent instant transfer rail
+- instant payout access via the local instant or fast transfer rail
 - employer dashboard with payout and commission views
 - employee dashboard with balance and payout history
 

sessions/session-ses_2fe5.md

@@ -1,705 +0,0 @@
-# Payment processing with early commission payouts and bank partnerships
-
-**Session ID:** ses_2fe58810cffeU8IzEZHZRCZF25
-**Created:** 3/18/2026, 3:54:07 PM
-**Updated:** 3/18/2026, 4:18:46 PM
-
----
-
-## User
-
-The core of the idea is: a company that process payments and pays out commissions to employees before sending the money to employers
-However there are some other parts of the idea that I'm still not sure how to put together, for example:
-1) Partnering with banks so that they hold the money and manage that
-2) What are the technologies we can use to process payments 
-
----
-
-## Assistant (Plan · gpt-5.4 · 24.6s)
-
-A cleaner way to frame the idea is:
-
-- A business receives customer payments.
-- Your platform calculates commissions owed to employees from those payments.
-- The funds are held with a regulated bank partner, not by you directly.
-- Your system instructs payouts to employees first, then sends the remaining balance to the employer.
-
-That gives you a clearer model: payment orchestration + commission ledger + regulated banking partner.
-
-What usually fits best
-
-- `You` are the software and workflow layer: calculate splits, track balances, trigger payouts, reporting.
-- `Bank partner` holds the money in safeguarded/FBO-style accounts and handles regulated money movement.
-- `Payment processor` collects the incoming payment.
-- `Payout rails` send money to employees and employers.
-
-How the bank partnership piece usually works
-
-- You generally do not want to custody funds yourself early on.
-- Instead, partner with a sponsor bank or Banking-as-a-Service provider.
-- The bank holds funds, manages compliance requirements around accounts/movement, and settles transactions.
-- Your platform keeps a ledger of who is owed what and sends payment instructions through APIs.
-
-Typical model
-
-- Customer pays `1000`.
-- Your rules engine says employee commission = `200`.
-- Bank-held account receives `1000`.
-- Platform ledger records:
-  - employee payable `200`
-  - employer payable `800`
-- Payout engine sends `200` to employee, `800` to employer.
-
-Key legal/regulatory point
-
-- This starts to look like `payments + payroll + earned commissions`, so regulation matters a lot.
-- Depending on geography, you may touch:
-  - money transmission
-  - payroll/wage laws
-  - KYC/KYB/AML
-  - card/network rules
-  - tax reporting
-- So the safest early approach is usually: `bank + licensed payment partners + your software layer`, rather than becoming the regulated entity yourself.
-
-Tech stack options
-
-- **Payment acceptance**
-  - `Stripe`, `Adyen`, `Checkout.com`
-  - Good for cards, basic ACH, merchant onboarding
-- **Banking / money movement**
-  - `Stripe Treasury`, `Modern Treasury`, `Moov`, `Increase`, `Dwolla`
-  - Good for ACH, wires, RTP, virtual accounts, balance tracking
-- **Identity / compliance**
-  - `Plaid` for bank linking
-  - `Alloy`, `Persona`, `Sardine` for KYC/KYB/fraud
-- **Ledger / commissions engine**
-  - Internal double-entry ledger
-  - Or tools like `Modern Treasury Ledgers`, `Formance`, `TigerBeetle`
-- **Core app stack**
-  - Backend: `Node.js/TypeScript`, `Python`, or `Go`
-  - DB: `PostgreSQL`
-  - Queue/workflows: `BullMQ`, `Temporal`, `SQS`
-  - Audit/reporting: event log + immutable ledger tables
-
-A practical MVP shape
-
-- Employer onboarding
-- Employee onboarding
-- Payment collection
-- Rules engine for commission calculation
-- Internal ledger for split accounting
-- Manual or scheduled payouts
-- Dashboard for balances, payouts, disputes, reports
-
-Best first partnership strategy
-
-- Start with a provider that already has bank relationships and payout rails.
-- Don’t begin by negotiating directly with a large bank unless you already have scale.
-- A common sequence is:
-  1. use `Stripe/Adyen` for incoming payments
-  2. use `Modern Treasury/Moov/Increase` for payout orchestration
-  3. add direct bank relationships later if volume justifies it
-
-The hardest parts are usually not the code
-
-- commission rule complexity
-- timing of fund availability
-- reversals/chargebacks
-- compliance and licensing boundaries
-- disputes between employee and employer
-- tax and payroll treatment of commissions
-
-If you want, I can next help with one of these:
-1. turn this into a one-paragraph startup description
-2. design the full product/payment flow step by step
-3. suggest a concrete MVP stack for building this in 3 months
-
----
-
-## User
-
-Right, so what I am thinking is having accounts for the employers and employees and credit money to their accounts in our system when we receive the payments. We need to find a way to incentivise them to leave their money with us for as long as possible to earn interest off off the cash that we're holding. One way I was thinking of doing this is by having credit/debit cards for the users so that they could spend their money directly from their account, while still leaving the option for them to wire that money to their own bank account. I'm considering starting this company in either switzerland or brazil, given that I have people in both countries that I could leverage and bring into this startup. I don't know much about the swiss market, but I know that the brazilian market currently has some smaller banks that seem eager to find partnerships to gain market share, Sicredi for example. Also, in brazil we have PIX which makes wiring money fast and cheap, which could be a great selling point, something along the lines of being able to tell the sales staff that they can instantly have access to their commissions the moment the customer makes a payment.
-
----
-
-## Assistant (Plan · gpt-5.4 · 34.2s)
-
-You’re moving from “commission payout software” toward a much bigger model: `stored balances + instant access + cards + bank transfers`. That can be powerful, but it changes the company a lot.
-
-The key strategic split
-
-- If you only calculate commissions and trigger payouts, you’re mainly a software/payments orchestration company.
-- If you hold balances in user accounts, let them keep funds, offer cards, and earn yield on float, you start to look like a fintech / neobank / regulated money business.
-
-That second version is much more valuable, but much harder.
-
-What I think is strongest in your idea
-
-- The best wedge is not “we hold your money.”
-- The best wedge is “salespeople get instant access to commissions the moment a sale clears.”
-- In Brazil, that pitch is especially strong because `PIX` makes instant movement normal and expected.
-- A card attached to the balance makes the money feel immediately usable, which is a real behavioral incentive not to cash out.
-
-Important caution on “earning interest off the cash”
-
-- This is attractive economically, but it is also where regulation gets much more serious.
-- You generally cannot just “hold client money and earn interest on it” however you want.
-- You need to be very clear on:
-  - who legally holds the funds
-  - whether funds are customer assets or your operating cash
-  - whether yield/interest belongs to the customer, the bank, or your platform
-  - whether your product becomes regulated as stored value, e-money, deposit-like activity, or money transmission
-- So the safer version is usually:
-  - partner bank or licensed institution holds funds
-  - your platform maintains the subledger and user experience
-  - cards and transfers are issued through licensed partners
-  - your economics come from interchange, SaaS, take rate on processing, float-sharing agreement if allowed, and treasury arrangements
-
-Your proposed product architecture
-
-- Employer account in your app
-- Employee account in your app
-- Incoming payment lands into safeguarded/partner-held funds
-- Your ledger allocates the split instantly
-- Employee sees commission balance immediately
-- Employee can:
-  - spend with card
-  - transfer out to bank
-  - maybe keep balance for future spending
-- Employer receives remaining balance on schedule or instantly
-
-That is a coherent product.
-
-Why Brazil looks stronger than Switzerland for the first launch
-
-- `PIX` is a huge distribution advantage for instant payouts.
-- User behavior already accepts real-time transfers.
-- Smaller financial institutions may be more open to partnerships.
-- The pain point around delayed commission access feels easier to explain.
-- Switzerland is wealthy and credible, but likely harder as a first market unless you already have strong local regulatory and banking access.
-
-My default view: start in `Brazil`, not Switzerland, unless your Swiss network includes real bank/compliance operators.
-
-Why cards are smart
-
-- A card makes the balance useful without forcing bank withdrawal.
-- That increases retention of funds in the system.
-- It also creates interchange revenue.
-- It changes the product from “payout tool” to “financial home for commission earners.”
-
-But cards should probably be phase 2, not day 1.
-
-Recommended rollout
-
-1. `Phase 1`: instant commission ledger + PIX payout
-- receive merchant payment
-- calculate split
-- show employee available commission immediately
-- let employee cash out instantly via PIX
-- let employer settle on schedule
-
-2. `Phase 2`: stored balance
-- employee can keep balance in app
-- employer can hold operating balance for future payouts
-- basic wallet behavior
-
-3. `Phase 3`: card issuance
-- prepaid/debit card tied to stored balance
-- spend directly from commission account
-- optional employer expense or draw features later
-
-4. `Phase 4`: treasury economics
-- negotiated bank yield/float arrangements
-- maybe employer incentives for keeping balances
-- maybe employee rewards instead of explicit interest
-
-Better incentive framing
-
-Instead of saying “leave money with us so we earn interest,” design the product so users naturally keep balances because it is useful:
-
-- instant commission availability
-- free PIX transfers
-- card spend with cashback/rewards
-- early access to future commissions
-- bill pay / payroll-like convenience
-- employer bonuses for keeping payout reserves on platform
-
-That is commercially cleaner and safer to message.
-
-Core risks you should think through now
-
-- **Regulatory boundary**: are you software, payment institution, wallet, or something deposit-like?
-- **Fund timing**: when is money truly available vs still reversible?
-- **Chargebacks/refunds**: what happens if you already paid the employee?
-- **Labor law**: are instant commissions legally “earned wages,” “advances,” or something else?
-- **Partnership dependence**: your bank/program manager/card issuer can become a bottleneck.
-- **Unit economics**: instant payouts and card programs only work if fees, fraud, and support stay under control.
-
-My practical recommendation
-
-- Build the company narrative around `instant commission access infrastructure for employers and sales teams`.
-- Start with `Brazil`.
-- Use `PIX` as the hero feature.
-- Do not make “we profit from holding your cash” the public core story.
-- Structure the first version with a licensed financial partner holding funds.
-- Add cards only after the payout/ledger engine works reliably.
-
-A clean positioning statement
-
-- “We help companies collect payments and give sales teams instant access to earned commissions, with employer and employee balances managed through regulated financial partners.”
-
-If you want, I can next do one of these:
-1. turn this into a proper startup thesis and business model
-2. map the exact money flow and partner stack for a Brazil-first launch
-3. compare Brazil vs Switzerland in a founder-style decision memo
-
----
-
-## User
-
-One practice that is quite common place in Brazil, that this company could potentially reduce, but probably not eliminate is what they call "vales", which are essentailly advances on their paycheck. I think there's good potential in also making it a feature in the business, letting employees borrow against their paycheck for a small fee/interest.
-
----
-
-## Assistant (Plan · gpt-5.4 · 19.7s)
-
-That can be a strong feature, but it splits into two very different products:
-
-- `Earned wage access` — employees withdraw commission/pay already earned but not yet settled.
-- `Consumer credit` — employees borrow against expected future paycheck/commission.
-
-Those look similar in the app, but operationally they are very different.
-
-My recommendation
-
-- Start with `earned commission access`, not lending.
-- Treat it as “access to already-earned money” whenever possible.
-- Only explore true advances/credit later, once you have repayment data and employer integrations.
-
-Why this matters
-
-- `Earned access` is easier to explain: “you already earned it, we just make it available sooner.”
-- `Lending` creates heavier risk around underwriting, defaults, collections, regulation, and reputation.
-- In Brazil, a product that feels like replacing `vales` is attractive, but you do not want to become just another salary-advance lender.
-
-Best product framing
-
-- Employee makes a sale.
-- Payment is received or sufficiently authorized.
-- Your engine calculates commission instantly.
-- A safe portion becomes `available now`.
-- Employee can:
-  - withdraw via `PIX`
-  - spend via card
-  - keep balance in wallet
-- For amounts not yet fully settled, you can show:
-  - `available now`
-  - `pending settlement`
-  - `future estimated commissions`
-
-That lets you reduce `vales` without promising money too early.
-
-Rollout path
-
-1. `Phase 1: Early access to earned commissions`
-- no true loan
-- only release funds tied to clear sales/payment events
-- set conservative availability rules
-
-2. `Phase 2: Employer-backed advances`
-- employer opts in
-- employer agrees payroll deduction / settlement logic
-- advance limits based on verified earnings history
-
-3. `Phase 3: Risk-based credit`
-- only if economics and regulation make sense
-- requires underwriting, loss reserves, collections, disclosures
-
-Key design choice
-
-- Use `employer-backed advance` before `standalone consumer lending`.
-- If the employer contract helps recover advances from payroll/commissions, risk drops a lot.
-- That keeps the product closer to B2B2C infrastructure than pure retail credit.
-
-Big risks to solve
-
-- **Settlement risk**: what if customer payment reverses after employee got paid?
-- **Commission disputes**: what if employer later changes the commission amount?
-- **Legal classification**: earned wage access vs credit product
-- **Collections**: what happens if employee leaves the company?
-- **Abuse**: employees repeatedly pulling advances before reversals/refunds are known
-
-Practical guardrails
-
-- Only advance against `verified and rule-locked` commissions
-- Keep a reserve/holdback for refunds and chargebacks
-- Cap instant access to a percentage, not 100%, at first
-- Require employer integration and approval
-- Price it as a transparent convenience fee, not compounding debt
-- Avoid language that makes it sound like payday lending
-
-Strong positioning
-
-- “We help companies eliminate informal paycheck advances by giving employees controlled, instant access to earned commissions.”
-
-What I’d plan next
-
-- Define three balance states: `earned`, `available`, `settled`
-- Make `PIX instant cash-out` the core Brazil feature
-- Keep wallet/cards as retention tools
-- Defer true lending until you have data on repayment, reversals, and employer behavior
-
-If you want, I can next do one of these:
-1. draft a Brazil-first product roadmap including this feature
-2. map the risk rules for `earned access` vs `advance`
-3. write a founder memo on why this should start as EWA, not lending
-
----
-
-## User
-
-Another part that I think can be valuable to companies is the possibility of giving them information on the performance of sales staff through amount of commissions, projections, some other forms of telemetry, etc
-
----
-
-## Assistant (Plan · claude-opus-4.6 · 28.4s)
-
-That's a natural extension and it gives the product a second value proposition beyond money movement: `sales intelligence powered by real transaction data`.
-
-Why this is strong
-
-- You already have the data because payments flow through your system.
-- Most commission tracking today lives in spreadsheets or disconnected CRMs.
-- Employers currently have to reconstruct sales performance from multiple sources.
-- Your platform sees the actual money, so your data is inherently more trustworthy than self-reported CRM entries.
-
-What you can offer
-
-**Real-time dashboards for employers**
-
-- Total commissions paid per employee, team, region, period
-- Revenue per salesperson
-- Average deal size and frequency
-- Commission cost as percentage of revenue
-- Top performers vs underperformers
-- Trends over time (weekly, monthly, quarterly)
-
-**Projections and forecasting**
-
-- Projected commission liability for the month based on current pace
-- Expected payout amounts before settlement
-- Seasonal patterns and trend analysis
-- Cash flow forecasting for the employer (how much they need in the system to cover upcoming payouts)
-
-**Employee-facing insights**
-
-- "You've earned X this month, Y this quarter"
-- Progress toward targets or tiers
-- Comparison to personal history
-- Estimated next payout
-
-**Alerts and anomalies**
-
-- Sudden drop in an employee's sales
-- Unusually high refund/chargeback rate for a salesperson
-- Commission costs trending above budget
-- Employees approaching advance limits
-
-**Operational telemetry**
-
-- Time from sale to commission availability
-- Payout speed and method distribution
-- Cash-out frequency per employee
-- Balance retention rates
-
-Why this matters strategically
-
-- Analytics transforms your product from `payment plumbing` into `business intelligence`.
-- It makes the employer the buyer, not just the payer.
-- It increases switching costs — once employers rely on your dashboards, leaving is harder.
-- It opens a path to premium/enterprise pricing tiers.
-
-Important nuance
-
-- The analytics should come from data you already collect through payment processing.
-- Do not try to become a full CRM or HR platform.
-- Stay focused on `money-linked sales performance`, not general employee management.
-
-How it fits in the product
-
-| Layer | What it does |
-|---|---|
-| Payment engine | Collect, split, settle |
-| Ledger / wallet | Track balances, enable instant access |
-| Cards / PIX | Make money usable |
-| Analytics | Make the data useful to employers |
-
-The analytics layer is essentially free to build incrementally because the underlying data already exists in your ledger. It's a reporting and visualization problem, not a data collection problem.
-
-Pricing angle
-
-- Basic analytics included in the platform fee
-- Advanced analytics (projections, anomaly detection, custom reports, API access) as a premium tier
-- That gives you a SaaS-like revenue stream alongside transaction-based revenue
-
-Recommended approach
-
-- Ship basic dashboards early — even simple charts increase perceived value significantly.
-- Add projections and alerts as you accumulate enough historical data.
-- Let employer feedback drive which analytics matter most.
-- Do not over-invest in analytics before the core payment/payout engine works.
-
-At this point, the full product vision is becoming clear:
-
-1. **Payment collection** — employer receives customer payments through you
-2. **Commission engine** — rules-based split calculation
-3. **Instant access** — employees see and use earned commissions immediately
-4. **Wallet + cards + PIX** — money stays in system, usable without withdrawal
-5. **Earned wage access / advances** — reduce informal "vales"
-6. **Sales analytics** — employer gets performance intelligence from real payment data
-7. **Float economics** — platform earns from balances, interchange, fees
-
-That is a coherent, defensible fintech product.
-
-Do you want me to now pull all of this together into one of these:
-1. A structured startup thesis / business model document
-2. A phased product roadmap with priorities
-3. A technical architecture plan for building the MVP
-
----
-
-## User
-
-1
-
----
-
-## Assistant (Plan · claude-opus-4.6 · 59.7s)
-
-
-
-Here is the structured startup thesis and business model.
-
----
-
-# Startup Thesis: Instant Commission Infrastructure
-
-## One-liner
-
-A B2B2C fintech platform that sits between employers and sales staff, processing customer payments, instantly calculating and distributing commissions, and providing financial accounts with cards and instant transfers — while earning from float, interchange, fees, and SaaS.
-
----
-
-## Problem
-
-**For employers:**
-- Commission calculation is manual, error-prone, and delayed.
-- Payroll cycles create lag between a sale and the salesperson getting paid.
-- Informal advance practices ("vales") are unstructured, create accounting friction, and expose the company to risk.
-- Visibility into sales performance is fragmented across CRM, payroll, and spreadsheets.
-
-**For employees (sales staff):**
-- Commissions arrive days or weeks after the sale.
-- Accessing earned money early requires asking for informal advances.
-- No single place to see earnings, track performance, or manage commission income.
-
----
-
-## Solution
-
-A platform that:
-
-1. Receives customer payments on behalf of the employer.
-2. Instantly calculates the commission split using employer-defined rules.
-3. Credits the employee's account with earned commission in real time.
-4. Lets employees spend (card), transfer (PIX), or hold their balance.
-5. Settles the employer's share on their preferred schedule.
-6. Provides both sides with analytics, projections, and reporting.
-
----
-
-## How money flows
-
-```
-Customer pays R$1,000
-        │
-        ▼
-┌─────────────────────────┐
-│  Partner bank / FBO     │  ← Regulated entity holds funds
-│  account receives funds │
-└─────────────────────────┘
-        │
-        ▼
-┌─────────────────────────┐
-│  Platform ledger splits  │
-│  Employee: R$200         │
-│  Employer: R$800         │
-│  Platform fee: deducted  │
-└─────────────────────────┘
-        │                │
-        ▼                ▼
-   Employee acct    Employer acct
-   (available now)  (settles on schedule)
-        │
-        ├── PIX cash-out (instant)
-        ├── Card spend (interchange)
-        └── Hold balance (float)
-```
-
----
-
-## Revenue model
-
-| Stream | Description | Phase |
-|---|---|---|
-| **Transaction fee** | % or flat fee on each payment processed | 1 |
-| **PIX/transfer fee** | Small fee per cash-out (or free with limits) | 1 |
-| **Float income** | Interest/yield on balances held with bank partner | 2 |
-| **Card interchange** | Revenue share on card transactions | 3 |
-| **Advance fee** | Flat fee for early access to not-yet-settled commissions | 2 |
-| **SaaS tier** | Premium analytics, custom rules, API access, multi-entity | 2 |
-
-The strongest early revenue is likely `transaction fee + advance fee`. Float and interchange grow with balance retention and card adoption.
-
----
-
-## Target market (Brazil first)
-
-**Initial segment:**
-- Small and mid-size companies with commission-based sales teams (5–200 salespeople).
-- Industries: retail, insurance, real estate, auto dealers, door-to-door sales, telecoms resellers.
-
-**Why Brazil:**
-- PIX makes instant transfers a baseline expectation.
-- "Vales" culture creates a clear pain point to solve.
-- Smaller banks (e.g., Sicredi, cooperatives) are actively seeking partnerships to grow.
-- Large underbanked/underserved workforce in commission-based roles.
-- Regulatory environment has a clear framework for payment institutions.
-
-**Why not Switzerland first:**
-- Harder to find flexible bank partners without existing scale.
-- Smaller addressable market for commission-heavy sales forces.
-- Higher regulatory and operational costs to start.
-- Consider Switzerland as a second market or for a different product angle (e.g., wealth/treasury for employers).
-
----
-
-## Product roadmap
-
-### Phase 1 — Core (months 1–4)
-- Employer onboarding and configuration
-- Employee onboarding (KYC via partner)
-- Payment collection (PIX, boleto, card via payment processor)
-- Commission rules engine (percentage, tiered, custom)
-- Internal double-entry ledger
-- Employee balance: `earned` / `pending` / `settled`
-- PIX instant cash-out for employees
-- Employer settlement on schedule
-- Basic employer dashboard (commissions paid, per-employee breakdown)
-- Basic employee dashboard (earnings, available balance, cash-out history)
-
-### Phase 2 — Retention + advances (months 4–7)
-- Employee wallet with stored balance
-- Earned wage access: early access to earned-but-unsettled commissions
-- Employer-backed advance feature (payroll-deductible)
-- Reserve/holdback logic for refunds and chargebacks
-- Employer analytics: performance trends, projections, commission cost ratios
-- Employee insights: earnings pace, personal trends
-- Alerts: anomalies, budget thresholds, refund spikes
-- Premium SaaS tier for analytics
-
-### Phase 3 — Cards + scale (months 7–12)
-- Prepaid/debit card issuance (via card program manager)
-- Card spend from commission balance
-- Interchange revenue
-- Float optimization with bank partner
-- Multi-entity / franchise support
-- API for employer system integrations (ERP, CRM, POS)
-- Employer cash flow forecasting
-
-### Phase 4 — Expansion (12+ months)
-- Risk-based credit / true advances (if regulation allows and data supports)
-- Employee rewards / cashback programs
-- Second market entry (Switzerland or other LatAm)
-- Employer expense management features
-- White-label or embedded finance partnerships
-
----
-
-## Key partnerships needed
-
-| Partner type | Role | Examples (Brazil) |
-|---|---|---|
-| **Sponsor bank / BaaS** | Hold funds, compliance, account infrastructure | Sicredi, QI Tech, Dock, Celcoin |
-| **Payment processor** | Accept PIX, boleto, cards | Pagar.me, Stripe BR, Adyen |
-| **Card issuer / program manager** | Issue prepaid/debit cards | Dock, Pomelo, Swap Financial |
-| **KYC/KYB provider** | Identity verification | idwall, BigDataCorp |
-| **Legal / regulatory counsel** | Payment institution licensing, labor law | Local fintech law firm |
-
----
-
-## Regulatory considerations (Brazil)
-
-- **Payment institution license**: likely needed if holding client funds or issuing payment instruments. Can potentially operate under a bank partner's license initially.
-- **Central Bank oversight**: PIX participation rules, reporting obligations.
-- **Labor law**: commission classification, payroll deduction rules for advances, tax withholding obligations.
-- **Consumer protection (CDC)**: transparency on fees, right to information.
-- **LGPD**: data protection for employee financial data.
-- Early recommendation: operate under a licensed partner's umbrella, pursue your own license when volume justifies it.
-
----
-
-## Core risks
-
-| Risk | Mitigation |
-|---|---|
-| Settlement reversal after payout | Holdback reserves, conservative availability windows |
-| Commission disputes | Employer-signed rules, audit trail, dispute workflow |
-| Employee default on advances | Employer-backed payroll deduction, conservative limits |
-| Bank partner dependency | Contractual protections, plan for multi-partner |
-| Regulatory classification | Legal counsel from day 1, operate under licensed partner |
-| Fraud / identity | KYC at onboarding, transaction monitoring |
-| Low balance retention | Card + UX incentives to keep funds in-platform |
-
----
-
-## Unit economics sketch (per employer, per month)
-
-Assuming: 20 employees, R$500 avg commission, 80% cash-out rate
-
-| Item | Value |
-|---|---|
-| Total commissions processed | R$10,000 |
-| Transaction fee (2%) | R$200 |
-| Advance fees (10% of employees, R$5 each) | R$10 |
-| Float income (20% retained, ~1% monthly yield) | R$20 |
-| Interchange (Phase 3, est.) | R$15 |
-| **Monthly revenue per employer** | **~R$245** |
-| Target: 200 employers | **~R$49,000/mo** |
-
-These are rough and conservative. The real leverage comes from larger employers and higher retention rates.
-
----
-
-## Competitive positioning
-
-- Not a payroll company. Not a bank. Not a CRM.
-- "Commission infrastructure" — the financial operating system between employer payments and sales team earnings.
-- Closest comparisons internationally: `Earned wage access` (DailyPay, Caju, Xerpay) crossed with `payment splitting` (Stripe Connect model) crossed with `sales performance analytics`.
-- Differentiation: you process the actual payment, so you have the most trustworthy data and the fastest path to commission availability.
-
----
-
-## Founding team needs
-
-- **Product / business lead**: understands the employer sales pain, can sell to mid-market companies.
-- **Engineering lead**: can build ledger, payment integrations, real-time systems.
-- **Fintech / regulatory lead**: understands Brazilian payment institution rules, bank partnerships, compliance.
-- Ideally, at least one founder with direct relationships at potential bank partners.
-
----
-
-That covers the thesis, model, market, roadmap, risks, and economics. Want me to go deeper on any section, or move toward technical architecture or a specific partnership strategy?
-
----
-