Launching Wallet-as-a-Service in the UK: Costs, Providers and Revenue Models

Choose your wallet model and launch approach

Wallet-as-a-Service (WaaS) supplies infrastructure for a branded financial product, from fiat accounts and payment APIs to blockchain wallets and signing. Before comparing providers, define one primary use case, target customers, launch countries, assets, funding methods and withdrawal routes.

Consumer wallets may prioritise simple payments and support; business wallets may need GBP transfers, approval workflows and accounting integrations. Marketplaces require buyer and seller journeys, balance allocation and payouts. These requirements should determine the provider shortlist.

Fiat safeguarding, crypto custody and key security are different arrangements. Stablecoins require their own asset and regulatory assessment. Labels such as embedded or non-custodial do not establish the actual funds flow or control model.

Select a delivery approach according to the features you need to own and the team available to maintain them:

A hybrid can combine your own customer experience with external financial services. Building software does not replace required permissions or partner arrangements. Also distinguish launching a customer-facing wallet from selling B2B WaaS infrastructure: the latter additionally needs tenant isolation, developer onboarding, programme administration and support commitments.

Establish UK regulatory responsibilities

Map who contracts with customers, receives funds, issues monetary value, executes payments and controls withdrawals. Payment services and e-money issuance are distinct activities; neither a wallet interface nor a supplier's authorisation determines your business's permissions. Establish whether you act as an institution, agent, e-money distributor or technology supplier. An EMI's payment-services agent must be registered through its principal; a distributor has a narrower role. Consult the FCA framework and perimeter guidance.

Own authorisation requires application preparation, governance, controls, applicable initial and ongoing capital, reporting and wind-down arrangements. Keep regulatory capital separate from operating expenditure and customer funds. Under a partner-led model, document the responsibilities retained by each party. The FCA's EMI application guidance explains the institution requirements.

For fiat wallets, allocate safeguarding, record-keeping, reconciliation and shortfall-resolution duties. The supplementary regime effective from 7 May 2026 requires in-scope institutions to maintain internal and external reconciliations at least once each reconciliation day, resolution packs, applicable audits and monthly FCA returns. Confirm exemptions and deadlines in the safeguarding guidance. Partner programmes must supply the records needed to support these controls. Explain to customers that safeguarding is not FSCS protection against the payment or e-money institution's failure.

Since 7 October 2024, eligible UK Faster Payments and CHAPS transfers have mandatory APP scam reimbursement protections, normally capped at GBP 85,000 per claim. Coverage includes individuals, microenterprises and qualifying charities, subject to scheme rules; overseas, cryptoasset and same-provider transfers are not automatically covered. Allocate reporting, investigation, customer communication, reimbursement deadlines and payout funding without overriding statutory or scheme duties. Distinguish APP scams from unauthorised payments. See the FCA's reimbursement guidance.

For crypto, assess custody and exchange activities separately. As at 5 November 2026, in-scope businesses require applicable MLR registration before operating, while promotions of qualifying cryptoassets to UK consumers need a lawful route. MLR registration is not general product authorisation or investment approval. Consult the FCA's registration guidance.

The new cryptoasset regime is scheduled to start on 25 October 2027, with an application period from 30 September 2026 to 28 February 2027. Existing registrations and permissions do not convert automatically. Assess new authorisation or variation requirements, transitional eligibility and implementation work using the FCA's preparation guidance.

The UK Travel Rule has applied since 1 September 2023. In-scope businesses must collect, verify and share prescribed transfer information as applicable, with procedures for missing data and jurisdictions that have not implemented the rule. Outsourcing does not transfer responsibility. See the FCA's Travel Rule expectations.

Assign accountable owners in a written responsibility matrix covering:

• Customer and business verification, beneficial ownership, sanctions, transaction monitoring and suspicious-activity escalation.
• Authentication, fraud, reimbursement, complaints and customer communications.
• Safeguarding or custody records, reconciliations, resolution packs, audits and regulatory reporting.
• Travel Rule information, exceptions and compliance suppliers.
• Incident response, outsourcing oversight, service changes and orderly termination.

Assess Consumer Duty where applicable; a B2B label does not automatically exclude relevant customers. Establish UK GDPR roles and agreements using the ICO guidance, and verify operational readiness before accepting live funds or assets.

Define the MVP and technical architecture

Build the MVP around one complete journey, including failure and recovery. For fiat, cover verified onboarding, a GBP balance, bank-transfer funding, an authorised payment and transaction history. For crypto, start with one asset and network, secure signing and tested recovery or export. Defer cards, lending and additional currencies unless essential; reconciliation, access controls and support belong in the first release.

For in-scope UK payments, assign responsibility for Strong Customer Authentication, including factors, challenges, validation and evidence. Document permitted exemptions and their conditions; small payments or business customers are not automatically exempt. Support challenges when exemptions fail, and test expired sessions and accessible alternatives. Follow the FCA guidance and UK technical standards.

Define permitted actions during onboarding, restrictions, freezes and closure. Distinguish login restrictions from transaction or asset restrictions, enforce them across interfaces and recheck queued payments before execution. Closure must resolve pending transactions, fees and disputes, preserve records and provide access to statements, support and remaining funds, subject to verification and legal restrictions.

Assign a source of truth for each balance and transaction, reconciling the application with provider or blockchain records. Use exact monetary arithmetic, balanced entries where appropriate and stable operation IDs. Make retries and duplicate or out-of-order events safe, enforce balance limits within controlled posting operations, and distinguish pending, posted and available funds.

Verify webhook signatures or equivalent authentication before processing. Validate signed timestamps where supported, deduplicate event IDs, protect and rotate secrets, and store events durably before acknowledgement. Recover missed events through APIs, reports or blockchain queries using the same idempotent processing path. Test outages, expired credentials and delayed delivery.

Schedule reconciliation of transactions, fees and balances, with named exception owners and escalation deadlines. Intraday checks and a full daily reconciliation may suit the MVP. Separately meet applicable safeguarding requirements, including internal and external reconciliations at least once each reconciliation day; application balance checks do not replace these controls. See the FCA guidance.

For crypto, define signing, recovery, network-fee and confirmation policies, including stalled transactions, reorganisations, wrong-network deposits and failed contract calls. A transaction hash does not establish finality, and application restrictions may not prevent a user-controlled wallet from operating elsewhere.

Protect credentials and signing authority according to the control model, separate production and test access, and log privileged actions. Set recovery-time and recovery-point objectives for each critical component. An illustrative operations-console target could be restoration within two hours with no more than fifteen minutes of lost case updates; financial recovery must still account for every accepted instruction and external movement.

Test restoration before launch, periodically and after material changes, including required secrets, signing recovery, missed events and external reconciliation. Require operational approval before resuming money movement. Release only when balances, fees, authentication, restrictions, event handling, reconciliation deadlines and recovery targets pass documented acceptance checks.

Compare providers against your product requirements

Start with mandatory requirements: supported customers, countries, assets, payment routes, funds-control arrangements and reporting. Treat these as pass-or-fail checks; price or optional features cannot compensate for an unsupported essential workflow. Confirm the contracting entity, permissions, included services and third-party dependencies.

Request evidence of complete customer journeys, API and sandbox behaviour, reconciliation reports, security assurance, incident history, recovery and exit arrangements. Compare fiat providers on account and payment capabilities; assess crypto infrastructure separately for signing, networks, recovery and transaction controls. Test delayed payments, rejected beneficiaries, duplicate notifications, lost responses and offboarding, adding signing and recovery failures for crypto.

Score preferences only after mandatory checks pass. For example, Providers A and B qualify, while Provider C is excluded because it cannot support the required withdrawal route. Agree weights before reviewing bids. The fictional scorecard below uses 1 for weak, 3 for adequate and 5 for strong; weighted points equal score / 5 × weight.

Record supporting evidence and test whether reasonable weight changes reverse the result. These scores illustrate a method, not rankings of named providers.

Request comparable 12-month GBP-only quotes covering 12,000 onboarding checks annually, 10,000 average monthly chargeable wallets, and monthly volumes of 20,000 inbound, 30,000 outbound and 5,000 internal transfers. Specify identical balances, payment values, peak throughput, support needs and assumptions for failed checks, retries, returns and manual reviews.

The hypothetical comparison below uses GBP and assumes platform minimums replace lower wallet and transaction charges. Other listed costs sit outside the minimum.

These are invented assumptions, not supplier prices or a complete operating budget. Obtain unit-rate breakdowns, confirm how minimums apply, and add applicable taxes, other suppliers and differing internal costs. Model adoption ramps and volume tiers; identify prefunding and restricted cash separately.

Translate service expectations into measurable contract terms. Illustrative negotiation targets include:

• Availability: 99.95% monthly uptime for specified APIs, with defined measurement, exclusions and remedies. API availability is distinct from payment completion.
• Critical support: 24/7 coverage, acknowledgement within 15 minutes and updates every 30 minutes, with agreed severity and escalation rules.
• Recovery: Restoration within two hours, documented data-recovery targets and evidence that accepted financial instructions remain accounted for.
• Changes: 90 days' notice of breaking API changes, a migration period and defined emergency exceptions.
• Exit: Routine machine-readable exports and a complete agreed export within five business days, specifying fields, history, security, fees and migration support.

These targets are examples, not universal standards. Distinguish documentation and demonstrations from contractual commitments, assign owners to material gaps and resolve them before selection.

Fiat wallet infrastructure: Modulr, Mangopay and Currencycloud

These providers serve different fiat-payment use cases. Suitability depends on customer eligibility, the contracted programme and enabled services. The comparison reflects public documentation reviewed on 5 November 2026.

Verify these details against Modulr's disclosures, Mangopay's UK notice, Currencycloud's disclosures and the current FCA Register. Confirm the actual contracting entity, account provider and customer terms; UK and EU/EEA arrangements are not interchangeable. Provider authorisation does not automatically cover your own activities.

Modulr: Account configurations depend on the agreement. Check its payment enablement rules and eligibility criteria, including incorporation, relevant permissions, financial-crime controls, financial viability and industry or jurisdiction restrictions. Its payments-clearing model requires an appropriately registered or authorised financial institution; minimum eligibility does not guarantee acceptance.

Mangopay: Test the complete purchase-to-payout and refund journey against its wallet model. Confirm verification requirements, chargeback exposure and the repudiation-wallet process. Its restrictions require additional assessment for activities such as remittance, crowdfunding and cryptoasset services, with exclusions within some categories. Check customer and country eligibility before integration.

Currencycloud: Confirm collection and payout routes, settlement deadlines and prefunding for each corridor. Its jurisdiction rules distinguish regulated and unregulated service models. The activity policy restricts FX speculation, cryptocurrency-derived transactions and cash-funded remittances; obtain acceptance of the intended funds flow in writing.

Request itemised proposals for the same usage scenario, covering setup, minimums, verification, accounts, payments, FX, refunds, disputes, support and exit. Separate settlement funding from fees. Unpublished minimums are unresolved terms, not evidence that none apply. Confirm safeguarding, onboarding responsibilities and service scope; these use-case assessments are neither rankings nor promises of a complete branded application.

Crypto-wallet infrastructure: Fireblocks and Privy

Evaluate Fireblocks and Privy against your blockchain, asset-control and operational requirements. Neither automatically replaces UK fiat infrastructure or the regulatory assessment of your service. This comparison, based on documentation reviewed on 5 November 2026, covers Fireblocks operator-managed WaaS and Privy's configurable wallets; confirm enabled features and contractual scope.

Fireblocks offers WaaS with MPC security, workspace policies and approval workflows for businesses managing client assets. Its embedded-wallet and separate custody offerings require their own assessment. Privy provides embedded wallets and server APIs with programmable ownership, including user-controlled, service-controlled and quorum-based configurations.

Validate Fireblocks' network support, Co-signer requirements and recovery tooling, alongside Privy's export workflow and access-recovery guidance. Test the actual configuration rather than relying on general portability claims.

Compare Fireblocks and Privy pricing using identical users, wallets, signatures, transaction values and support needs. Add gas, sponsorship, hosting and external compliance costs; entry plans are not complete launch budgets.

Separate native authorisation controls from compliance services:

• Fireblocks: Native policies govern actions; documented integrations include Chainalysis and Elliptic for KYT/AML and Notabene for Travel Rule. Confirm activation, coverage, subscriptions and fees.
• Privy: Native ownership, quorums and policies govern wallet actions. Integrated KYT and sanctions controls require confirmation of provider, coverage and package. Its screening guidance distinguishes denylists from risk scoring. The reviewed wallet documentation does not establish an included end-to-end Travel Rule service; specify this separately unless contracted.

For both, identify checks performed outside signing controls and distinguish included functions from separately licensed integrations or your own processes. Assign owners for customer verification, alerts, records and incomplete Travel Rule information. Address blocking alone does not detect all indirect exposure or replace a compliance programme.

Technical infrastructure does not determine the customer's legal custody arrangement:

• Operator-managed Fireblocks: If your business approves transfers and handles withdrawal requests, it may perform a custody role. Distinguish infrastructure provision from any separately contracted custodian.
• User-controlled Privy: Verify independent authorisation and export, including whether additional signers, administrators or recovery mechanisms can override user control.
• Service-controlled Privy: Holding the controlling key or quorum may make customers dependent on your business for access; assess the resulting custody obligations.

Document ownership, segregation, withdrawal rights, contractual counterparties and failure arrangements, including who can change policies, add signers, recover access or export keys. Labels such as MPC or non-custodial do not replace this assessment.

Test wallet creation, permitted and blocked transfers, screening outages and lost-authentication recovery. For service-controlled wallets, test separation of duties and suspension; for user-controlled wallets, test export, independent access and which policies cease to apply afterwards. Verify fiat on/off-ramps and additional compliance services separately unless expressly included.

Estimate launch costs and ongoing operating expenditure

Budget for the complete service: legal preparation, development, integration, testing, staffing, infrastructure, compliance, provider charges, acquisition and tax. Separate expenditure from business-funded liquidity, regulatory capital and customer safeguarding funds. Provider quotes should identify setup fees, minimums, usage, support and exit charges; confirm whether minimums replace or supplement usage.

The hypothetical example below covers a partner-led UK business wallet with GBP balances, bank-transfer funding, payments and transaction history. It excludes cards, FX, lending and crypto and assumes no separate institution authorisation is required, subject to confirmation of the arrangement and any agent registration. Allow four months for delivery, with two engineers budgeted at a combined GBP 15,000 monthly and separate integration and assurance work packages.

These are planning assumptions, not market benchmarks. The tax example assumes confirmed exempt financial supplies, no recovery of the specified input VAT and no additional VAT on remaining base costs. The contingency includes tax on its use. Software does not become exempt merely because it supports financial services; confirm treatment and recovery using HMRC's finance guidance and partial-exemption guidance.

For the first six operating months, assume:

• Growth: Active wallets increase from 1,000 to 10,000 as shown below, with start-of-month activation and no churn.
• Fixed costs: GBP 10,000 monthly for maintenance, product, operations, compliance and infrastructure, rising to GBP 13,000 in month 4 for an additional support and operations hire.
• Provider costs: The higher of GBP 2,000 monthly or GBP 0.50 per active wallet, plus separate variable costs of GBP 1 per wallet for verification, incremental support and expected losses.
• Acquisition: GBP 10 per newly activated customer, paid immediately, totalling GBP 100,000.
• Revenue: GBP 4 per active wallet monthly, collected one month later, with no bad debts.
• Liquidity: GBP 20,000 committed at launch, increasing by GBP 5,000 in months 3 and 5, without releases.
• Tax: Costs include applicable employer liabilities and irrecoverable VAT. Assume no output VAT under the specified exempt-supply scenario and no corporation-tax payment due within six months; this is timing, not exemption.

Cash amounts below are GBP thousands. Outflows include fixed, provider, variable and acquisition costs; liquidity additions are separate.

GBP 218,000 of outflows minus GBP 84,000 of receipts plus GBP 30,000 of liquidity produces GBP 164,000 of post-launch funding use. Adding the GBP 156,000 pre-launch allowance and a separate GBP 30,000 operating buffer gives a GBP 350,000 funding target, assuming full use of the delivery contingency.

At month 6, GBP 40,000 of revenue remains uncollected and GBP 30,000 remains committed to liquidity. Neither is available operating cash. Extend the forecast for continuing acquisition, tax, reserve changes and wind-down needs; this target applies only to the stated scenario.

For own authorisation, add application preparation, FCA application and annual fees, applicable levies, governance and assurance costs. Forecast initial and ongoing capital under the relevant institution requirements, allowing for losses. Capital is neither an expense nor necessarily a separate cash reserve: model the balance sheet to avoid overlapping allowances, and never fund the business with customer safeguarding money.

Stress-test low and high adoption, churn, verification failures, returns, fraud, delayed receipts and higher staffing or prefunding needs; add network-fee and recovery scenarios for crypto. Distinguish cash payments from accounting capitalisation and show payment dates, restricted amounts and assumptions requiring provider, regulatory or tax confirmation.

Choose revenue models and test unit economics

Match revenue to customer value: subscriptions for recurring features, transaction fees for payments, disclosed FX margins for conversion, and premium charges for reporting or controls. B2B WaaS platforms can charge for programme access and usage. Validate willingness to pay, retention and margins after delivery costs; customer wallets and B2B programmes have different sales cycles and economics.

Customer balances and payment volume are not revenue. Distinguish gross billing from retained revenue, exclude output VAT where applicable and deduct each provider cost only once. Interchange, balance-related income and crypto yield require separate contractual and regulatory assessment. Income lawfully retained by the business differs from interest paid to e-money holders: Regulation 45 prohibits issuers from awarding interest on e-money or benefits linked to its holding period.

In this example, an active wallet completes at least one customer-initiated payment during the month; registrations and logins alone do not qualify. Assume one wallet per customer. Include free transacting users with zero direct revenue, and separately account for inactive users who pay fees or incur costs. Reconcile these definitions with provider billing. For customers with multiple wallets, aggregate their economics before comparing contribution with acquisition cost.

Monthly contribution per wallet = retained revenue - variable servicing costs.

Operating break-even wallets = monthly fixed costs / positive contribution per wallet, rounded up.

Using the preceding budget, GBP 4 revenue minus GBP 1.50 variable costs gives GBP 2.50 contribution. Fixed costs of GBP 13,000 require 5,200 active wallets. At 10,000 wallets, GBP 40,000 revenue less GBP 15,000 variable costs and GBP 13,000 fixed costs leaves GBP 12,000 before acquisition and tax. This assumes no additional inactive-account revenue or costs.

The provider charges the higher of GBP 2,000 monthly or GBP 0.50 per wallet. Usage exceeds the minimum above 4,000 wallets, so the break-even calculation is consistent; below that threshold, model the minimum explicitly.

These are hypothetical scenarios with GBP 4 revenue per wallet. Apply cost increases at their actual thresholds, and do not add usage charges where a provider commitment replaces them.

Calculate customer acquisition cost (CAC) as attributable marketing, sales, incentives and unsuccessful acquisition spending divided by newly activated customers. Avoid counting onboarding costs again in servicing expenses.

Simple CAC payback = acquisition cost per customer / monthly contribution per customer.

GBP 10 CAC and GBP 2.50 monthly contribution imply four months' payback without churn or collection delays. This recovers acquisition spending before shared overhead and tax, not the entire business investment.

For lifetime contribution, sum expected monthly contribution weighted by cohort retention. With constant contribution, permanent month-end churn, no reactivation and no discounting, the simplified formula is:

Expected lifetime contribution = monthly contribution / monthly churn rate.

At 5% monthly churn, expected active lifetime is 20 months and contribution is GBP 2.50 / 0.05 = GBP 50, or GBP 40 after CAC, before overhead and tax. With first-month contribution and 95% subsequent monthly retention, cumulative contribution is GBP 9.27 after four months and GBP 11.31 after five. Cohort CAC payback therefore occurs in month 5; collection delays extend cash payback. Replace these assumptions with observed retention.

For a separate B2B example, GBP 3,000 retained monthly revenue less GBP 1,000 direct servicing costs gives GBP 2,000 contribution per client programme. GBP 30,000 shared costs require 15 comparable programmes; 20 generate GBP 10,000 before acquisition and tax. GBP 6,000 acquisition plus GBP 4,000 implementation costs, net of retained setup fees, take five months to recover after go-live. Include sales and implementation delays, payment terms, renewals, usage variation and client concentration.

Keep acquisition payback, operating break-even and launch-investment recovery separate. A sustained GBP 12,000 monthly operating surplus would recover the GBP 156,000 pre-launch allowance arithmetically in 13 months, excluding ongoing acquisition, tax, collection delays and liquidity changes. This does not recover the full GBP 350,000 funding target, which also includes operating funding, restricted liquidity and a buffer.

Track conversion, funded and transacting customers, retention, revenue, frequency and support demand by cohort. Include replacement acquisition costs when maintaining activity despite churn. Stress-test discounts, free-user mix, verification failures, fraud and network costs. Where Consumer Duty applies, assess fair value using the FCA's payments review.

Move from provider selection to pilot and scale

Assign named owners and deputies for Product, Engineering, Finance Operations, Compliance, Security and Support, with documented approval evidence. Keep engineering completion, provider onboarding and regulatory readiness as separate gates: a signed contract or working sandbox does not establish readiness for live funds.

For the partner-led GBP wallet, the following schedule is illustrative, subject to external approvals. The live pilot belongs to the post-launch operating period.

Before live activity, define the cohort, journeys, individual and aggregate exposure limits, operating hours and escalation contacts. Resolve essential external conditions and approve a process for changing limits.

Set measurable pilot gates, adjusted to the product and payment rails. These examples are operational targets, not regulatory standards or guarantees of future reliability:

• Coverage: At least four consecutive weeks and 1,000 eligible payment attempts, covering funding, transfers, returns, withdrawals and closure. Extend observation if coverage is insufficient.
• Reliability: Technical failures below 0.5%, with every accepted instruction resolved or assigned for investigation within the relevant rail deadline. Engineering owns the evidence.
• Reconciliation: All scheduled checks completed on time, no unexplained exception older than one business day and no unexplained customer-balance difference at expansion. Finance Operations owns resolution.
• Support: Meaningful first responses within four business hours for 90% of ordinary cases during published hours; critical-incident acknowledgement within 15 minutes through the agreed channel.
• Controls: No unresolved critical security findings or overdue complaint responses; demonstrated recovery without duplicate payments and tested closure and inaccessible-account procedures.
• Economics: Actual revenue and servicing costs support the forecast, with Finance explaining material variances.

Define measurement denominators, separate expected business rejections from technical failures and report overall customer completion. Track onboarding and time to first funded use. API acknowledgement is not payment completion; for crypto, also assess signing, confirmation delays, fees, reorganisations and recovery. A transaction hash alone does not establish settlement.

Handle complaints separately from ordinary support. Relevant payment-services and e-money complaints generally require a final response within 15 business days after the day of receipt. Only exceptional circumstances beyond the firm's control justify extension: send a holding response within the initial deadline, explain the delay and issue a final response within 35 business days. Follow the FCA time-limit rules.

Record receipt dates, classification, deadlines and responsible firms, preserving this information during transfers. Escalate deadline risks to the Complaints Manager, Compliance and provider. Where eligible, explain Financial Ombudsman referral for an unsatisfactory or overdue response, including the usual six-month deadline following the final response. See the Ombudsman's guidance; assess other complaint categories separately.

Immediately escalate shortfalls, compromised signing, duplicate payments or lost reconciliation data, pausing affected activity where necessary. The reconciliation target does not permit delayed investigation. Define pause authority, customer communications and restart approvals. Software rollback cannot reverse completed payments; reconcile actual balances and pending instructions before resuming.

Include customer closure and return of funds in routine offboarding and supplier-exit plans:

• Give required notices, explain withdrawals and stop new activity in a controlled sequence.
• Resolve pending payments, fees, disputes and chargebacks; document and review any retained amounts.
• Verify entitlement and destination, return permitted funds and reconcile balances, with owned review of legal restrictions.
• Provide alternative verification when login or the original withdrawal account is unavailable; assign owners and review dates to unresolved balances.
• Preserve required records, statements, complaints and dispute handling after app closure.
• Test usable exports, balance reconciliation and migration or orderly closure before relying on supplier exit.

Log findings, corrective actions and approval decisions. Retest material fixes and gather further evidence where needed. Expand only when money movement, balances, support and economics are reliable; reassess capacity and contractual coverage for new services, currencies or networks. Retain pause controls and periodically test continuity and exit arrangements.