On this page
In brief
- Define the wallet's users, paying customers and legal service model before monetisation, since software-only, sponsored and directly authorised arrangements create different duties and costs.
- Choose subscriptions, payment fees, FX margins or premium features that fit customer needs, treating interchange and other revenue shares as contract-dependent rather than automatic income.
- Price clear packages with defined billing events, allowances, failure treatment and cancellation terms, testing both customer value and the margin remaining after provider charges.
- Budget for setup, launch assurance, fixed operations, usage, exceptions and losses while separating liquidity requirements from expenses and avoiding double-counted minimum commitments.
- Calculate contribution and operating break-even using retained revenue and variable costs for the same active customer cohort, distinguishing these from recovery of launch investment.
Define Your Wallet Model and UK Regulatory Responsibilities
A wallet revenue model starts with identifying the user, the paying customer and the legal service being supplied. A consumer wallet, an SME expense wallet and a marketplace balance service can use similar software while having different purchasing decisions, transaction patterns and responsibilities. White labelling changes the brand customers see; it does not grant permission to issue e-money or provide payment services.
Wallet proposition | Who uses it | Who may pay |
|---|---|---|
Consumer | Individuals making transfers or managing spending. | The individual, a sponsoring business or another contractual customer, depending on the proposition. |
SME | Finance teams, business owners and authorised employees. | The business purchasing payment or spending-management functionality. |
Marketplace | Buyers, sellers and platform operations teams. | The marketplace or participating sellers under the agreed commercial model. |
Specify whether the wallet stores value, merely displays a balance held elsewhere, or initiates payments from another account. That distinction affects the service scope and prevents a software subscription from being confused with the provision of a regulated financial product.
The operating arrangement typically falls into one of three categories:
- Software-only provision: A supplier provides technology to an organisation that supplies, or separately arranges, the financial service. The software contract does not itself establish an issuer or account provider.
- Sponsored programme: A bank, payment institution or e-money institution supplies agreed services through a partner arrangement. Payment-institution authorisation alone does not permit e-money issuance; an e-money wallet requires an issuer with the relevant permissions, such as an appropriately authorised bank or e-money institution. Your role may involve distribution, outsourced operations or a registered agency relationship, depending on the activities.
- Direct authorisation: Your business seeks the relevant permissions and operates the regulated service, with the governance, capital, reporting and controls that entails. Buying white-label software does not replace this process.
Map each money flow to a named legal entity. Identify who issues e-money, provides payment services, receives and holds funds, contracts with the customer and performs KYC/AML checks. Also allocate transaction monitoring, reconciliation, complaints and customer support. Tasks can be contracted out, but the regulated entity's obligations do not disappear, and the branded business must assess duties arising from its own activities. The FCA's payment-services and e-money guidance sets out the relevant regulatory perimeter.
For an e-money wallet, customer value is a claim on the issuer, not a bank deposit in the customer's name. Relevant funds must be safeguarded under the applicable requirements. Safeguarding is distinct from FSCS deposit protection: it does not provide FSCS compensation for failure of the non-bank issuer. Customer disclosures should accurately describe the arrangement, as explained in the FCA's guide to payment providers.
These choices determine which revenue your business can retain and which service costs it must fund. Establish the contractual customer, financial provider and operational responsibilities before selecting subscriptions, payment charges or other monetisation methods.
Choose Revenue Streams That Fit Your Customers
Start with the customer who benefits from the wallet and the party willing to pay. In a consumer product, these may be the same person. An SME may pay for employee controls, payment approvals and accounting integration, while a marketplace may fund the wallet to improve seller payouts or charge sellers for specific services. A revenue stream should support that use case rather than depend on customers encountering avoidable friction.
Revenue stream | Where it can fit | What determines retained revenue |
|---|---|---|
Subscription or licence fee | SME tools, premium consumer features or a wallet programme supplied to another business. | Paid adoption, retention, included usage and any platform or sponsor revenue share. |
Transfer or payout fee | Clearly defined domestic, international or marketplace payment services. | Chargeable transactions after waivers and refunds, less agreed pass-through costs and partner shares. |
FX margin | Customers regularly converting currencies for genuine cross-border needs. | The realised customer spread after execution pricing, partner sharing and relevant adjustments. |
Card interchange share | A wallet with a separately supported card-issuing programme. | Eligible card spending, the issuer agreement, applicable interchange rules and programme charges. |
Premium operational features | Business users needing additional reporting, approval controls or service levels. | Willingness to pay relative to the incremental cost of delivering and supporting the feature. |
Distinguish a payment fee from the amount transferred. A GBP 500 transfer with a GBP 1 fee does not generate GBP 501 of wallet revenue. Likewise, customer balances are liabilities or funds held under the relevant arrangement, not operating income. Confirm the accounting presentation of partner revenue shares and pass-through charges with finance.
Interchange needs particular care. It is a payment between the acquiring and issuing sides of a card transaction, not a fee that every wallet operator automatically receives. Any share for the branded programme depends on its issuing agreement. The Payment Systems Regulator's interchange guidance also explains that caps apply to specified consumer card transactions. Forecast the contracted net share for the actual transaction mix, not the headline interchange amount.
For FX, record the rate offered to the customer, the execution rate and the provider's share. Conversion volume alone does not establish profitability. For marketplace wallets, separate payment-service income from any existing marketplace commission so the same revenue is not credited to both business cases.
Select one core revenue stream and a small number of complementary ones. Test whether consumers value a paid feature, whether SMEs save enough operating time, or whether sellers benefit from the payout service. Treat interest on safeguarded balances or additional financial products as separate opportunities requiring verified contractual and regulatory treatment, rather than assumed base-case income. The resulting revenue model should explain who pays, what triggers the charge and what the business actually retains.
Set Customer Pricing and Packages
Translate the revenue model into a tariff customers can understand before they commit. Define the billing unit first: an individual wallet, a business account, an active user, a payment instruction or a completed transaction. These units are not interchangeable. A business with twenty employee wallets may reasonably expect one programme subscription, while its provider may charge your business per wallet.
Choose a structure that matches usage. Pay-as-you-go can suit occasional customers, subscriptions can suit frequent users who value predictable bills, and a hybrid can combine a monthly allowance with additional usage charges. Keep the number of packages small and tie upgrades to clear benefits such as approval workflows, reporting or a greater payment allowance.
The following example illustrates package mechanics only. These are hypothetical customer prices, not market rates or provider quotations, and they cover only the stated domestic-transfer service. Monthly fees and transfer allowances apply per business account, with transfers pooled across its employee wallets.
Illustrative plan | Monthly fee per business account | Included transfers per business account | Additional transfer fee |
|---|---|---|---|
Pay-as-you-go | GBP 0 | None | GBP 0.50 |
Business | GBP 10 | 30 per month | GBP 0.20 |
At ten transfers, the example customer pays GBP 5 on pay-as-you-go or GBP 10 on Business. At fifty transfers, the bills are GBP 25 and GBP 14 respectively. Showing these usage examples helps customers choose a suitable package. To assess whether either package creates an unsustainable subsidy for heavy users, compare retained revenue at each usage level with the corresponding payment-processing, account-maintenance and support costs, including provider charges for individual employee wallets.
- Define the charging event: State whether a fee applies to a submitted, accepted or completed payment and how failures, returns and refunds are treated.
- Explain allowances: Specify the billing period, eligible transaction types, pooled usage, rollover rules and overage rate.
- Make FX transparent: Explain the reference or quoted rate, any separate conversion charge and what the recipient is expected to receive.
- List other relevant charges: Identify optional cards, international transfers or premium support separately, with any applicable tax treatment made clear.
- Document contract changes: Establish cancellation, renewal, plan-switching and price-change procedures consistent with the applicable terms and requirements.
Assess affordability and value across customer groups, including users who transact infrequently or encounter exceptions. For products within Consumer Duty scope, the FCA's payments review expects consideration of benefits, limitations and the expected total customer price. A tariff being cheaper than competitors is not, by itself, evidence of fair value. Fees such as e-money redemption charges also need separate legal review rather than being added as unrestricted revenue opportunities.
Test the proposed tariff with representative customers and transaction histories. Track the effective price paid, paid-plan conversion, cancellations, fee complaints and usage distribution. Review partner revenue shares and contracted charges before approving a discount. A successful package gives the customer a clear reason to buy while leaving sufficient margin to operate the promised service.
Calculate Setup and Operating Costs
Build the white-label wallet budget around the services your business will actually operate. A software licence may cover the interface and selected integrations while leaving onboarding operations, reconciliation, fraud management and customer support with your team. A sponsored programme may bundle some regulated services into platform fees or revenue sharing. Direct authorisation creates a different cost base and capital requirement. Compare the complete responsibility split, not just the headline licence price.
Cost category | Typical budget items | How to model it |
|---|---|---|
Setup and implementation | Discovery, branding, legal review, configuration, integrations, data migration and reconciliation design. | One-off cash commitments tied to defined deliverables and acceptance criteria. |
Launch assurance | Security testing, payment-flow testing, training, production readiness and contingency. | Budget for both initial testing and remediation before launch. |
Customer acquisition | Launch campaigns, ongoing marketing, sales activity, referral incentives and acquisition partnerships. | Planned spending by month and channel, linked to expected activated customers, including acquisition needed to replace churned customers. |
Recurring fixed costs | Licence or sponsor commitments, cloud services, maintenance, compliance, finance and support capacity. | Monthly costs that remain even when customer activity is low. |
Usage-based costs | KYC or KYB checks, screening, transfers, FX execution, card services and additional infrastructure usage. | Actual charging units multiplied by expected volumes, with contractual tiers and minimums. |
Exceptions and losses | Manual reviews, failed payments, disputes, refunds, fraud losses, applicable APP scam reimbursement costs and investigation work. | Observed or explicitly assumed event rates and the cost or exposure per event, reflecting the programme's contractual allocation of costs. |
Check whether monthly minimums are additive charges or credits against usage. For example, a GBP 2,000 minimum credited against GBP 3,000 of eligible usage produces a GBP 3,000 charge, not GBP 5,000. Confirm which fee categories count towards that minimum and whether the unused commitment expires. Also identify fees for dormant accounts, failed verification attempts, additional environments, support upgrades and contract exit.
For UK payment services within scope of authorised push payment (APP) scam reimbursement requirements, budget for the programme's reimbursement exposure and claims-handling costs. Confirm which regulated provider is responsible for meeting the applicable requirements and how the programme agreement allocates costs between that provider and your business, including any charges passed through to you. Contractual cost allocation does not remove the provider's regulatory obligations. The PSR's APP fraud reimbursement guidance explains the relevant protections.
An illustrative setup budget might allocate GBP 15,000 to discovery and legal preparation, GBP 45,000 to implementation and integration, and GBP 20,000 to testing and launch readiness. That totals GBP 80,000; a 20% contingency brings the funding allowance to GBP 96,000. These are modelling assumptions, not a market estimate or supplier quotation. Customer-acquisition spending is additional to this illustrative setup allowance.
For operating expenditure, assume GBP 18,000 per month in fixed costs and GBP 2 per active wallet in variable monthly costs. At 8,000 active wallets, operating expenditure is GBP 34,000 per month before additional customer-acquisition spending. The blended GBP 2 must be supported by a transaction and support mix; it should not be assumed constant if heavier usage changes the underlying charges.
Keep liquidity and restricted cash separate from expenses. Settlement prefunding, contractual collateral and applicable own-funds requirements affect funding needs without necessarily being immediate profit-and-loss charges. Relevant customer funds are not available to finance the business's own operations; the FCA's safeguarding rules address their protection.
Prepare a month-by-month cash forecast covering provider payment dates, recruitment, launch delays, customer-acquisition spending and the adoption ramp. Include acquisition spending both to grow the customer base and to replace customers lost through churn, alongside applicable APP scam reimbursements and their payment timing. Include tax and foreign-currency effects where applicable, and avoid double-counting partner charges already deducted from retained revenue or acquisition costs already included elsewhere in the budget. The result should show both the cost of operating the wallet and the cash required to reach a sustainable activity level.
Model Unit Economics and Break-Even
Build the model around active, revenue-generating customers rather than registered wallets. Define active consistently, for example as a customer completing a qualifying transaction during the month. Track paid subscriptions separately where a customer can remain billable without transacting. For an SME or marketplace programme, calculate economics at the business-account level as well as per wallet so employee or seller accounts do not distort the denominator. Include the costs of inactive and non-paying customers even when they are excluded from the revenue-generating customer count.
Estimate retained revenue from subscriptions, eligible transaction fees, FX margins and any contracted interchange share. Deduct refunds, discounts and partner shares consistently. Then identify variable costs for the same customer cohort and period, including payment processing, onboarding, support and expected losses. A cost already deducted in arriving at retained revenue must not be deducted again.
For a simple illustration using the earlier pay-as-you-go tariff, assume each business account has one active wallet and completes ten chargeable transfers per month at GBP 0.50 each. This produces GBP 5 monthly revenue per active wallet. Assume no discounts, refunds or partner revenue shares in this example, with processing charges included in variable costs. For a mix of plans or multiple wallets per business account, calculate total retained revenue from account-level subscriptions and chargeable activity, then divide by the corresponding active-wallet count.
Contribution per active wallet = retained monthly revenue per active wallet - variable monthly cost per active wallet
Using illustrative retained revenue of GBP 5 per active wallet and variable costs of GBP 2, contribution is GBP 3 per wallet, or 60% of retained revenue, before replacement acquisition and costs attributable to inactive or non-paying customers.
Assume monthly fixed operating costs of GBP 18,000 and a further GBP 1,000 per month for maintaining and supporting inactive or non-paying customers, excluding costs already counted elsewhere. Also assume 2% monthly customer churn and GBP 30 to acquire each replacement activated customer. With one active wallet per customer in this example, maintaining a stable customer base requires replacement acquisition spending of GBP 0.60 per active wallet per month: 2% multiplied by GBP 30.
Operating break-even active wallets = (monthly fixed operating costs + monthly costs of inactive and non-paying customers) / (contribution per active wallet - replacement acquisition cost per active wallet)
Under these assumptions, operating break-even is GBP 19,000 divided by GBP 2.40, or approximately 7,917 active wallets, rounded up. This formula assumes a stable customer base, a constant replacement acquisition cost per active wallet and an unchanged monthly cost for inactive and non-paying customers. These assumptions describe a planning scenario, not a predicted commercial result.
Scenario | Active wallets | Monthly retained revenue | Monthly active-wallet variable costs | Monthly replacement acquisition spending | Result after GBP 18,000 fixed costs and GBP 1,000 inactive and non-paying customer costs |
|---|---|---|---|---|---|
Lower adoption | 5,000 | GBP 25,000 | GBP 10,000 | GBP 3,000 | GBP 7,000 loss |
Base activity | 8,000 | GBP 40,000 | GBP 16,000 | GBP 4,800 | GBP 2,000 surplus |
Higher adoption | 12,000 | GBP 60,000 | GBP 24,000 | GBP 7,200 | GBP 9,800 surplus |
The table assumes unchanged prices, customer mix, churn, acquisition efficiency and fixed capacity. It includes acquisition spending to replace churned customers; acquisition spending to grow beyond each stated activity level is additional. In practice, additional support staff, provider tiers, a growing inactive customer base or higher fraud exposure can change the result. If contribution before replacement acquisition falls from GBP 3 to GBP 2, the adjusted contribution becomes GBP 1.40 and break-even rises to approximately 13,572 active wallets. If adjusted contribution is zero or negative, additional volume will not cover the remaining costs without a change in pricing, costs or customer mix.
Separate operating break-even from recovery of the launch investment. At a constant GBP 2,000 monthly surplus, recovering the illustrative GBP 96,000 setup budget takes 48 months after reaching the base activity level, before tax, acquisition spending for further growth and other cash movements. The adoption ramp, initial customer-acquisition spending and earlier operating losses extend total cash payback.
Measure customer acquisition cost using the cost of acquiring activated customers, not just leads or registrations. With GBP 30 acquisition cost and GBP 3 monthly contribution, simple acquisition payback for an individual customer is ten retained customer-months before fixed overhead allocation. This individual-customer calculation is separate from the programme-level replacement acquisition allowance above. Customers leaving earlier may never repay their acquisition cost. Use cohort retention and observed contribution to estimate lifetime value rather than assuming every wallet remains active indefinitely. Allocate onboarding and acquisition expenses consistently so the same cost is not counted twice.
Review low, base and high scenarios for activation, churn, transaction frequency, FX usage, verification failures and support demand. Recalculate inactive and non-paying customer costs as those populations change, and distinguish acquisition spending for replacement from spending for growth. Maintain a separate cash forecast for settlement timing, prefunding and reserves. A viable wallet should demonstrate positive customer contribution, sufficient scale to cover operating capacity and a funded route through the period before cash break-even.
Independent research
Ask AI whether Framnex fits your business.
Research Framnex with your preferred AI assistant and see where the platform may fit your client base, product and launch model.
The prompt will be prefilled. Review it before sending.