White-Label Neobank Costs in the UK: Launch, Run and Break Even

White-Label Neobank Costs in the UK: Launch, Run and Break Even

Launching a white-label neobank in the UK costs more than a branded app. Let's examine setup fees, ongoing charges and break-even assumptions to assess the funding your business needs before shortlisting providers.

Launch and operating costs: building your total budget

A white-label neobank budget covers a financial product and its operations, not just a branded app. Define the customer segment, account type, payment rails, card programme and service responsibilities. Deposit and e-money products may look similar but require different partners, contracts and budgets.

Model launch, fixed and usage-based costs monthly over 12 and 36 months. Compare proposals using identical scope and start dates: project approval, contract signature or live launch. Include preparation costs even when supplier quotes omit them.

Use average billable accounts and account-months, not only year-end customer numbers. Include failed verification attempts, replacement cards, chargeable dormant accounts and payment returns. Distinguish active users, accounts, cards and applicants so pilot and rollout scenarios use comparable units.

The expenditure budget equals launch costs + fixed charges + usage charges + irrecoverable VAT + customer acquisition and other excluded commercial costs + contingency. Apply any minimum-spend drawdown before adding totals. Contingency is an allowance, not assumed expenditure.

Convert this budget into a monthly cash forecast, counting each payment once:

The funding requirement is the peak cumulative cash shortfall, including restricted cash, plus contingency. Deduct available unrestricted company cash to determine additional funding needed, and secure it before the shortfall occurs. Do not add operating costs again if they already form part of the deficit.

In a regulated-partner model, customer deposits and safeguarded payment or e-money balances cannot fund your business. Neither customer balances nor payment throughput count as your operating revenue or unrestricted working capital.

Keep dated provider prices separate from assumptions. The examples below are hypothetical, not market averages or complete neobank quotations. Before approving investment, replace assumptions with agreed prices and scope, and document all exclusions.

One-off implementation and launch costs

A setup fee covers only part of launch expenditure. Budget for integration, customer journeys, financial controls, legal documents and operational training. Obtain a statement of work defining deliverables, dependencies, acceptance criteria and ownership.

Griffin's platform-banking pricing, checked on 4 November 2026, lists onboarding from GBP 15,000. This is not a complete neobank quote and does not establish that an interface, card programme or internal implementation is included.

The hypothetical allocations below exclude VAT and are unrelated to provider quotations or market ranges. The pilot assumes simpler configuration; the larger rollout requires more integration and preparation. Initial customer verification and cards are budgeted separately.

For the initial cohort, assume 1,000 opened accounts for the pilot and 5,000 for the larger rollout. An illustrative 80% conversion from billable verification attempts to opened accounts requires 1,250 and 6,250 attempts. At GBP 3 per attempt and GBP 5 per physical card including delivery, with one card per account, additional costs are:

Replace these assumptions with actual verification, retry and card-uptake rates, adding separately charged account-opening fees and manual reviews. Schedule payments when due and count each attempt and card once. The later steady-volume example excludes a separate opening cohort: add it where needed, but not if already captured in monthly usage.

Include internal staff time and external invoices without duplicating supplier charges. Confirm coverage of card artwork, scheme approval, initial stock, app publication, data migration and accessibility testing. Reconcile prepaid card stock with issuance fees. Even a pre-built interface may require connections to identity, CRM, finance and support systems.

• Link payments to approved designs, tested integrations and production acceptance.
• Agree pricing and approval procedures for scope changes.
• Define treatment of prepaid fees if approval fails, features are unavailable or the project is cancelled.
• Document code and configuration ownership, third-party licences and handover obligations.

A hypothetical 10% contingency adds GBP 6,000 or GBP 12,000 to implementation alone. Including the initial cohort increases the allowance to GBP 6,875 or GBP 16,375, giving launch budgets of GBP 75,625 and GBP 180,125 before VAT and other exclusions. This percentage is an assumption, not a universal recommendation. Apply contingency once across the 12- or 36-month model, extending it to initial-cohort costs where added.

Separately identify customer acquisition, unbudgeted pre-launch salaries and subscriptions, applicable regulatory capital, contractual deposits and settlement prefunding. Keep recoverable collateral separate from expenditure. Obtain a complete scope and payment schedule, including recurring-fee start dates, before approving funding.

Recurring platform and usage-based costs

Separate fixed commitments—platform access, hosting, support and compliance or operations staff—from charges for accounts, verification attempts, transfers, card issuance and transactions. Check whether dormant accounts, rejected checks, refunds and replacements incur fees.

Under minimum-spend drawdown, pay the greater of eligible usage or the minimum, plus excluded fees; an additive platform fee sits on top of usage. Griffin's pricing, checked on 4 November 2026, lists GBP 4,000, GBP 6,000 and GBP 10,000 monthly minimum packages drawn down by accounts, payments and onboarding. Obtain unit tariffs and exclusions before modelling costs.

The independent hypothetical example below uses additive pricing and constant volumes of 1,000 or 5,000 average active billable accounts. It models steady operation, not growth from zero. Monthly onboarding and cards cover ongoing turnover; initial-cohort costs must be added separately where required.

Monthly variable costs total GBP 3,500 and GBP 17,500. Fixed costs comprise platform fees of GBP 4,000 or GBP 8,000, plus GBP 6,000 or GBP 12,000 for internal operations, support and hosting. Validate staffing against the service model. No additional minimums or volume discounts apply in this illustration.

Periods start at live operation and include implementation once. Totals exclude initial-cohort costs, pre-launch recurring spending, VAT, acquisition, fraud losses, disputes, FX, ATM use, extraordinary reviews, financing, regulatory capital and prefunding. Card maintenance and scheme costs are assumed included in tariffs; confirm this. No price increases or revenue offsets are modelled. Contingency is an allowance, not forecast expenditure.

Confirm VAT treatment by line item: financial-service exemptions do not automatically cover software or implementation, and input-tax recovery depends on your activities. Apply HMRC's finance and partial-exemption guidance with your tax adviser. These totals compare a defined scope; they are not complete funding quotations.

White-label versus bespoke: choosing the delivery model

Choose according to the customer experience you need to control and your team's capacity. White-label provides reusable software and configurable branding; bespoke requires more application development. Both can use the same bank or e-money infrastructure. Building an interface does not itself make your business a regulated financial institution.

White-label suits standard onboarding, account, payment and support journeys. Its advantage weakens as customisation grows: require a demonstration of your eligibility rules, approvals and reconciliation workflow. Bespoke may justify its cost when the experience creates competitive advantage, but requires ongoing API, authentication, reporting and security maintenance without disrupting customer access. Specify source-code ownership in developer contracts.

A hybrid can combine hosted onboarding or card components with a custom dashboard. Define component ownership, data flows, incident responsibilities and replacement options, and test the complete money flow.

Schedule due diligence, contracting, configuration or development, integration, compliance approval, testing and operational readiness for both options. Identify parallel work and approval dependencies, with base and delayed scenarios. Reusable software does not guarantee an earlier launch.

Compare monthly cash flows over the same 36-month period from a common decision date, using identical scope, customers, pricing and transaction assumptions. Include build costs, supplier fees, staff, maintenance, security, planned changes and migration. Apply the same growth assumptions relative to launch, shifting revenue and usage to each expected launch date.

Calculate savings after all operating-cost differences. Hypothetical supplier savings of GBP 5,000 per month, less GBP 2,500 of additional engineering, hosting and maintenance, leave GBP 2,500 net. Recovering an extra GBP 90,000 build investment therefore takes 36 months of savings, before financing or timing effects.

For a later launch, calculate forgone contribution as delayed or lost revenue less avoided variable costs, then add extra pre-launch expenditure not already budgeted. Model subsequent receipts rather than assuming all delayed revenue is permanently lost.

For example, a three-month delay with GBP 4,000 monthly forgone contribution and GBP 3,000 additional monthly expenditure adds GBP 21,000. Including the GBP 90,000 extra build cost, GBP 111,000 requires 44.4 months of GBP 2,500 net savings after launch. This hypothetical example assumes no contribution catch-up and excludes financing and discounting.

Count savings only when they begin. Compare cumulative cash performance and peak funding needs to assess whether lower running costs offset additional development and delay within the investment horizon.

Keep software choice separate from regulatory permissions: identify the entity providing each financial service and your permitted role. Choose a maintainable, affordable model that meets essential requirements and gives clear contractual control over future changes.

UK regulation: who holds the permissions and responsibilities?

"Neobank" and "white-label banking" describe propositions, not regulatory permissions. Establish whether customers will hold bank deposits, e-money or another type of payment account, and identify the legal entity supplying each service. The name on the app may differ from the firm holding the relevant permissions. Verify the provider's current status, permissions and restrictions on the Financial Services Register before relying on its proposed delivery model.

A regulated-partner arrangement can allow your business to distribute or support a financial product without becoming a bank. It does not automatically authorise every activity your business might undertake. Depending on the functions performed, your role could involve technology provision, e-money distribution, payment-services agency or an activity requiring your own authorisation. Determine the perimeter from actual contracts and money flows with qualified UK advisers; the FCA overview of payment services and e-money regulation provides the starting framework.

If your business provides payment services as an agent of a payment institution, the principal must register it on the Financial Services Register before those services begin. Agents providing payment services for an electronic money institution also require registration by their principal. Treat registration and the principal's due diligence as launch dependencies, with time and budget allocated for evidence requests and approval. By contrast, an agent of a bank permitted to provide payment services in the UK does not require agent registration under the Payment Services Regulations merely for that role. The FCA's guidance on payment-services agents explains these distinctions.

E-money distribution is a separate category. A business that only distributes or redeems e-money, without issuing it or acting as a payment-services agent, does not need authorisation or registration under the Electronic Money Regulations for that activity; its principal should notify the FCA of the distributor arrangement. If its activities also amount to payment services, additional requirements may apply. Neither an agent nor a distributor may issue e-money on the institution's behalf. Check the actual role against the FCA guidance on e-money distributors and agents.

For deposit-taking, the banking entity holds the relevant permission. An electronic money institution issues e-money; its authorisation is not a banking licence. If your proposal includes lending, investment or other additional products, assess those activities separately rather than assuming that an accounts-and-payments agreement covers them.

Document both who performs each task and who remains accountable. A statement that "compliance is included" is insufficient to cost the arrangement: it may cover standard checks but exclude complex cases, ongoing investigations or first-line customer support. Request a responsibility matrix and tariff for exceptions, with service levels and escalation routes. Contractual delegation of operational tasks does not remove the regulated firm's applicable responsibilities.

Include the UK's mandatory authorised push payment (APP) scam reimbursement framework in the cost assessment. It covers qualifying payments through Faster Payments and CHAPS, subject to the applicable eligibility rules and exclusions. Under the Faster Payments framework, reimbursement costs are shared equally between the sending and receiving payment service providers. This creates exposure on both sides of a payment, including where a programme's accounts receive scam proceeds. Review the PSR's consolidated reimbursement policy against the proposed customer and account types.

Agree who will monitor incoming and outgoing payments, investigate suspected mule accounts, handle claims, exchange evidence and fund reimbursements within the required timescales. Budget for fraud-prevention tools, trained claims staff and expected losses. Identify any indemnities or charges through which a provider passes costs to your business; the allocation between regulated payment service providers does not, by itself, determine your commercial liability under the programme contract.

Customer-money protection also needs precise wording. The standard FSCS deposit limit is GBP 120,000 per eligible person, per authorised firm, effective from 1 December 2025. Eligible deposits across brands sharing a banking licence are aggregated. E-money is not a bank deposit, and failure of a non-bank payment provider is not covered by FSCS deposit compensation. The FCA explains safeguarding and warns that repayment following insolvency can be delayed and reduced by costs.

For institutions required to safeguard, the current framework includes the supplementary rules effective from 7 May 2026. Confirm how the provider meets the applicable requirements under the FCA safeguarding regime, including:

• Internal and external safeguarding reconciliations at least once on each reconciliation day, as defined by the rules, with processes to investigate and resolve discrepancies.
• Monthly safeguarding reporting to the FCA through the applicable return.
• Maintaining and updating resolution packs to support the return of customer funds if the institution fails.
• Safeguarding audits where required, taking account of applicable exemptions and submission deadlines.

Identify which obligations belong to the regulated provider and which data, records and operational assistance your business must supply. Budget for reliable ledger exports, reconciliation support, exception handling, audit evidence and any separately charged assurance work. Confirm whether these activities are included in platform fees or billed separately.

Where the Consumer Duty applies, responsibilities reflect each firm's role and influence over retail customer outcomes. Assess this explicitly, including relevant business-customer categories. Translate those responsibilities into funded work: product and fair-value assessments, testing whether customers understand communications, monitoring outcomes and addressing identified harm. Include support for customers in vulnerable circumstances through staff training, accessible service channels and appropriate escalation processes.

Agree the information your business must provide for the regulated firm's oversight and applicable annual governing-body assessment. Assign owners and budgets for collecting outcome data, investigating poor results and implementing improvements. A contractual promise to support Consumer Duty compliance is insufficient without the systems and staff to produce evidence and act on it.

If you instead pursue your own authorisation, build a separate plan for governance, regulatory applications, capital and ongoing supervision; a partner-programme budget is not an estimate of that undertaking.

Business case: launch timeline, margins and break-even

Plan around the date customers can use the approved product. Assign owners, completion evidence and cost start dates to due diligence, contracting, integration, compliance, testing and operational readiness. This hypothetical 16-week schedule shows overlapping activities; it is not a market benchmark or provider commitment.

Actual timing depends on scope, partner capacity and team readiness; provider onboarding alone is not the full launch timeline. Model delays: three additional months at a hypothetical GBP 10,000 monthly pre-launch cost require GBP 30,000. This is separate from the operating-cost assumptions; exclude usage fees not yet incurred and avoid duplicating budgeted staff costs.

Forecast acquisition, verification, activation and retention separately. Track acquisition cost per activated customer, paid-plan uptake, time to first use, dormancy and churn. Applicants are not necessarily paying customers, while failed checks and inactive accounts may still incur charges.

Contribution per active account equals net revenue less variable service costs and expected variable losses. Use realistic collection rates and only contractually permitted revenue. Customer deposits and payment throughput are not revenue. The following hypothetical assumptions produce GBP 8.50 per average active account monthly:

The UK Interchange Fee Regulation caps qualifying consumer debit and prepaid interchange at 0.2% where the merchant, acquirer and issuer are all in the UK. This is not a guaranteed rate or programme entitlement, and should not be applied indiscriminately to commercial or cross-border cards. Validate transaction mix, deductions and revenue share. The subscription assumption excludes applicable output VAT; service costs are modelled separately. Count deductions once.

This sensitivity assumes unchanged tariffs, transaction and onboarding mix, and sufficient capacity within fixed costs. Recalculate for staffing changes, pricing tiers and minimums. Add acquisition, VAT, fraud losses and other exclusions before calling the surplus profit. Zero or negative contribution cannot cover positive fixed costs through volume alone.

A separate growth example starts with 1,000 active accounts. It assumes all 1,000 accounts in the opening cohort are active at launch; the additional 80% activation assumption below applies only to subsequent monthly cohorts. Each month, 625 billable verification attempts produce 400 activations: 80% pass verification and 80% of those activate. With 2% monthly churn, closing accounts equal opening accounts × 98% + 400. Average accounts are the midpoint of opening and closing balances, assuming evenly distributed activity.

Keep revenue at GBP 8.50 per average active account and fixed costs at GBP 10,000. Recurring account and transaction costs are GBP 2.40 per account: GBP 1.00 administration + GBP 1.00 transfers + GBP 0.40 card purchases. Replace the earlier onboarding allowance with actual monthly flows: GBP 1,875 verification, GBP 2,000 for 400 cards and GBP 4,000 acquisition at GBP 10 per activation. No extra replacement-card or dormant-account fees are assumed.

Monthly net cash flow is therefore average active accounts × GBP 6.10 - GBP 17,875, assuming same-month receipts and payments. Opening outflows total GBP 78,750: GBP 60,000 implementation, GBP 8,750 initial verification and cards, and GBP 10,000 acquisition for the opening cohort, each counted once.

Monthly cash flow becomes positive in month 6, above approximately 2,931 average active accounts. Acquisition spending and the different onboarding mix explain why this exceeds the earlier 2,000-account threshold. The six-month peak month-end deficit is GBP 109,336.19 in month 5. Calculations retain fractional forecast accounts; displayed rounding may cause small differences.

Extend the forecast to 12 and 36 months, adjusting capacity, tariffs and conversion assumptions. Add omitted pre-launch costs, VAT, fraud, disputes, contingency, financing and restricted cash. Check whether payment timing creates larger shortfalls within a month. Monthly cash break-even does not mean investment payback.

In the steady-volume example, GBP 5,000 monthly surplus recovers GBP 60,000 implementation spending in 12 months at that run rate, or GBP 66,000 in 13.2 months if a 10% allowance is spent. Both exclude initial-cohort costs, acquisition, earlier losses and financing. Full payback requires cumulative cash inflows to recover actual expenditure and funding outflows, accounting for collateral releases.

Stress-test revenue, activation, churn, usage, losses and launch timing together. In the steady-volume model, revenue of GBP 6.50 less GBP 3.50 variable cost leaves GBP 3.00 contribution, raising break-even to 3,334 average active accounts. Recalculate the growth model separately using its actual onboarding and acquisition costs. Invest against an affordable downside case and evidence that customers will pay.

UK provider shortlist: capabilities, pricing and contract fit

Compare providers against a defined UK product and operating model. The information below was reviewed on 5 November 2026; confirm current capabilities, contracting entities and eligibility before budgeting. Programme-operator eligibility and end-customer eligibility are separate. None of these offerings should automatically be treated as a complete branded neobank app.

Sources: ClearBank embedded banking, payments and payment-account documentation; Griffin pricing, eligibility, payments, 13 October 2026 release notes and Direct Debit documentation; Modulr platform scope and UK disclosures; Railsr/PayrNet disclosures and the 1 June 2026 Equals rebrand announcement.

Verify availability for the exact contract. ClearBank's caveat concerns the documented embedded payment-account solution, not all its account services. Griffin's Direct Debits require product-specific enablement. Marketing claims alone do not establish production access.

Before major integration spending, obtain written acceptance covering the operator's entity and regulatory status, customer types, locations, sectors, balances and payment flows. Record required registrations, permissions, minimum volumes, financial resources, controls and approval dependencies; a sales discussion is not programme approval.

Name the supplier of the app or web portal, onboarding screens, card controls and support tools. Distinguish included components from your own or third-party development, and assign ownership of releases, maintenance and security fixes. APIs, administration portals and branded customer applications are different deliverables.

Request quotes using identical 12- and 36-month volumes, separating setup, platform fees, minimum drawdown, usage tariffs, cards, interfaces, internal work, VAT and exclusions. Obtain sample invoices at pilot and rollout volumes, including initial onboarding, failed checks, dormant accounts, returns and exceptional support.

• Confirm contract duration, renewal, fee increases, acceptance criteria and billing start dates.
• Record approved customers, operator status, live features and launch conditions.
• Allocate fraud, dispute and reimbursement costs, collateral and prefunding.
• Agree service levels, incident escalation, reconciliation data access and regulatory support.
• Define interface ownership, maintenance, third-party dependencies and change charges.
• Specify data exports, transition support, termination fees and consequences of changing banks, issuers or processors.

Select on verified capability, eligibility and total contractual cost. Require a demonstration of your customer journey and a quote matching your financial assumptions; a low starting fee does not establish affordability or launch readiness.