How to Launch a UK Corporate Card Programme: Revenue, Costs and Controls

Define the Card Product and Target Customers

Begin with the business customer and spending problem the programme will solve. A small company controlling software subscriptions, a consultancy funding employee travel and a larger group managing supplier purchases may need different funding, reporting and approval arrangements. Specify the legal entity buying the service, the people authorised to use cards and the party responsible for repayment or other amounts due.

Define which customer types the programme will accept, such as limited companies, sole traders and partnerships. Do not treat these as interchangeable: legal structure can affect onboarding requirements, the regulation of any credit offered and the protections available to the customer. Agree eligibility criteria with the issuing and lending partners before designing the application process.

The Payment Systems Regulator distinguishes debit, credit and charge cards. Confirm the exact terms rather than using corporate card as a funding classification. A business card may be physical or virtual under any supported model, and its form does not determine who bears liability.

Document whether liability rests with the company, an individual or another agreed party, including any guarantees. An employee spending limit is not the same as the programme's credit limit or an assurance that all exceptional charges are covered. Distinguish the employer's internal expense policy from the customer's contractual obligations to the provider.

• Use cases: identify travel, online subscriptions, procurement, fuel or other defined spending categories and their existing pain points.
• Formats: determine where physical cards, reusable virtual cards or transaction-specific credentials are needed.
• Channels: specify online and in-person acceptance, any required digital-wallet support and whether cash access is necessary.
• Currencies: separate purchase, funding, billing and settlement currencies and identify where conversion is expected.
• Finance workflow: describe the required receipt capture, cost allocation, accounting export and visibility across business entities.

Test demand with a narrow customer segment before selecting a broad feature set. Record what clients currently pay for elsewhere, the manual work they want removed and the service they would adopt first. Those findings should determine the launch scope.

Conclude with a product brief and representative spending profile: expected active customers, cards per business, transaction frequency, purchase sizes and repayment behaviour where relevant. These choices determine funding needs, operational complexity and the partner capabilities required for a viable programme.

Choose Issuing Partners and Allocate UK Compliance Responsibilities

Start by deciding which legal entity will contract with the business customer and cardholder, issue the payment instrument, hold or safeguard funds, extend any credit, and operate the programme. A technology platform can provide APIs and dashboards without being the regulated issuer. The contract map must therefore identify the issuing bank, appropriately authorised payment institution or electronic money institution, any BIN sponsor, processor, programme manager, card manufacturer, wallet or token service, fraud supplier, and your own operating company.

Test the partnership before pricing it

Ask each candidate for its exact contracting entity, regulatory permissions, supported card models, customer types, territories, currencies, settlement routes, scheme access, and subcontractors. Verify the legal entity and permissions on the FCA Financial Services Register. Issuing payment instruments is a payment service under the UK Payment Services Regulations, while issuing electronic money requires an appropriate status under the Electronic Money Regulations unless an exemption applies. If the proposition includes a credit line, obtain specific perimeter advice on consumer credit and customer eligibility rather than assuming that a business label removes every requirement.

Establish your own operating company's regulatory position too: whether it acts solely as a technical supplier, as a payment-services agent or e-money distributor, or as a provider requiring its own authorisation or registration. Complete any required approvals and registration before launch. Contractual allocation of responsibilities does not replace these requirements.

• Product fit: physical and virtual cards, mobile wallets, commercial card classification, funding and repayment options, limits, merchant controls, and dispute handling.
• Operational fit: API availability, service levels, authorisation latency, settlement files, reconciliation data, incident response, replacement cards, and exit support.
• Economic fit: setup and minimum fees, per-card and per-transaction charges, interchange sharing, foreign exchange economics, reserves, prefunding, and change fees.
• Risk fit: underwriting ownership, loss allocation, fraud controls, safeguarding arrangements, data locations, concentration risk, and business continuity.

Map customer protections to the target market. The corporate opt-out allows agreed changes to certain payment-services requirements, but is unavailable for consumers, micro-enterprises and charities with annual income below £1 million. It does not remove all regulatory protections. Assess Consumer Duty applicability, including where the programme serves micro-enterprises, and allocate responsibility for meeting the applicable requirements.

Build a signed responsibility matrix

Translate the operating model into a RACI schedule attached to the contracts. Allocate KYB, including beneficial-owner identification and verification, ownership and control checks, and ongoing customer due diligence. Also allocate verification of authorised users, sanctions screening, transaction monitoring, suspicious activity escalation, strong customer authentication, fraud decisions, complaints, refunds, chargebacks, card blocking, customer communications, regulatory reporting, record retention, and data protection. State who sets policy, who performs each control, who reviews exceptions, which evidence is retained, and how quickly information must be supplied to the accountable regulated firm.

Where the structure requires safeguarding, document who receives relevant funds, how safeguarding is operated, how daily reconciliation works, and what customers are told. Reflect the FCA safeguarding requirements effective from 7 May 2026, including applicable monthly reporting, safeguarding audits and maintenance of a resolution pack to support the return of customer funds if the firm fails. Assign owners for these obligations and for supplying supporting records. Safeguarding is designed to protect relevant funds if an institution fails, but it should not be described as identical to bank deposit protection. For charge or credit products, document underwriting, credit limits, repayment collection, arrears, bad debt, and recourse.

Finally, align contracts across the chain. Service levels should cover authorisation, webhooks, file delivery, support, incidents, security notifications, and recovery. Audit rights, liability caps, insurance, subcontractor approval, regulatory change, data return, card migration, and termination assistance must not conflict. Maintain a live obligations register and review it before every material product, customer, or geographic change. The goal is not to outsource accountability, but to make every regulated and operational duty visible, owned, evidenced, and enforceable.

Build the Revenue Model

Build the revenue model from customer behaviour, not from a headline interchange percentage. Use monthly cohorts by customer segment and card type, then model active businesses, active cards, purchase volume, transaction count, average ticket, domestic and cross-border mix, currency mix, refunds, reversals, and attrition. This creates a transparent link between adoption assumptions and revenue.

Separate each revenue stream

Interchange is a gross economic pool, not automatically your revenue. Ask the issuer or sponsor for a transaction-level waterfall showing the applicable card category, gross interchange, scheme assessments, processor or sponsor deductions, incentives, refunds, and your contractual share. Qualifying commercial-card transactions are excluded from UK interchange fee caps, but the corporate label alone does not establish eligibility. Confirm that the arrangement meets the applicable criteria, including business-only use and payments charged directly to the business account, with settlement funds coming directly from that account. Use the PSR guidance and the issuer's confirmed classification. Cross-border economics can differ, so avoid assuming that one rate applies to every transaction.

For revolving-credit products, model interest income from expected interest-bearing balances and repayment behaviour, rather than total purchase volume. Identify which party earns the interest and bears the funding cost and credit risk; include only the income and costs attributable to your programme under the contracts.

Calculate contribution by cohort

For each revenue stream, state whether the model uses a gross amount or an amount net of partner shares and direct costs. Record each deduction once. If interchange revenue is already your net contractual share, do not subtract the issuer's share again. If foreign exchange revenue is already net of wholesale conversion costs, do not deduct those costs again. Reconcile this management view to the revenue presentation required by your accounting policy.

For each month, calculate programme revenue on that stated basis, then subtract variable costs not already deducted: authorisation and clearing fees, card and token charges, partner revenue share, foreign exchange cost, customer rewards, fraud and credit loss, chargeback cost, customer support driven by usage, and any variable compliance checks. Include funding costs attributable to credit balances where the programme bears them. The result is contribution; divide it by revenue to show the contribution margin percentage. Subtract fixed operating costs separately to show operating break-even.

A useful control equation is: contribution per active account equals revenue per active account minus variable cost per active account. Customer lifetime value should be based on contribution, not gross revenue, and should be compared with fully loaded acquisition cost. Show payback months, gross margin, contribution margin, and revenue concentration by customer and stream.

Use scenarios, not a single forecast

Create base, downside, and upside cases. Stress lower activation, lower spend, weaker interchange economics, higher churn, more foreign exchange refunds, higher fraud, and delayed enterprise sales. For credit products, also stress higher funding costs, slower repayment and higher credit losses. Test concentration: a large customer can raise volume while worsening margin through negotiated pricing and support demands. Include contract floors, minimum monthly commitments, tiered pricing, and step changes rather than smoothing them into averages.

Keep cash, accounting revenue, and regulated customer funds distinct. Recognise revenue according to the contracts and accounting policy, and do not treat prefunded customer balances as operating revenue. Reconcile forecast inputs to processor and issuer reports after launch. Each month, replace assumptions with observed cohort data, explain variance by price, volume, mix, and loss, and update the decision on which segments and features deserve further investment.

Budget Launch Costs and Calculate Break-Even

Construct the launch budget as a monthly cash and profit model, with costs tagged as one-off, recurring fixed, volume-based, or loss-related. Track funding requirements separately from expenses. A single total hides the timing and thresholds that determine whether the programme can launch safely. Use supplier quotations and contract schedules, and show tax treatment separately where relevant.

Capture the full cost base

• Programme setup: issuer and sponsor onboarding, scheme or BIN work, legal drafting, compliance design, due diligence, security assessment, card design, certification, and initial integrations.
• Product delivery: engineering, testing, cloud services, observability, data warehouse, accounting integrations, mobile or web interfaces, and internal tooling.
• Customer acquisition and sales: marketing campaigns, sales staff, commissions, referral fees, and customer onboarding costs.
• Card operations: manufacture, personalisation, postage, replacement, token provisioning, authorisation, clearing, settlement files, disputes, and customer support.
• Risk and compliance: KYB and user checks, sanctions and monitoring tools, fraud operations, audits, insurance, regulatory advice, and ongoing oversight.
• Financing costs and losses: interest and facility fees, fraud loss, credit loss, chargebacks, and recoveries, without counting the same loss twice.

Separately model cash committed to prefunding, refundable reserves and credit funding, including settlement timing and when funds become available again. These commitments affect liquidity but are not automatically profit-and-loss expenses. Record associated fees, financing costs and actual losses in the cost base.

Record minimum monthly commitments and tier thresholds exactly. A low unit price may be irrelevant if the minimum applies before volume arrives. Include internal staff at fully loaded cost and a contingency for remediation, certification repeats, supplier delays, and customer migration.

Model both contribution and cash break-even

The operating break-even formula requires positive contribution per active account. If contribution is zero or negative, increasing volume cannot cover fixed costs without a change in pricing, costs or customer mix. Recalculate where supplier tiers, staffing requirements or customer mix change materially.

Monthly cash break-even does not mean the initial investment has been recovered. Calculate payback from the cumulative monthly cash forecast, including launch expenditure, operating cash flows and changes in committed funding. Dividing investment by a single month's cash generation is only a shortcut where future cash flows are stable and positive.

Calculate segment-level contribution and reflect each segment's spend, subscription price, support demand, card replacement and loss rates in the overall forecast. Use active accounts or another economically meaningful denominator, not cards issued. Separate authorised, cleared, and settled volume, and reflect the delay between customer funding, settlement, partner invoicing, and revenue receipt. Keep safeguarded customer funds separate from cash available to finance the programme.

Run downside cases before approval

Stress delayed launch, slower activation, lower spend, reduced interchange share, higher processor minimums, more replacements, elevated fraud, credit losses, and a customer concentration event. Include a severe but plausible liquidity case in which settlement or reconciliation is disrupted. Document management actions such as reducing acquisition spend, pausing a feature, tightening underwriting, or renegotiating a commitment.

Approve the programme against explicit gates: maximum launch investment, peak cash requirement, minimum contribution margin, target break-even month, and a stop or redesign threshold. After launch, compare budget with actuals by price, volume, mix, timing, and loss. Refresh the forecast monthly so that higher transaction volume is never mistaken for healthy economics when variable cost, risk, or working-capital needs are rising faster.

Design Spending Controls and Expense Workflows

Design controls around the company's policy hierarchy: organisation, team or cost centre, cardholder, card, and transaction. The objective is to let approved spending flow while preventing misuse and creating evidence for finance. Every rule should have an owner, a reason, an effective date, an exception path, and a record of changes.

Translate policy into real-time rules

• Set per-transaction, daily, weekly, and monthly limits, with separate cash and foreign exchange limits where supported.
• Allow or block merchant categories, countries, currencies, card-present activity, online use, contactless use, and cash withdrawal according to role.
• Use single-use or merchant-locked virtual cards for controlled purchases, projects, suppliers, or travel bookings.
• Apply time windows, velocity rules, and balance or credit availability checks before authorisation.
• Define who may create, activate, freeze, unfreeze, replace, terminate, or reveal sensitive card details.

Real-time controls do not guarantee that every charge will remain within the displayed limit. Offline transactions, stand-in processing when the normal authorisation service is unavailable, and delayed or adjusted charges may not pass through the programme's usual checks. Agree with the issuer which controls apply in these situations, who bears any resulting exposure, and how exceptions are detected and resolved.

Controls must align with the issuer's framework contract and regulatory duties. Blocking decisions should be supported by agreed terms, reasonable grounds, and the notification process applicable to the regulated provider. Avoid presenting internal policy as an automatic legal entitlement to decline or retain funds.

Connect the card event to the expense record

Create an expense as soon as an authorisation event arrives, then update it through clearing, adjustment, reversal, refund, and chargeback. Capture merchant, amount, currency, exchange information, cardholder, cost centre, project, tax category, receipt, purpose, attendees, and approval status. Preserve the distinction between pending and settled amounts so the ledger is not posted from an unstable authorisation.

Separate pre-spend approval from post-transaction expense approval. Where prior approval is required, obtain it before enabling the purchase, for example by issuing a controlled virtual card or temporarily adjusting a limit. Review after payment checks the expense's purpose, evidence and accounting treatment; it cannot prevent a payment that has already occurred.

Use configurable workflows. Low-risk spend may require receipt and manager review; higher-value or sensitive categories may require budget owner, finance, or compliance approval before spending, followed by an evidence check after payment. Define reminders, escalation, overdue treatment, and card suspension rules. Provide a documented emergency override with time limit, second-person approval, and post-event review.

For UK VAT recovery, capture and retain a valid VAT invoice, including a qualifying simplified invoice where applicable. A card statement or transaction record alone is insufficient evidence for reclaiming VAT. Route missing or invalid invoices to finance for review before claiming, in line with HMRC guidance.

Make reconciliation and audit routine

Match processor transactions to expenses using stable transaction identifiers, not merchant text alone. Handle partial clearing, tips, incremental authorisations, split shipments, refunds, foreign exchange differences, and duplicates. Map approved expenses to the chart of accounts and export balanced journal entries with source links. Failed exports should enter a visible retry queue rather than disappear.

Separate duties among card administration, policy approval, expense approval, accounting, and payment release. Log every card lifecycle action, rule change, approval, override, data edit, and export. Give finance exception dashboards for missing receipts, out-of-policy spend, unusual velocity, stale authorisations, duplicate claims, unreconciled settlements, and overdue repayments.

Measure decline rates, false positives, exception volume, receipt completion, approval time, unreconciled value, fraud loss, and employee support contacts. Review these by segment and rule. Tighten controls that reduce genuine loss, but retire rules that repeatedly block legitimate activity without compensating benefit. A strong workflow combines real-time prevention, prompt evidence collection, disciplined accounting, and a clear human route for exceptions.

Integrate Digital Card Issuing and Operational Systems

Design the integration as a controlled payments system, not a collection of API calls. Keep a canonical internal model for business accounts, authorised users, cards, wallets or tokens, funding sources, limits, authorisations, clearings, reversals, refunds, disputes, and settlements. Map each partner identifier and status to that model so a provider change does not rewrite every downstream system.

Build a secure lifecycle service

Expose internal commands for create, activate, freeze, unfreeze, replace, terminate, set controls, and provision a token. Authenticate services strongly, apply least privilege, require step-up approval for sensitive actions, and keep immutable audit logs. Never place a full PAN, security code, secret, or personal data in ordinary application logs. Virtual PANs remain subject to PCI DSS when they represent a participating payment brand, so determine scope with a qualified assessor and use hosted or tokenised components where appropriate.

Separate the customer interface from the issuer adapter. Version API contracts, validate inputs, and enforce idempotency keys on write operations. Retain only the request and response fields needed for operations, reconciliation and audit, with sensitive data removed or masked and appropriate access controls and retention periods. Record the resulting state transition. Timeouts are ambiguous: retry only with the same idempotency key where the partner guarantees safe retries, or first query the partner. Use circuit breakers, bounded retries, rate limits, and a manual operations path for unresolved outcomes.

Define whether the issuer, processor or programme service makes each real-time authorisation decision, which system owns the available balance, and the response deadline. Reserve funds or credit atomically when approving a transaction so simultaneous requests cannot spend the same availability. Adjust or release reservations as clearing, reversal and expiry events arrive. Agree timeout and outage behaviour with the issuer, including when transactions are declined or handled through stand-in processing, which limits remain enforceable, and how decisions are reconciled after recovery.

Integrate the issuer's 3-D Secure service for online card payments and define how strong customer authentication challenges are delivered, completed and recovered when they fail. Agree responsibility for exemption decisions and authentication records. Corporate cards are not automatically exempt from SCA: the dedicated corporate-process exemption applies only under the conditions in the FCA technical standards.

Handle events and non-sequential transaction lifecycles

Receive webhooks through a narrow authenticated endpoint. Verify signatures or other agreed authenticity controls, retain only necessary event data under the same protection and retention rules, acknowledge quickly, and place processing on a durable queue. Deduplicate by event identifier, accept that events can arrive late or out of order, and make handlers idempotent. A state machine should prevent a stale authorisation update from overwriting a later clearing or reversal.

Do not assume that every authorisation has one matching clearing. Support multiple partial clearings, clearing without a matching authorisation, and late presentment after an authorisation reservation has expired. Track reservations and posted amounts separately, link related events where possible, and route unmatched items for investigation without dropping valid financial entries or releasing the same reservation twice.

Reconcile event-driven records against issuer settlement and transaction reports. Webhooks improve speed but are not the accounting source of truth. Poll for gaps where the partner supports it, track sequence or update times, and create exceptions for unmatched, duplicated, or conflicting records.

Connect the operating stack

• Identity and compliance: business onboarding, authorised user verification, sanctions decisions, and review status.
• Finance: funding, repayment, settlement, fees, foreign exchange, general ledger journals, and bank reconciliation.
• Expense management: pending transactions, receipts, coding, approval, refunds, and policy exceptions.
• Service operations: card status, delivery, disputes, fraud cases, customer messages, and support history.

Encrypt data in transit and at rest, rotate secrets, segregate production access, test backup restoration, and define retention and deletion. Monitor authorisation latency, API error rate, webhook lag, queue age, duplicate rate, reconciliation breaks, settlement completeness, and card lifecycle failures. Alert on customer impact and financial exposure, with runbooks and named owners.

Test partner sandbox behaviour, but also run controlled production tests for token provisioning, authentication challenges, declines, reversals, refunds, replacement cards, lost webhooks, replayed events, and degraded dependencies. Verify concurrent spending, partial and unmatched clearings, late presentment, and outage recovery through agreed test scenarios. A launch-ready integration can explain every card state and money movement, recover without duplication, and produce evidence for customers, finance, compliance, and the issuing partner.

Pilot, Launch and Scale the Programme

Use a staged launch to prove customer value, operational control, and unit economics before broad distribution. Start with a narrow segment whose spending patterns are understood and whose users will provide structured feedback. Limit initial accounts, card types, countries, currencies, and funding models so failures can be isolated without hiding behind aggregate volume.

Define the pilot as a test with gates

Write hypotheses and acceptance thresholds before issuing cards. Track onboarding completion, time to first transaction, activation, active-card rate, spend, authorisation approval, false declines, support contacts, receipt completion, reconciliation breaks, fraud and credit loss, contribution margin, and partner service levels. Segment results by customer type and use case rather than relying on a single average.

Set aggregate financial exposure limits alongside individual customer and card limits. Cap total outstanding credit, unsettled spending and programme funding committed to the pilot, with defined buffers for delayed or adjusted charges. Assign an owner to monitor exposure and specify when a breach triggers restrictions on spending, credit or further onboarding.

For charge and credit products, observe cohorts through complete billing and repayment cycles before judging credit performance or increasing exposure. Include time to identify missed payments and assess collections outcomes. Early repayment success does not establish mature credit-loss performance, so retain conservative loss assumptions and exposure limits while the evidence develops.

Recruit businesses that represent the intended market but avoid dependence on one unusually cooperative customer. Give them clear terms, funding and repayment instructions, escalation contacts, and limitations of the pilot. Train internal support, fraud, finance, compliance, and engineering teams, then rehearse lost cards, suspected fraud, missing settlements, duplicate events, failed funding, card replacement, complaints, data incidents, and provider outages.

Launch only when operations are repeatable

• Complete contractual, regulatory, data protection, security, and operational readiness sign-off.
• Verify production configuration, limit templates, merchant controls, pricing, communications, accounting mappings, and user permissions.
• Reconcile issued cards, customer balances, authorisations, clearings, fees, funding, and settlement every day during the early period.
• Maintain live incident roles, decision authority, partner contacts, customer messaging templates, and tested pause and shutdown procedures.

Distinguish pausing new issuance from restricting spending on existing cards or closing the programme. Agree with the issuer how each action affects cards, wallet tokens and recurring payments. Continue processing outstanding authorisations, late clearings, refunds, disputes and repayments, and retain sufficient funding and operational support to meet those obligations. Define how customer balances will be reconciled and returned or transferred, how customers will be notified, and who owns unresolved items until closure.

Move from employee testing to invited customers, then to controlled general availability. Increase limits and customer volume in batches, with a monitoring period between stages. Do not use acquisition campaigns to outrun KYB capacity, fraud review, card fulfilment, support, settlement liquidity, or reconciliation.

Scale the operating model as well as volume

Capacity plans should cover API quotas, webhook queues, database load, card stock, customer support, compliance reviews, dispute deadlines, fraud staffing, credit funding, safeguarding or settlement balances, and accounting close. Remove manual work through controlled automation, but retain exception queues, dual approval for sensitive changes, and auditable overrides.

Review partners against measured service levels and concentration risk. Maintain exit data, migration procedures, and tested continuity options before they are urgently needed. New countries, currencies, wallets, card classifications, or credit features require a fresh legal, risk, economic, and technical assessment rather than being treated as configuration.

Run a weekly launch forum and a monthly programme review. Assign owners and deadlines to incidents, customer feedback, control weaknesses, and forecast variance. Stop, restrict, or redesign a feature when loss, complaints, reconciliation failure, or negative contribution breaches an agreed threshold. Scale when consecutive cohorts show stable controls, predictable servicing, reliable settlement, and improving contribution, supported by repayment evidence where credit is offered. The objective is sustainable, explainable growth, not simply more cards issued or more gross transaction volume.