API shadow ledger for European pension and life funds to ship dashboard compliance and policy changes without core replacement.

1. Growth capital at scale is flowing into pension-core modernization, which signals that boards and investors now view this as an active software budget line rather than deferred technical debt.
2. Pension dashboard and Solvency II mandates create hard deadlines for exposing policy data, making an external API layer easier to fund than a purely strategic platform rewrite.
3. Funds cannot wait for multi-year replacements because their mainframes are already too expensive and too slow to absorb product, fee, and reporting changes.
4. Buyers are validating modular, API-first architectures, which opens the door for a wedge product that modernizes data and change workflows before it takes on full policy administration.

Catalyst. Pension dashboards and Solvency II data demands are forcing funds to externalize core data, while validated growth capital behind modular API-first vendors shows buyers now have budget for incremental modernization.

Build a vertical software layer that sits beside the legacy pension core and creates a canonical benefit-event ledger for policies, contributions, fees, and payouts. The first product ingests batch outputs and policy tables from the incumbent system, turns them into auditable APIs, and generates dashboard-ready member records plus regulator-ready extracts. A second module lets operations teams simulate scheme and fee changes before they touch the mainframe, reducing the risk of weekend releases and actuarial spreadsheet workarounds. Over time, the ledger becomes the control plane for policy change management and book migration, giving customers a path away from the core without a big-bang replacement.

What's different. Most vendors in this category sell either a full policy administration replacement or generic data-integration services. This company would start at the highest-pain seam: translating legacy pension policy logic into a trusted benefit-event model that powers dashboard, reporting, and scheme-change workflows. That creates a proprietary rules corpus and customer dependency on the event ledger, which is harder to displace than a pure API gateway or consultancy.

Jobs to be done

flowchart LR
  Buyer[Pension COO or CIO] --> Pain[Legacy core blocks dashboard and scheme changes]
  Pain --> Product[Benefit event shadow ledger]
  Product --> Outcome[Faster compliance and safer modernization]

Executive takeaways

• The most urgent wedge is not a full policy-administration replacement; it is getting large schemes through dashboard, data-quality, and pension-rule deadlines without touching the legacy core first. [1][3][5][7][8][27][28][29]
• UK dashboards and the Dutch Future Pensions Act create visible delivery windows, while Solvency II reporting change keeps life insurers in the same buying conversation. [7][8][9][20][27][28][29]
• Competition is real but skewed toward heavier transformation motions: the fetched incumbents mostly sell full PAS suites, member/admin platforms, or migration programmes rather than a narrow audit-first benefit-event overlay. [40][43][47][49][50][51][52][53]
• Budget is real because schemes and providers are already connecting to dashboards, very large administrators are transitioning millions of members, and pension-tech vendors are attracting both funding and M&A. [13][14][32][33][35][40][43][44][47]

Market definition

An audit-first software layer that sits beside legacy pension and life policy systems, turns scheme and policy events into a canonical ledger, and feeds dashboards, member communications, regulatory extracts, and controlled change workflows without forcing a full PAS replacement first. [1][4][5][28][39][44]

Customer and buyer

Daily users are policy-administration transformation leads, dashboard programme managers, pension operations teams, and actuarial change managers who must expose trustworthy member data and simulate rule changes outside legacy cores. The economic buyer is usually the COO, CIO, or head of administration transformation at a pension administrator or life platform owner. [3][12][27][29][39]

Buying triggers

• A dashboard connection deadline or connection wave forces the scheme/provider to expose member and policy data externally by 31 October 2026. [1][3][7][8]
• Data-quality, matching, and member-information duties reveal that the incumbent admin stack cannot produce reliable dashboard-ready outputs without manual reconciliation. [4][5][10][11][12]
• Dutch pension-rule transition programmes require administrators to remodel benefits and communications before the 1 January 2028 deadline. [27][28][29]
• Solvency II reporting and disclosure changes keep insurer data models and reporting pipelines in motion, making adjacent modernization easier to fund. [20]

Willingness to pay

Willingness to pay is highest when the spend can ride on an already-funded compliance or transition programme. Standard Life and Nest are already connected to the dashboard ecosystem, APG is actively moving large funds onto the renewed Dutch system, and both Festina and Lumera show that buyers will finance major modernization work when it de-risks administration and change. [13][14][33][35][40][43][44]

Category dynamics

Growth signal 7.0-12.2% CAGR across fetched global life-PAS market summaries

Validation signals

• Standard Life has already connected to the dashboard ecosystem via an Integrated Service Provider, proving buyers will fund third-party connection architecture.
• Nest is already connected and serves 13.8 million members, proving that very large schemes are actively doing the work now.
• Dutch administrators such as PGGM and APG are already operating at huge scale while navigating transition work, which supports a beachhead focused on controlled rule change rather than greenfield admin.
• Lumera’s 58-million-transaction migration and Keylane’s acquisition of Heywood show that large buyers still spend materially on pension admin modernization infrastructure.

Regulatory & technical constraints

• Any solution touching dashboards must support reliable member matching and controlled delivery of administrative, signpost, and value data.
• UK in-scope schemes and providers are working against a staged path that ends on 31 October 2026.
• Dutch administrators must execute broad pension-rule transitions before 1 January 2028 under the Future Pensions Act.
• Life insurers still face changing Solvency II reporting and disclosure requirements, so the data model must be auditable and adaptable.
• Legacy-core extraction, migration cutovers, and mainframe release constraints remain a major delivery risk in this market.

The field breaks into four camps: full PAS vendors, pension-specialist administration/member platforms, dashboard connection providers and ISPs, and migration-heavy consultancies or cloud-modernization programmes. The proposed startup wins only if it becomes the trusted benefit-event abstraction layer that lands with less replacement scope than the suites above it. [40][43][47][49][50][51][52][53]

Why incumbents do not win by default

• Full PAS suites. Lumera, Keylane, Sapiens, and Bravura are strongest when the buyer is ready to modernize broad policy-administration scope, but that breadth is also why they do not automatically win a narrow dashboard/reporting/change-control wedge.
• Dashboard connection providers / ISPs. Connection providers help schemes reach the ecosystem and satisfy operational duties, but they do not inherently become the system-of-change for benefit-event logic or scheme-change simulation.
• Migration and consulting programmes. Consultancies and migration specialists already monetize legacy cleanup and programme delivery, so the startup must attach to their projects as a lower-risk control layer instead of assuming buyers will rip them out.
• Internal admin workarounds. Many schemes will first reach for spreadsheets, ETL patches, and administrator-led data remediation; the startup must prove materially better auditability, speed, and reuse than these internal fixes.

Benefit Event API Layer should start as a read-only shadow ledger for Dutch pension administrators running 500,000-3,000,000 legacy retirement policies through Future Pensions Act transition and dashboard-data exposure programs. The immediate pain is not replacing the core; it is producing auditable member, policy, and benefit-event data fast enough for dashboard, reporting, and rule-change deadlines without adding new spreadsheet reconciliation. The first product should ingest batch outputs and policy tables from one legacy book, map them into a canonical benefit-event model, and generate dashboard-ready extracts, reconciliation logs, and scheme-change simulations before any write-back workflow is attempted. The economic buyer is the COO, CIO, or head of policy-administration transformation already accountable for a named transition milestone, while actuarial and operations teams decide whether the output is trusted enough to use in production. Pricing should follow active policies live on the ledger plus one-time workflow activation fees, so the company can land through a paid pilot on one policy block and expand as more books and change workflows move onto the platform. The hard strategic choice is to avoid full PAS replacement, advisor tooling, and small-scheme selling until the company proves that a narrow overlay can launch one live compliance workflow in months. Research supports the timing through UK dashboard deadlines, Dutch transition work, and continued modernization funding, but it also shows high substitution risk from incumbents, ISPs, SIs, and internal ETL patches. Public competitor pricing and first-account implementation effort remain open questions, so the first 12-18 months should be run as a proof-of-deployment and proof-of-budget exercise rather than a scale-at-all-costs expansion.

Problem

• Large European pension and life administrators must expose trusted member, value, and policy data for dashboards, reporting, and transition programs, but legacy mainframes still encode benefit logic in COBOL, batch jobs, and undocumented tables.
• Every fee, scheme, or disclosure change becomes a risky project across ETL patches, spreadsheets, and manual reconciliations, while full PAS replacement is too slow and politically heavy for near-term deadlines.

Solution

• Build an audit-first shadow ledger that ingests legacy batch outputs and policy tables, translates them into canonical benefit events, and serves dashboard-ready APIs, regulatory extracts, and exception queues without replacing the core.
• Add a controlled scheme-change simulator on top of the same ledger so operations and actuarial teams can test fee, indexation, or benefit-rule changes before they touch the mainframe.

Why we win

• The wedge lands at the highest-pain seam, trusted benefit-event translation for mandated external data and rule-change workflows, rather than competing head-on as a full policy-administration suite.
• If the company captures legacy-rule mappings, reconciliation outcomes, and simulation history across multiple books, it builds a proprietary audit and migration corpus that ISPs, generic integrators, and internal ETL teams do not naturally own.

Milestones

flowchart LR
  Wedge[Dutch transition data wedge] --> MVP[Read-only shadow ledger MVP]
  MVP --> Proof[Live extracts with fewer reconciliations]
  Proof --> Expansion[Rule-change and book expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 5 target administrators confirm that dashboard or transition data exposure is a budget-worthy pain distinct from full PAS replacement.
• The first 3 pilots can ingest copied batch outputs and policy tables fast enough to produce trusted extracts within 120 days.
• At least half of paid pilots convert to production without requiring write-back control of the incumbent core.
• The same ledger can sell a second workflow such as scheme-change simulation or additional reporting within 12 months of the first production go-live.
• Migration consultancies, ISPs, or administrators generate at least 2 qualified partner-sourced pilots after the first lighthouse deployment.

Open diligence questions

• Which budget owner actually signs first, the transition program sponsor, the CIO, or the external administrator running the book?
• What minimum data package is required to deliver a trusted ledger for the most common legacy cores in the first 10 target accounts?
• How much of the dashboard or transition budget is already locked up by ISPs, SIs, or incumbent PAS vendors?
• Which workflow closes first in practice, dashboard extracts, Solvency II reporting, or scheme-change simulation?
• How much implementation work is needed before gross margins can approach 70%?

Model sanity

• Revenue engine. Base-case revenue is driven by roughly five active lighthouse administrators by Q4Y3 and a per-account ARR ramp toward about $2.0M as extra policy blocks and scheme-change workflows go live.
• Must go right. The two Y2 partner-sourced deployments need to convert into production quickly enough for the $115K-to-$165K monthly ARPU ramp to materialize without adding a large services bench.
• Model breaks if. If lighthouse starts slip and pricing lands near the ARPU downside case, cash low point compresses toward $0.7M before the company has next-round proof.
• Next-round proof. A Series A story is strongest once Q4Y2 shows 4-5 production administrators, partner-sourced wins, and implementation hours down about 30% versus the first pilots.

Scenarios

Sensitivity

flowchart LR
  Leads --> PaidPilots
  PaidPilots --> ProductionAdmins
  ProductionAdmins --> ExpandedPolicies
  ExpandedPolicies --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

Flags: Revenue per FTE is above typical SaaS benchmarks, so the model depends on very high ACV and partner-enabled delivery rather than a scaled direct implementation team. · The base case still needs six paid account starts across three years; if one of the Y2 or Y3 lighthouse adds slips, the sales-cycle sensitivity takes more than $0.5M out of year-three revenue. · Gross margin only reaches the 70% target if mapping templates and partner delivery absorb bespoke reconciliation work by H2Y3. · The downside case stays cash-positive but falls below a $1M cushion, so management should raise before the Q4Y2 milestone drifts materially.

• Long enterprise sales cycles. Pension and life-platform deals can stall behind board approvals, procurement, and incumbent SI politics. Mitigation: Start with a single mandated workflow like dashboard feeds, price for a fast pilot, and sell through implementation partners already inside the account.
• Integration complexity. Legacy policy books often contain fragmented product rules and poor documentation that can delay time to value. Mitigation: Build the product around repeatable ingestion patterns for common pension cores and begin with read-heavy use cases before introducing write-back workflows.
• Incumbent platform retaliation. Core vendors and system integrators may bundle adjacent modules or warn customers against a shadow-ledger approach. Mitigation: Position as a non-rip-and-replace compliance and change layer, prove coexistence with incumbent systems, and capture audit data the incumbent stack does not model well.