Embedded finance companies – and where embedded benefits fit
· Roland Völkel
Summary
- An embedded finance company provides a regulated financial capability – payments, accounts, cards, credit, insurance, payroll, or benefits – as an API that a non-financial platform embeds in its own product.
- The useful sorting criterion is not the product name but the obligation the provider absorbs: its own license, a sponsor bank behind it, or software only, with the license left to you.
- Names that recur across the categories: Stripe and Adyen in payments, Solaris and Swan for accounts in Europe, Marqeta and Lithic in card issuing, Plaid, Tink and Qwist in banking data, Check and Gusto Embedded in US payroll.
- Benefits does appear as a category in these directories, but in the American sense – health, retirement, commuter and wellness plans – where the infrastructure problem is carrier connectivity, and Noyo and Ideon are the answers.
- In Germany the regulated core of employee benefits is payroll tax law, not banking law: receipt-level checks, monthly payroll tax files, and values that change every year. That keeps the benefits row of a European list thin, with Palary and Hrmony Embedded as the German entries.
What an embedded finance company actually provides
An embedded finance company provides a regulated financial capability – payments, accounts, cards, credit, insurance, payroll, or employee benefits – as an API that a non-financial platform puts inside its own product. The platform keeps the interface and the customer relationship. The provider carries the license, the operational compliance work, or both. If the category itself is new to you, start with what embedded finance is and come back here for the vendor map.
Which means the name of the product tells you very little. Two vendors both say "cards" and mean entirely different divisions of labor: one holds the issuing license and the liability, the other sells you software and expects you to bring your own regulated partner. Sort by the obligation, not by the label.
The categories, and who shows up in them
The examples below are illustrative, taken from the providers' own public product descriptions. No ranking, no completeness – directories like the Open Banking Tracker and the Apideck landscape maintain inventories in the hundreds. What matters here is the shape of each category.
| Category | What your platform can offer | Where the regulated part sits | Publicly known providers |
|---|---|---|---|
| Payments and acquiring | Checkout, payouts, marketplace splits | Provider is the regulated payment institution | Stripe, Adyen |
| Banking-as-a-service | Accounts, IBANs, transfers | Provider's own license, or a sponsor bank behind it | Solaris (own German banking license), Swan (EMI, France), Unit, Synctera, Treasury Prime (US sponsor-bank model) |
| Card issuing | Branded debit, credit or prepaid programs | Provider plus scheme and issuing bank | Marqeta, Lithic, Highnote, Galileo |
| Lending and B2B BNPL | Working capital, invoice terms, installments | Provider or its funding bank underwrites | Banxware, Billie, Mondu, Kanmon, Parafin |
| Banking data and open finance | Account linking, income and risk checks | PSD2 licensing sits with the provider | Plaid, Tink, Qwist (built from figo and finAPI) |
| White-label banking software | A brandable banking product | With you – software layer only, the license comes from elsewhere | Crassula, Mambu, SDK.finance |
| Embedded insurance | Coverage offered at the point of sale | Carrier and underwriter behind the API | Varies strongly by line of business and market |
| Embedded payroll | Payroll runs and tax filing inside your product | Provider's tax engine and filing obligations | Check, Gusto Embedded, ADP Embedded, Salsa, Zeal |
| Embedded benefits | Employee benefits as modules in your product | Payroll tax handling with the provider, card and payment layer via a licensed partner | Noyo, Ideon (US, benefits data and enrollment); Palary, Hrmony Embedded (Germany, payroll-tax benefit modules) |
Two things stand out once the table is on the page. Payments and banking are crowded, mature, and well documented. Payroll and benefits are recent, and their providers are mostly single-market: Check, Gusto Embedded and Zeal serve the United States, Salsa adds Canada. Geography is not a footnote in this part of the stack – it is the product.
The questions that separate providers
Five questions do most of the work in a first call, and none of them are about API design.
Whose license, and whose liability. Own license, sponsor bank, or software only. This determines what happens when an audit or a regulator arrives, and it is the answer most likely to be blurred in a pitch.
Which jurisdictions, concretely. Not "Europe" but which countries, and what breaks in the second one. Anything touching payroll or tax is country-specific by construction.
Who owns the UI and the customer. White-label with your branding and your support flow, or a redirect that hands your user to someone else's screen.
What the commercial model does to your margin. Per user, per active module, revenue share, platform fee – and whether you set the end price.
Who answers the second-level questions. Your support team will receive tax and eligibility questions on day one. Either the provider takes them or you train for them.
Where these lists get thin: benefits
Benefits already exists as a category in embedded finance directories. The definition, though, is American: health insurance, retirement, commuter and wellness plans distributed through HR and payroll platforms. The infrastructure problem there is carrier connectivity, which is what Noyo and Ideon sell – one API into the insurance carriers instead of a file feed per carrier.
In Germany the same word points somewhere else entirely. There is no carrier to connect to. A meal allowance is valued with the official non-cash benefit value set by the SvEV – €4.57 per main meal in 2026 – plus a tax-free employer top-up of €3.10, capped at €7.67 per working day. A voucher or benefits card runs on the monthly €50.00 exemption threshold for non-cash benefits (§ 8 (2) sentence 11 EStG) and qualifies only if it is granted on top of regular pay (§ 8 (4) EStG). Exceed the threshold by a cent and the full amount becomes taxable.
Operationally that means receipt-level checking, monthly payroll tax files that have to survive an audit, and values that move: the meal figures were €4.40 and €7.50 in 2025, €4.57 and €7.67 in 2026. Nothing here resembles a card program, and none of it is banking law. That is the actual reason the benefits row of a European embedded finance list stays thin – the regulated core sits in payroll tax law, outside what a BaaS provider or an issuer processor builds. The mechanics of that difference are the subject of embedded finance vs. embedded benefits; the category itself is defined in what are embedded benefits.
Thin is not empty. Palary describes itself as financial infrastructure for HR tech: card issuing and payment processing through a licensed EMI partner, benefit logic on top, available API-first or as a white-label portal, with guud, Regional Hero and HR Benefit named as platforms running on it. Hrmony Embedded arrives at the same row from the operations side.
Where Hrmony Embedded sits
Hrmony has run these benefits as a direct product in Germany since 2015 and offers the same engine behind an API: Meal, Voucher, Health, Mobility, Internet and Benefit Card as modules in your product, with your branding and your customer relationship. Receipt checking and the monthly payroll tax reporting files sit on our side; for the Meal module, Hrmony also takes on liability for the receipts it checks. The module set and the integration path are on the Hrmony Embedded overview.
If you are building the vendor shortlist, keep the two halves of the table apart. Payments, accounts and cards are a licensing question. Payroll and benefits are an operations-and-tax question. Providers that are good at the first are rarely built for the second.