Belgian workplace pension migration OS that moves mid-market employers from opaque group insurance to transparent pooled retirement plans.

1. Belgian supplementary pension outcomes are poor enough to create executive urgency, since workers near retirement reportedly hold median reserves under €10,000.
2. Employers are already proving willingness to move plans, which means the market no longer needs education so much as lower-friction migration tooling.
3. A regulated, fee-light fund creates a credible replacement rail, so a new entrant can sell the software and workflow that helps employers defect from costly group insurance.
4. AI-powered coaching is moving into the core pension offer, making employee understanding and trust part of the product rather than a separate HR education exercise.

Catalyst. Warren's funding, proof of about 100 employer migrations, and the headline claim that Belgium's current group insurance products are costly and poorly understood show that both buyer pain and a regulated replacement path now exist at the same time.

Build a vertical SaaS platform for employers and brokers switching workplace pensions away from opaque group insurance products. The first module imports incumbent plan documents and payroll files, surfaces fees and plan rules, and generates a side-by-side employee outcome model for the replacement fund. A migration workflow then coordinates payroll field mapping, employee consent steps, broker tasks, and insurer handoffs so the switch feels like a managed software rollout instead of a legal project. An embedded employee portal and coaching layer answers "what changes for me?" questions in plain language, lifting adoption and reducing HR ticket volume. Over time, the platform becomes the operating system for contribution changes, new-hire onboarding, and retirement-plan analytics after the migration is complete.

What's different. Most benefits vendors either sell the pension product itself or provide generic financial wellness content. This company would own the hard layer in between: the workflow that converts an employer from one retirement setup to another while preserving payroll accuracy, employee trust, and auditability. That creates sticky system-of-record data around plan rules, contribution flows, and employee communications that brokers, insurers, and coaching apps do not currently unify.

Jobs to be done

flowchart LR
  Buyer[Belgian CFO or CHRO] --> Pain[Opaque pension plan and painful switch process]
  Pain --> Product[Pension migration and admin OS]
  Product --> Outcome[Lower fees, higher trust, smoother pension operations]

Executive takeaways

• The real wedge is operational switching, not a prettier pension dashboard: Belgium already has regulated replacement rails, but employers still treat provider changes as brittle legal projects.
• This is an event-driven sale: harmonization deadlines, reorganisations, and provider reviews are the moments when CFO and CHRO attention actually appears.
• Belgium is a credible but narrow beachhead, so the venture case depends on turning local migration know-how into repeatable software and exporting it into other fragmented European benefits markets.
• The biggest go-to-market risk is channel resistance from brokers and payroll administrators who currently monetize the mess; collaboration-first distribution is likelier to work than open disintermediation.

Market definition

This category sits between pension product, broker service, and payroll administration. The defensible product is the migration and operations layer that audits the incumbent contract, models a replacement structure, coordinates the transfer, and keeps payroll, reporting, and employee communication aligned after go-live.

Customer and buyer

The daily user is the HR, payroll, or benefits manager who has to reconcile provider data, payroll changes, and employee questions. The economic buyer is typically the CFO, CHRO, or head of total rewards when a renewal, harmonization project, or organisational change forces a decision.

Buying triggers

• Blue-collar / white-collar harmonization and the 2030 deadline create forced review windows for supplementary pension plans. [25][26][30]
• Changes inside the company such as provider changes, mergers, or reorganisations expose how manual the current insurer-and-broker workflow still is. [18][20]
• Employee job changes and reserve-transfer questions create a communication burden that HR teams currently solve with letters, FAQs, and ad hoc explanations. [27][28][29][31]

Willingness to pay

Budget clearly exists around pension administration and change management: employers already absorb special pension contributions, insurer/broker servicing, portal tooling, payroll integration, and outsourcing costs. A switching OS can attach to that budget line if it reduces paperwork, errors, and fee opacity. [17][18][23][24]

Category dynamics

Growth signal 2.4% YoY growth in the number of Belgian 50-249 employee SMEs (2023-2024 proxy for adjacent mid-market employer-base growth)

Validation signals

• FinTech Global reports that around a hundred Belgian companies had already moved pension arrangements to Warren within its first year of operations.
• Warren’s Helio case study claims 78% weekly active members six months after go-live, suggesting employees will engage when the experience is simple and employer-backed.
• NN and SD Worx explicitly market low-paperwork administration, integrations, and outsourcing, confirming that operations simplification already carries budget.
• Detailed employee FAQs from KBC, P&V, and Test-Aankoop show that reserve visibility, transfer choices, and tax treatment remain recurring pain points.

Regulatory & technical constraints

• Supplementary pensions must be managed by an insurer or pension fund, so the startup must integrate with regulated institutions rather than sit in the balance-sheet chain itself.
• DB2P / PensionPro reporting requires clean organiser, provider, and affiliate mappings plus versioned schema support.
• Blue-collar / white-collar harmonization creates legal project dependencies through 2030 that can delay or reshape employer plan changes.
• Group-insurance comparisons touch the 8.86% employer social contribution, the Wijninckx contribution, the 80% rule, and payout-tax treatment, so modeling errors create real legal and budget risk.

Budget and trust are fragmented across four lanes: insurers that own the pension product, brokers that run the review project, payroll/social-secretariat players that own the employee-data plumbing, and new fee-light pension funds that improve economics but still sell their own rail. The startup wins only if it becomes the neutral switching layer across those lanes.

Why incumbents do not win by default

• Insurers. AG and NN already offer plan design and admin portals, but they still optimize around their own contract book rather than around making it easy for an employer to defect to a better structure.
• Brokers and consultants. Vanbreda-class advisers own the renewal conversation, yet their workflow is still service-led and bespoke rather than a reusable, auditable software control plane.
• Payroll and social secretariats. SD Worx and Securex have the integration trust and payroll data, but not the pension-modeling and transfer-rights logic that makes provider switching safe.
• Pension funds and OFPs. Prolocus and Warren prove that pooled pension-fund structures can be more transparent, but a fund does not automatically own the migration OS layer across multiple provider types.

Belgian pension switch OS is a workflow and data layer for Belgian mid-market employers moving supplementary pensions off opaque group insurance contracts. The first buyer is a CFO, CHRO, or Head of Total Rewards at a 500-2,000 employee company facing a renewal, harmonization project, or benefits redesign within 12 months. The pain is operational more than informational: employers can compare providers, but switching still breaks across insurer documents, payroll mappings, broker handoffs, DB2P reporting, and employee questions. Research supports a real replacement rail through regulated pension funds and shows roughly 100 employer migrations already happened in the market, but the evidence base is still concentrated in one recent entrant and does not fully resolve pricing or implementation-labor questions. The initial product should therefore start as a read-heavy migration workspace that audits the incumbent plan, models employee-level outcomes, and coordinates provider, payroll, broker, and employee tasks without becoming the pension product itself. The researched Belgian SAM is only about $5.9M, so the venture case depends on turning local migration know-how into repeatable software and then exporting it into adjacent fragmented European benefits markets. Go-to-market should be collaboration-first with brokers and payroll partners because those channels already own trust and can block adoption if threatened. The company should delay cross-border expansion, public-sector plans, and broad financial wellness until it proves that migrations close faster, error rates fall, and employers convert from one-off switch projects into recurring administration revenue. The board-level question is whether a neutral switching OS can win budget before fund-led players and incumbent insurers bundle enough workflow to make a standalone layer unnecessary.

Problem

• Legacy Belgian group insurance plans are costly, opaque, and poorly understood, but employers still struggle to change providers because the switch spans payroll remapping, broker coordination, transfer logic, DB2P reporting, and employee communications.
• Contract renewals and harmonization projects create urgency, yet HR and finance teams still run the change process through spreadsheets, PDFs, email chains, and service-heavy intermediaries that increase error risk and hide true economics.

Solution

• Build a migration workspace that imports incumbent plan documents and payroll exports, surfaces fees and plan rules, and generates employee-level outcome comparisons across replacement structures.
• Orchestrate payroll mapping, provider handoffs, broker tasks, compliance checkpoints, and employee Q&A in one auditable workflow that stays useful after go-live for contribution changes and plan administration.

Why we win

• The wedge is narrower than selling a new pension fund or a generic benefits portal: it targets the highest-friction moment when employers already need to act.
• A neutral control plane can work across insurers, brokers, payroll systems, and pension funds, which is a better fit for buyers that want proof before committing to one rail.
• Every completed migration improves provider-rule libraries, payroll mappings, and employee communication templates, lowering implementation risk on the next account.

Milestones

flowchart LR
  Wedge[Renewal-driven switching wedge] --> MVP[Migration workspace MVP]
  MVP --> Proof[Clean go-live and lower manual coordination]
  Proof --> Expansion[Recurring pension operations and channel expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• Brokers and consultants accept a collaboration-first model and help source at least part of the first pipeline instead of blocking the product.
• The three most common target payroll and insurer file combinations can be normalized in under three weeks without bespoke engineering each time.
• Buyer-facing outcome models are trusted enough to influence provider-selection decisions in real renewal processes.
• At least half of paid migration projects convert into annual recurring administration subscriptions after go-live.
• A neutral workflow layer can win budget even when the employer has not yet chosen one specific pension fund or insurer rail.

Open diligence questions

• Which exact renewal or harmonization events make CFOs and CHROs spend incremental budget instead of leaving the process with brokers and insurers?
• How much manual cleanup is required on the first five payroll and incumbent-plan datasets?
• What economic concession or workflow benefit does a broker need to actively co-sell this product?
• Can the startup win when the employer stays with an incumbent insurer but still wants better switching and administration tooling?
• What recurring workflow after go-live is valuable enough to sustain software retention beyond the migration event?

Model sanity

• Revenue engine. Base revenue is driven by growing active paying employers from 3 at Y1 exit to 34 by Q4Y3 while the mix shifts from one-time migrations toward recurring administration subscriptions.
• Must go right. The company must standardize the first payroll and provider templates fast enough that gross margin can move from the mid-40s in Y1 to roughly 72% by Q4Y3 without adding a large services bench.
• Model breaks if. If broker channels stall and migration-to-subscription conversion stays near the 40% kill-criteria floor, the downside case compresses the cash floor toward roughly $0.1M before the next raise.
• Next-round proof. The next financing story is about 20 active paying employers by Q2Y3 with 50%+ recurring conversion, partner-sourced deals working, and more than six months of cash still on hand.

Scenarios

Sensitivity

flowchart LR
  RenewalEvents[Renewal and harmonization events] --> PaidMigrations[Paid migration projects]
  PaidMigrations --> LiveEmployers[Live employer admin subscriptions]
  LiveEmployers --> Revenue[Recurring + migration revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash and runway]

Flags: The blended revenue per active employer stays elevated because customersEop combines migration projects and recurring subscriptions; true pure-subscription ARR is lower than total reported revenue until late Y3. · The base case depends on broker and payroll channels contributing materially by Y2; a mostly direct-sales motion would likely require either lower growth or a larger round. · Even with a lean team, the model does not reach full-year EBITDA breakeven by Y3, so a slower margin ramp or earlier hiring would push the funding ask upward.

• Distribution capture by brokers. Benefits brokers may prefer to keep switching workflows opaque and service-heavy, limiting direct software adoption by employers. Mitigation: Start with broker-friendly collaboration features and revenue share so the product upgrades broker workflow instead of trying to displace distribution on day one.
• Regulatory and product dependence. If regulated pooled-fund structures prove harder to deploy broadly than the source suggests, migration demand could narrow to a smaller slice of the market. Mitigation: Keep the software fund-agnostic so it can support comparisons, migrations, and administration across multiple approved pension structures, not one provider model.
• Data and payroll integration drag. Employer pension files, payroll codes, and incumbent insurer records may be too messy for fast time to value in early deployments. Mitigation: Focus first on a narrow renewal playbook for common Belgian payroll systems and read-heavy migrations before expanding into deeper ongoing administration workflows.