How to Launch a UK Card Issuing Programme: Costs, Partners and Regulation

Define Your Card Product and Business Model

A card issuing programme combines a payment instrument, a funding arrangement and the services needed to support cardholders. Your business may own the brand and customer experience while a regulated issuer supplies the card service. Running the programme does not automatically make your company the issuer; identify the intended customer relationship before selecting the technology.

Start with one customer problem. A consumer spending card, an employee expense product and a supplier-payment card can require different eligibility rules, transaction patterns and support. Specify whether the customer is an individual or a business, who uses each card, who funds spending and who is responsible for amounts owed.

The Payment Systems Regulator's explanation of payment types provides the basic distinctions, but your contracts determine the precise funding and repayment mechanics. A virtual format does not itself establish whether the card is debit, prepaid or credit.

• Specify customer residence, business locations, permitted merchant countries and expected domestic versus cross-border spending.
• Separate account currency, purchase currency and settlement currency, including when conversion occurs.
• Define essential journeys: card creation, activation, spending, freezing, replacement, refunds and account closure.
• Record expected active cards, spending frequency, average purchase value and support demand, rather than only cards issued.

Identify who will pay for the proposition. Revenue may include subscriptions for useful services, disclosed programme fees or a contracted share of interchange. Interchange is not automatically retained by the branded business: the issuing agreement determines any share, and the UK interchange framework applies caps to specified transactions. Do not build the base case from an unverified headline rate.

Finish with a concise product brief describing the customer, problem, funding model, card formats, geography and proposed revenue. Test whether the service offers a reason to use and retain the card before adding features. This establishes the scope against which the issuing arrangement and regulatory responsibilities can be assessed.

Choose Your Issuing Model and Understand UK Regulation

Start by separating the customer proposition from the regulated issuing role. A card programme can provide the brand, app, customer journey, pricing and operating rules while a bank, authorised electronic money institution or appropriately authorised payment institution issues the card. The programme operator does not become the regulated issuer merely because its name appears on the card.

Card issuance, electronic money issuance, deposit-taking and lending are distinct activities. A payment institution can issue payment instruments within its permissions without issuing electronic money. Issuing e-money requires the appropriate legal status, accepting deposits requires deposit-taking permission, and regulated consumer lending requires the relevant consumer-credit permission. Card-issuing permissions alone do not authorise all these activities.

Map the product before choosing the structure. A debit card draws from a payment account, a prepaid card normally spends stored value or electronic money, and a credit card draws on a credit facility. Consumer and commercial cards can have different conduct, credit, interchange and customer-protection implications. Physical and virtual formats, currencies, countries, cash withdrawal, contactless use and digital-wallet support also affect partner capabilities and scheme approvals and may change the regulatory requirements.

In a sponsored model, the issuer or BIN sponsor supplies scheme access and the regulated issuing foundation. The programme may operate as an agent or distributor, or perform outsourced technical and operational functions, depending on the activities and contracts. The sponsor remains accountable for regulated services performed on its behalf, but the programme still has contractual, data-protection, security and conduct duties. Verify the exact legal entity and permissions on the FCA Financial Services Register.

Direct authorisation gives greater control but is not simply an alternative commercial contract. Choose the authorisation route according to the activities the business will perform. A payment institution or electronic money institution application requires adequate capital, suitable management, governance, risk controls, applicable safeguarding arrangements, anti-money-laundering arrangements, security, business continuity, incident processes and a credible wind-down plan. Payment institution authorisation does not itself permit electronic money issuance or deposit-taking, and electronic money institution authorisation does not permit deposit-taking. Regulated consumer lending requires the relevant FCA permission and a compliant funding, affordability, arrears and forbearance model.

Document the complete flow of money and responsibility: customer funding, e-money issuance or account credit, authorisation, clearing, settlement, refunds, chargebacks and redemption. Identify who owns each customer obligation, who records the balance and who has access to safeguarded or lending funds. Safeguarding is designed to protect relevant funds if a payment or e-money firm fails; it is not the same as deposit protection.

Obtain specialist legal advice on the proposed perimeter before development. The decision should reflect target customers, launch speed, capital, governance capacity and long-term control. Do not assume that issuer sponsorship removes every compliance obligation or that direct authorisation removes the need for a processor, scheme access and specialist operating partners.

Issuer Sponsorship Versus Direct Authorisation

Issuer sponsorship is usually the faster route to market. A bank, authorised electronic money institution or appropriately authorised payment institution acts as issuer, provides or sponsors access to the card scheme and accepts regulatory responsibility for the issuing services it supplies. The programme business contracts for the product configuration, processing and operating model, while remaining subject to the sponsor's risk appetite, controls and approval.

Sponsorship does not mean that the programme can outsource every decision. The parties must define whether the programme is an agent, e-money distributor or unregulated technical service provider, and whether it performs onboarding, transaction monitoring, customer support or complaints handling on the issuer's behalf. Agents providing payment services must be registered where required. An electronic money institution remains responsible for acts and omissions of its agents and distributors and must oversee them effectively.

Build the launch timetable in separate stages: preparation, regulatory assessment where required, and implementation. For a sponsored programme, allow several months as an initial planning assumption for due diligence, contracting, integration, testing and approvals, then replace that assumption with a sponsor-confirmed schedule. There is no standard regulatory deadline for a sponsored launch. For direct payment institution or electronic money institution authorisation, the FCA must determine a complete application within three months of receipt, or an incomplete application within twelve months. These periods exclude preparation before submission and are not launch guarantees. Recruitment, control development, scheme access and technical delivery also need time, although some work can run in parallel.

Evaluate a sponsor by the exact legal entity and permissions, supported card products, customer types, currencies and countries. Ask how programme approval, policy changes, new features and new markets are governed. Contract for data access, transaction portability, token rights, customer communications, incident escalation and an orderly migration if the relationship ends. A sponsor exit can affect active cards, balances and customers, so termination assistance and wind-down responsibilities are essential.

Direct authorisation is appropriate only when the expected scale and strategic control justify the investment. The applicant needs experienced management, sufficient financial resources and documented systems for applicable safeguarding, financial crime, security, complaints, operational resilience, regulatory reporting and customer outcomes. Authorisation also carries execution risk; no regulated activity should begin before the required permission is effective.

For an authorised payment institution issuing payment instruments, the minimum initial capital is EUR 125,000. Ongoing own funds must meet the higher of that minimum and the amount calculated under the applicable FCA-directed method, based on fixed overheads, payment volume or income, subject to regulatory adjustments. An authorised electronic money institution requires at least EUR 350,000 initially. Its ongoing own funds must meet the higher of that floor and its calculated requirement, normally 2% of average outstanding e-money plus any requirement for payment services unrelated to e-money issuance, subject to regulatory adjustments. These figures concern full PI and EMI authorisation; banks and other regulatory routes have different requirements.

Regulatory capital is not a launch-cost budget or a sponsor reserve. Forecast eligible own funds after expected operating losses, and separately model operating cash, settlement prefunding and any collateral or guarantees. Safeguarded customer money cannot fund the business. Avoid counting the same resources as freely available for several purposes without checking the regulatory and contractual restrictions.

Credit programmes require additional care. If the business is the consumer lender, it needs the appropriate consumer-credit permission and must fund receivables, assess creditworthiness and affordability, manage statements, arrears, forbearance and complaints. A sponsored card issuer does not automatically supply the lending permission or balance-sheet funding.

A staged approach can preserve options. Launch with a sponsor, use business-owned product and data models, and negotiate portability while testing demand. Revisit direct authorisation when volumes, unit economics, governance maturity and the value of greater control are evidenced. The comparison should include the cost and risk of transition, not only the steady-state fee difference.

Compliance Obligations and Accountability

Allocate every obligation to a named legal entity and an operational owner. The regulated issuer remains accountable for regulated services that it outsources or delivers through agents and distributors, but the programme business is responsible for performing its contracted controls correctly. A responsibility matrix should cover policy ownership, execution, oversight, evidence, escalation and final regulatory accountability.

For prepaid or debit products involving electronic money or payment services, apply the Money Laundering Regulations and the issuer's risk-based customer and transaction controls. The programme must not treat a successful automated identity check as the complete decision. Define enhanced due diligence, sanctions matches, suspicious activity, account restrictions and exit. Keep an auditable link between the customer, account, card and transaction.

Where relevant funds are held, the authorised payment or electronic money institution must comply with the applicable safeguarding framework. Under the UK regime effective from May 2026, this includes FCA Handbook requirements for governance, records, reconciliations, reporting and resolution arrangements alongside the statutory rules. The programme ledger and processor files must provide accurate daily data to the safeguarding institution. Customer communications must not describe safeguarded e-money as a bank deposit or imply FSCS protection where it does not apply.

Apply Strong Customer Authentication (SCA) where required for electronic payments, online payment-account access and relevant remote actions. Document which exemptions may be used, the conditions for applying them and how their use is monitored. Assign responsibility for implementation and testing across the issuer, processor and authentication provider, including 3-D Secure where used. Provide authentication methods that accommodate customers' accessibility needs. Outsourcing authentication does not remove the responsible payment service provider's regulatory obligations.

Products within the FCA Consumer Duty's scope require product governance and fair-value analysis, clear communications and support throughout the product lifecycle. In payments and e-money, retail customers can include micro-enterprises and qualifying small charities, not just individual consumers. The Duty can apply to regulated firms in the retail distribution chain even where they do not have the direct customer contract. Complaints, vulnerable-customer support, declined transactions, fraud claims, refunds and account closure need documented service levels and escalation routes.

Separate statutory unauthorised-payment refunds from scheme chargebacks. Where the statutory refund duty applies, the payment service provider must generally refund an unauthorised payment immediately and no later than the end of the business day following the day it becomes aware of the transaction, subject to the applicable legal exceptions. Do not delay a refund merely while awaiting a chargeback outcome. Chargebacks follow card-scheme rules, evidence requirements and deadlines and do not replace statutory customer rights.

Relevant payment-services and e-money complaints normally require a final response within 15 business days of receipt. Only in exceptional circumstances beyond the firm's control may this extend to 35 business days, with a holding response explaining the delay. Other complaints, including many consumer-credit complaints, generally follow the eight-week timetable. Explain eligible complainants' right to refer unresolved complaints to the Financial Ombudsman Service after the applicable response deadline or if dissatisfied with the final response, normally within six months of that response.

A credit card adds lender obligations. The responsible firm must use compliant creditworthiness and affordability assessments, provide required information and statements, administer interest and fees correctly, and manage arrears and forbearance. Outsourcing scoring or servicing does not transfer the lender's accountability. Commercial cards may avoid some consumer-credit provisions, but customer type and agreement terms must be verified.

For qualifying credit-card purchases, Section 75 of the Consumer Credit Act 1974 can make the creditor jointly and severally liable with the supplier for breach of contract or misrepresentation. It generally applies where the cash price of the individual goods or services is more than GBP 100 and no more than GBP 30,000, subject to the required debtor-creditor-supplier relationship and other statutory conditions. Allocate responsibility for assessing and funding these claims separately from scheme chargebacks; a failed chargeback does not by itself determine the Section 75 outcome.

Apply UK GDPR by defining controller, joint-controller and processor roles for onboarding, fraud, marketing and servicing. Use appropriate contracts, minimise data, set retention periods and assess restricted international transfers. Confirm PCI DSS responsibilities with the issuer, processor and scheme; tokenisation can reduce card-data exposure but does not eliminate all obligations.

Governance should include management information, control testing, audit rights and change approval. Review complaint outcomes, financial-crime alerts, authorisation declines, fraud, chargebacks, safeguarding differences and service incidents. Escalate material breaches promptly under the contract and applicable rules. The compliance model is complete only when each party can produce evidence of the control it performs.

Select Your Issuer and Delivery Partners

Build the partner map before requesting proposals. The issuer or BIN sponsor is only one component of a card programme. The operating chain may also include an issuer processor, scheme connectivity, card manufacture and personalisation, digital-wallet tokenisation, identity verification, fraud monitoring, ledger infrastructure, customer support and a settlement or safeguarding bank. One vendor can bundle several roles, but the contract should identify the legal entity and subcontractor behind each service.

Issue the same requirements pack to every candidate. State the card type, consumer or commercial target market, customer journey, expected accounts and cards, transaction volume, average value, cash withdrawal, countries, currencies, physical and virtual mix, wallets, credit or prefunding model and launch phases. Ask each vendor to mark capabilities as live, configurable, roadmap or unsupported for the exact contracting entity.

Check the issuer's current permissions on the FCA Financial Services Register and confirm its scheme relationship. If the programme will be an agent or distributor, establish the required registration, approval and oversight process. Review the sponsor's restricted-business policy, onboarding standards, risk appetite, reserve or prefunding requirements and change-control lead times. A technically capable processor cannot override an issuer's refusal to approve the product.

Evaluate the processor through real lifecycle scenarios. It should expose stable identifiers and auditable states for card creation, activation, PIN, tokenisation, authorisation, reversal, clearing, refund, chargeback, expiry, replacement, suspension and closure. Confirm idempotency, webhook authentication, duplicate-event handling, API versioning, capacity, latency, service levels and export of raw transaction and fee data.

Commercial analysis should include setup, certification, programme management, processing, scheme pass-through, card production, shipping, wallet, fraud, KYC, disputes, minimum commitments, support, reserve and exit charges. Identify which fees are fixed, per account, per card, per authorisation, per cleared transaction or percentage-based. Obtain specimen invoices and settlement files.

Allocate financial liability explicitly in partner contracts. Specify who funds customer refunds and settlement shortfalls immediately, and who ultimately bears losses from fraud, operational errors, disputes and chargebacks. Define responsibility for subcontractor failures, claims procedures, evidence requirements, reimbursement deadlines, indemnities, liability caps and exclusions. State when reserves or collateral may be used, replenished and released. Ensure that disagreements between partners do not delay required customer refunds or settlement payments.

Perform financial, security and operational due diligence. Review audited financial information where available, insurance, PCI DSS evidence, penetration testing, subcontractors, data locations, incident history, recovery objectives and concentration risk. Test support escalation and require named ownership for severe incidents.

Contract for change and exit. Preserve access to customer, card, token, transaction and dispute records; define who communicates with customers; and specify migration assistance, card reissue responsibility and balance return. Select the combination that meets regulatory and operational needs with a credible total cost, rather than the vendor with the broadest demonstration.

Estimate Launch Costs, Funding Needs and Unit Economics

Build the financial model before signing minimum commitments. Separate one-off implementation, recurring fixed cost, variable cost, funding and expected revenue. Use quotations for the defined product and transaction mix; generic "card issuing" prices rarely include the full issuer, processor, scheme, fraud and operations stack.

Model funding separately from expense. A prepaid programme may need settlement prefunding, liquidity for refunds and chargebacks, operational accounts and any reserve or guarantee required by the sponsor. Safeguarded customer funds are not the programme's working capital. A credit programme also needs funding for receivables, liquidity and capital through the payment and repayment cycle, with expected credit losses reflected in its forecasts. Stress delayed repayment, higher fraud and sponsor requests for additional collateral.

For illustration, consider the following funding plan for a sponsored debit programme. Every amount is an invented modelling assumption, not a market benchmark or supplier quote. The example assumes no separate regulatory capital requirement for the programme operator; any applicable requirement must be assessed and funded separately.

Do not assume interchange funds the programme. Under the UK Interchange Fee Regulation, caps currently apply to qualifying UK domestic consumer card transactions: 0.2% for debit cards, including prepaid cards, and 0.3% for credit cards. The conditions and exclusions matter, commercial cards can be treated differently, and the programme receives only the contractual share agreed through its issuing chain. Cross-border transactions, reversals, scheme costs and sponsor pricing further change the result.

Potential revenue includes customer or employer subscriptions, account or service fees where lawful and appropriate, foreign-exchange margin, premium features, partner revenue and a contractual interchange share. Credit products may also earn interest: model the yield actually expected to be collected on interest-bearing receivables, allowing for interest-free periods, arrears and non-payment. Deduct funding interest, facility fees and credit losses when assessing contribution. Test customer charges against product governance, communications and fair-value requirements.

For the illustrative debit programme, assume 20,000 active cards, eight qualifying purchases per card per month and an average purchase value of GBP 30. Annual purchase volume is GBP 57.6 million. If every purchase earns interchange at the 0.2% cap, gross annual interchange is GBP 115,200. A hypothetical 50% contractual programme share leaves GBP 57,600, or GBP 0.24 per active card per month. Actual rates and contractual allocations must replace these assumptions.

The assumed GBP 1.50 variable cost includes transaction processing, ongoing card and account charges, servicing, replacements, fraud and disputes. Initial stock and acquisition are budgeted separately to avoid double counting. Costs associated with inactive accounts must also be included where incurred. At GBP 0.74 monthly contribution, operating break-even requires approximately 27,028 active cards, assuming fixed costs and unit economics remain unchanged. This does not recover initial investment or fund continuing acquisition. A GBP 5 acquisition cost takes approximately 6.8 active months to recover from contribution, before fixed costs and churn.

Translate the model into monthly cash flow. As a simplified first-year illustration, assume average active cards of 5,000, 10,000, 15,000 and 20,000 in successive quarters. At GBP 0.74 monthly contribution and GBP 20,000 monthly fixed costs, quarterly operating cash deficits are GBP 48,900, GBP 37,800, GBP 26,700 and GBP 15,600: GBP 129,000 for the year. The GBP 240,000 operating allocation therefore ends the year with GBP 111,000 remaining, assuming revenue and operating costs settle in the same month and acquisition is paid from its separate budget. With no customer contribution and unchanged fixed costs, that operating allocation alone provides twelve months of runway.

Calculate contribution by cohort and use consistent monthly or annual periods. Break-even active cards equal fixed costs divided by positive contribution per active card. Model acquisition spending separately, including the cost of replacing customers lost to attrition, and distinguish operating break-even from recovery of launch costs.

Run conservative, base and growth cases for activation, active rate, spend, interchange share, fraud, chargebacks, replacements, support contacts and attrition. Include tax, any irrecoverable VAT, launch delays and the timing of receipts and invoices; the simplified example excludes tax and payment-timing differences. Recalculate runway from unrestricted cash and forecast monthly outflows, excluding safeguarded funds and committed collateral. The programme is viable only if it can fund launch and stress liquidity while reaching break-even without relying on unconfirmed pricing or unrealistic card usage.

Build, Test and Prepare Programme Operations

Turn the approved proposition into an end-to-end service, not just a card API integration. Begin with signed product requirements that identify the regulated issuer, programme manager, processor and every material supplier. Map which party owns each decision, control, customer communication and operational task. The issuer or sponsor should approve the final product, customer journey, limits and risk rules before production use.

Design a clear system of record for customers, accounts, balances, cards and transactions. Use stable identifiers across platforms, idempotent requests, authenticated webhooks and traceable status changes. Define how authorisations, reversals, presentments, refunds, chargebacks, fees and foreign exchange reach the ledger. Reconcile processor, issuer, bank, scheme and internal records to cash movement; an attractive app cannot compensate for an unexplained settlement difference.

Agree the programme's PCI DSS scope with qualified security and delivery specialists. Tokenisation and hosted components may reduce exposure, but they do not by themselves prove that the business is out of scope. Document data flows, privilege boundaries, encryption, key responsibilities, retention and deletion. Use test data in non-production systems and restrict production access by role.

Test complete transaction journeys rather than isolated endpoints. The test catalogue should cover:

• Successful and declined authorisations, timeouts, duplicate messages, retries, reversals, clearing and late presentment.
• Strong Customer Authentication and 3-D Secure where used, including successful and failed challenges, applicable exemptions, unavailable authentication channels and accessible alternatives.
• Partial approvals where supported, refunds, chargebacks, offline or stand-in decisions, ATM activity, contactless use and foreign currency.
• Virtual and physical card issuance, activation, wallet provisioning where offered, lost or stolen status, replacement, renewal and closure.
• KYC or KYB exceptions, sanctions alerts, limit changes, suspicious behaviour, account restriction and lawful information requests.
• Daily settlement and safeguarding checks where relevant, file breaks, rounding, missing events and correction with a complete audit trail.
• Statutory unauthorised-payment refund workflows, from notification through assessment and account credit, with deadline tracking, documented exceptions and escalation before a breach. Verify that refunds are not delayed while awaiting a chargeback outcome.
• Complaint classification, deadline calculation, partner hand-offs, holding and final responses, and Financial Ombudsman referral information where applicable. Include weekends, bank holidays and cases approaching their response deadline.

Create production runbooks before the pilot. Name the on-call owners, escalation routes and decision authority for fraud spikes, processing outages, funding shortages, data incidents and reconciliation breaks. Set service levels between partners, but also define the customer response when a supplier misses them. Train support and compliance teams on scripts, verification, complaints, disputes and prohibited disclosures.

Use objective launch gates. At minimum, critical journeys, including authentication, statutory refunds and complaint handling, should pass in the production-like environment; reconciliations should balance through several complete cycles; monitoring and alerts should be exercised; customer terms and communications should be approved; and operational teams should complete simulations. Obtain all required issuer, scheme, processor and wallet-provider approvals or certifications for the launch scope, recording where existing partner approvals cover the programme.

Remediate security findings that prevent compliance with mandatory legal, scheme or security requirements before launch. Accountable owners may accept other residual risks only within those requirements and the agreed risk policy, with documented justification, controls and review dates. Internal risk acceptance cannot waive a mandatory requirement.

Keep a controlled release plan with rollback criteria, configuration baselines and evidence for every approval. This creates a repeatable operational service that can be piloted safely and scaled without losing accountability between the programme and its regulated and technical partners.

Pilot, Launch and Scale

Treat launch as a controlled release, not a single marketing date. Start with a pilot whose size, customer type, spend limits and duration have been approved by the issuer or sponsor. A useful pilot includes real end-to-end activity but limits financial and customer impact. Internal staff alone may not reproduce ordinary behaviour, so add a small representative customer cohort once contracts, disclosures, support and regulatory approvals permit it.

Before issuing the first live card, confirm that customer funds, settlement liquidity, card stock, production credentials, fraud rules and support coverage are ready. Complete operational rehearsals for a processor outage, suspected account takeover, lost card, safeguarding or settlement discrepancy where relevant, data incident and high-volume complaint. Record who can stop issuance, restrict transactions, notify partners and communicate with customers.

Set the pilot duration to observe complete transaction and settlement cycles, including delayed clearing and refunds and, for credit products, billing and repayment. Successful initial purchases alone are insufficient evidence for expansion. Where disputes or other delayed events do not arise during the pilot, supplement live results with controlled end-to-end tests, document the remaining uncertainty and agree any limits on expansion with the issuer. Continue monitoring the pilot cohort as later claims and losses emerge.

Define the metrics and thresholds before observing the results. Track application completion, approval rate, activation, active-card rate, transaction approval, average spend, fraud loss, false positives, disputes, chargebacks, replacement cards, support contacts and complaints. Add daily cash, settlement and reconciliation exceptions. Internal tolerances must not excuse safeguarding shortfalls or override required investigation, correction or reporting. Segment results by customer cohort and transaction type so that a strong headline does not hide a harmful or uneconomic group.

Use a staged ramp plan:

• Pilot: cap customers and exposure, review incidents daily and fix material defects before adding volume.
• Limited launch: open controlled acquisition channels, test support capacity and compare actual unit economics with the base case.
• General availability: increase issuance only after accountable owners and the issuer approve the evidence.
• Scale: automate stable controls, increase resilience and keep manual fallback for high-risk exceptions.

Each stage needs hold and rollback criteria. Examples include unexplained reconciliation breaks, settlement funding below buffer, a material security event, fraud or complaints above tolerance, failure of a critical supplier, misleading customer communications or inability to meet support times. A rollback can pause new applications or issuance while preserving essential service for existing customers; closing all functionality may create greater harm.

Scale capacity as well as demand. Forecast concurrent authorisations, settlement file volume, KYC or KYB reviews, fraud alerts, disputes, support contacts, card manufacture and replacement inventory. Test vendor rate limits and disaster recovery. Review service levels, incident trends, access, subcontractors and concentration risk through a regular governance forum with documented actions.

Do not silently extend the product to a new customer class, credit feature, currency or country. Reassess the regulatory perimeter, issuer permissions, customer terms, financial-crime controls, scheme rules, tax, safeguarding, funding and operational capability, then obtain the approvals required by the relevant partners. Consumer Duty and complaint obligations should be addressed where they apply; commercial positioning does not automatically remove every retail obligation.

Reforecast monthly during early growth using actual activation, spend, retained interchange, fees, fraud, losses and servicing cost. Maintain liquidity and contingency headroom, and keep an executable exit or migration plan. Sustainable scale means customer outcomes, control performance and contribution economics improve together, with evidence that the programme can withstand stress rather than relying on growth to conceal defects.