PLAYBOOK · BANKING · MARKETPLACE
Banking-as-a-Service for Multi-Vendor Marketplaces
vIBANs, safeguarding, split payouts
Marketplaces that hold buyer funds before paying sellers are operating in regulated territory whether they planned to or not. Banking-as-a-Service lets you run seller wallets, named virtual IBANs and split payouts without becoming a licensed payment institution. This playbook covers the regulatory drivers, the operating models, and what good looks like in 2026.
Multi-vendor marketplaces sit in an awkward regulatory position. The moment your platform collects a buyer's payment and holds it before paying a seller, you are arguably operating as a payment institution under PSD2 in the EU/UK — even if you never thought of yourself that way. Banking-as-a-Service (BaaS) is how most marketplaces solve this without becoming a licensed payment institution themselves: the underlying EMI or bank takes the regulatory load, while your platform gets the wallet, IBAN, and split-payment infrastructure it needs to operate.
Why marketplaces can't use generic business banking
If you take buyer funds into your own corporate bank account and then transfer the seller's share onward, you are handling third-party money. Under PSD2 (and the UK PSRs 2017), that activity is regulated. The 'commercial agent exemption' that marketplaces historically relied on has been tightened by both the EBA and the FCA — regulators now expect platforms with discretion over the transaction (price-setting, dispute handling, refund rights) to either obtain authorisation or partner with a regulated institution that does. A standard corporate account cannot lawfully commingle thousands of sellers' funds, cannot issue sub-accounts in sellers' names, and offers no safeguarding wrapper.
What marketplace-grade BaaS actually delivers
- Named virtual IBANs (vIBANs) per seller, so buyer funds settle directly into the seller's regulatory wrapper rather than your operating account
- Safeguarding of held balances under EMI rules (UK EMRs 2011 / EU EMD2) — funds are ring-fenced from the BaaS provider's insolvency
- Programmatic KYB and KYC onboarding for sellers via API, including UBO checks, sanctions screening, and ongoing monitoring
- Split-payment logic at settlement: platform fee, VAT/tax withholding, seller payout, and reserve all calculated in one instruction
- Multi-currency wallets so cross-border marketplaces don't force sellers to bear FX or open foreign accounts
- Payout rails (SEPA Instant, Faster Payments, SWIFT, local ACH) directly from the seller's wallet to their nominated external account
Two operating models — pick before you build
| Model | How it works | Best fit | Trade-off |
|---|---|---|---|
| Agent of the EMI/PI | You operate as a registered agent under the BaaS provider's licence. They safeguard funds; you handle the front end. | Marketplaces under ~EUR 50m GMV, or pre-Series B, who want speed. | Brand sits behind the provider's name on statements; ongoing oversight by the principal. |
| Embedded BaaS via API only | Provider supplies vIBANs, wallets and payouts. You sign your own terms with sellers; provider is disclosed. | Mid-market marketplaces who want their own brand on receipts and direct seller relationships. | More compliance load on you — onboarding, complaints, AML monitoring. |
| Hybrid (licence-as-a-service) | Provider gives you a dedicated programme inside their licence with bespoke flows and risk parameters. | Marketplaces processing > EUR 100m GMV who haven't decided whether to seek their own PI/EMI authorisation. | Higher minimums and longer integration; effectively a stepping stone to full licensing. |
Compliance touchpoints you cannot delegate
- Seller KYB depth — marketplaces underestimate how much UBO documentation regulated EMIs require; sole-trader sellers in low-tax jurisdictions are increasingly refused without enhanced due diligence
- Transaction monitoring rule-sets — your platform usage data (refunds, dispute ratios, login geo) needs to feed the provider's AML engine, not just sit in your product DB
- Safeguarding reconciliation — daily reconciliation between platform ledger and the safeguarding account is a regulatory requirement under FCA SUP 16; gaps trigger Section 166 reviews
- Complaints handling — if you operate as an agent, complaints about the payment service still flow to the principal EMI and count against their regulatory record
WORTH KNOWING
The FCA's 2023 'Dear CEO' letter on safeguarding has made EMIs far more cautious about onboarding marketplace programmes. Expect 8-16 weeks of due diligence for any marketplace with > EUR 20m annualised GMV, and a written safeguarding attestation as part of the deal. Providers will also want sight of your card acquirer's chargeback flow, because clawbacks have to land somewhere in the wallet structure.
Cost structure and what you need before approaching providers
| Cost line | Typical structure | What drives it |
|---|---|---|
| Programme setup | One-off, mid-five to low-six figures | Legal, integration, agent registration, compliance review |
| Per-seller onboarding | Per-KYB fee, often tiered by entity type | UBO complexity, jurisdiction, document verification |
| Per-vIBAN | Monthly maintenance per active IBAN | Whether the IBAN is named, dormant fees, country of issue |
| Transaction fees | Per-transfer flat fee plus FX spread | Rail used (SEPA Instant cheapest, SWIFT highest), currency pair |
| Safeguarding reserve | Percentage of float, sometimes interest-shared | Provider's own capital requirements, your risk profile |
- A written description of money flow showing buyer funds, holding period, fee deduction and seller payout — providers ask for this on the first call
- Annualised GMV, average transaction value, seller count, and projected growth — used to size the safeguarding programme
- A seller-side AML policy (even a draft) covering onboarding, sanctions, ongoing monitoring and exit
- A view on whether sellers are consumers, microbusinesses or larger entities — this changes the licensing exemptions available
- Clarity on geography: EEA-only marketplaces have far more provider choice than those onboarding sellers from FATF grey-list countries
From first conversation to live payouts, expect 12-20 weeks for an embedded BaaS programme — roughly four to eight weeks of provider due diligence, four to six weeks of API integration and UAT, and two to four weeks of staged go-live with a capped seller cohort. Marketplaces handling adjacent high-risk goods should add another six to eight weeks for risk committee approval. The failure modes we see most often: building on a provider that doesn't issue named vIBANs (sellers see the marketplace as payer of record and tax/accounting breaks at the seller end); choosing a provider with no payout coverage in your seller geography, forcing expensive SWIFT routing; underestimating chargeback flow — when a buyer disputes a card payment, the BaaS wallet must absorb the clawback even though the seller has already been paid; and treating BaaS as 'just a bank account' and skipping the safeguarding ledger reconciliation work, usually surfaced at year-one audit.
HOW ICETREE APPROACHES IT
Our approach for merchants in this combination.
- We map your money flow against PSD2/PSRs first and tell you honestly whether you need BaaS, an agent arrangement, or your own licence
- We shortlist EMIs from our 50+ partner network based on named vIBAN capability, payout geography, and appetite for your seller mix
- We pre-qualify your programme against safeguarding and KYB requirements before introductions, so due diligence runs in weeks not months
- We coordinate the card acquiring side in parallel — chargeback flow into BaaS wallets only works if both sides are designed together
- Free to merchants — our partners pay placement fees, so our incentive is matching you to a programme that actually goes live and scales
FAQ
Common questions answered.
Want IceTree on your side?
Run the Approval Predictor for a 2-minute estimate of your acquirer fit, expected reserve range, and what to prepare — specific to and .