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

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