Greenfield Debit Card Program

Turning a CLV Thesis into Regulated Money Movement Infrastructure

---

TL;DR

A zero-to-one Visa debit card programme at Capital.com – a regulated CFD and investment broker – built not as a card product, but as a retained liquidity infrastructure layer. The hard problem was not card issuance: it was engineering the regulated internal fund movement architecture that allows value to travel between a live trading ledger, a card-spendable balance, and a CASS 7 safeguarded pool without breaching margin, settlement, or regulatory segregation constraints. Early cohort modelling projects cardholders generating 10–18% higher lifetime value than matched non-cardholders. In active build, targeting public beta Q2 2026.

CONTEXT

Capital.com is a regulated CFD and investment broker serving retail and professional traders globally, with active users holding leveraged positions in equities, FX, commodities, and indices. Revolut had launched stock trading, eToro had added a card product, and Interactive Brokers was deepening cash management – a card offering had become table stakes for defending the high-value segment. Capital.com holds a UK FCA investment firm authorisation, not an EMI licence. That regulatory fact shaped every architecture decision that followed: customer balances are trading balances subject to margin requirements, not e-money ledgers, and the path to card spend required a formally designed fund movement model – not a simple balance read.

PROBLEM

User problem

Capital.com traders – particularly the high-value segment – could not access gains or working capital without initiating a bank withdrawal and waiting 1–3 business days for settlement. Every purchase or bill required exiting the platform. For active traders managing leveraged positions, that friction compounded: withdrawing reduced available margin, interrupted portfolio exposure, and made the platform feel like a custody account rather than a financial operating layer.

Business problem

Withdrawal frequency was a measurable leading indicator of churn. Capital.com’s revenue – spread income, overnight financing, premium subscriptions – depends on funded, active positions.

Example: At £5B AUM and a 0.5% annual revenue yield, every 1% of at-risk AUM retained is worth £25M in preserved annual revenue. 

The card programme was not evaluated as a card product. It was evaluated as a retained liquidity mechanism: if idle balances gained real-world utility without leaving the platform, withdrawal leakage would fall and lifetime monetisation would increase.

Technical and regulatory problem

The core architecture problem is one no off-the-shelf card issuance product solves: moving funds from a live, leveraged trading environment into a card-spendable balance in real time, without breaching margin safety, settlement integrity, or regulatory segregation. Trading balances are not freely spendable – they may be affected by open positions, margin locks, pending settlement, or realised P&L timing. Card balances must support real-time authorisation via ISO 8583, scheme settlement under a dual-message clearing model, chargebacks, refunds, and FX conversion. These two domains operate under different timing, liquidity, and reconciliation rules. Since the firm does not hold and EMI license on its own, it requires a licensed BIN sponsor, a designed CASS 7 safeguarding structure, and PCI DSS scope defined from zero.

APPROACH

The programme defined its sequence early and held to it: commercial and compliance architecture before engineering, ledger design before card experience, and the financial case framed at board level around lifetime value rather than card economics.

Economic framing and financial model

The programme was evaluated through a card-adjusted LTV formula rather than standalone card P&L. The base model:

Base LTV = (Average gross revenue × customer tenure) − CAC − cost to serve

The card programme was designed to improve each variable. The full card-adjusted model:

Card-adjusted LTV =

  Base LTV

  + retained balance value
  + trickle-back trading revenue
  + interchange revenue
  + FX conversion revenue
  + interest income on sitting balances
  + payment cost savings
  − card operating cost
  − card risk cost

Where:

Retained balance value = retained balance uplift × revenue yield on retained funds

Revenue yield on retained funds = gross trading revenue ÷ average funded balance

Trickle-back revenue = trickle-back funds × trading turnover multiplier × gross revenue yield

Trickle-back rate = funds moved back into trading ÷ funds moved from trading into card balance

Direct card revenue =

  (card purchase volume × interchange rate × platform interchange share)
  + (foreign spend volume × FX markup × platform FX share)
  + (active cardholders × average sitting balance × net interest rate × platform interest share)

Net interest rate = Bank of England base rate − 1.5%

Average sitting balance = daily card spend × 2.33

  (assumption: ~30% of daily balance spent, ~70% retained as sitting liquidity)

Early modelling projected 10–18% higher LTV for active cardholders versus matched non-cardholders, with the majority of uplift driven by retained liquidity and trickle-back redeployment – not interchange. The AUM retention case – £25M in preserved annual revenue if 5% of at-risk AUM is retained – was the metric that reached board level. Three scenarios were validated: conservative (50K monthly active cards), base (100K cards), and optimistic (250k cards).

Internal fund movement model

The first architectural principle was that funds could not move between domains automatically or implicitly. Every card-spendable balance had to be created through an explicit, controlled internal fund transfer – a ledger event with eligibility checks, reservation states, posting rules, and reconciliation outputs. The platform checks available withdrawable balance – excluding margin-locked, unsettled, restricted, or pending-settlement funds – before posting a debit to the trading ledger and a credit to the internal card ledger. The card account became a separate financial domain, not a view onto the trading account. The issuer processor’s ledger was treated as an external operational ledger reconciled daily against the internal card ledger, which remained the authoritative source of truth.

The most technically demanding flow was cross-currency transfer: a trader moving funds from a GBP card balance into a EUR CFD trading account. Although the customer experienced this as a single transfer, the architecture decomposed it into two regulated operations. Operation 1 moved GBP from the card ledger to a GBP CFD account. Only after that completed did Operation 2 execute an internal FX conversion through the company’s FX infrastructure layer – an internal institutional-grade FX engine sourcing liquidity from multiple providers with rates cached in Redis for deterministic execution and quote locking. This separation preserved auditability, compensating transaction capability, FX transparency, and reconciliation correctness at every step.

Issuer selection and commercial negotiation

Three BIN sponsors were evaluated on a weighted scorecard: EMI licence jurisdiction, dual scheme membership, multi-currency programme support, delegated authorisation API maturity, settlement SLA flexibility, and interchange revenue sharing. The selection turned on a single integration risk: the delegated authorisation hook – the real-time API call into Capital.com’s portfolio ledger during card authorisation – had to execute within the ISO 8583 2-second timeout window. Contract terms – interchange splits, scheme fee pass-through, FX margin rights, settlement timing, and SLA penalty clauses – were negotiated and executed before engineering began.

Compliance and regulatory architecture

Four regulatory domains required design decisions before a BIN could be allocated. PCI DSS scope was bounded by confirming that card PAN data would be vaulted inside the issuer’s tokenisation environment – never transiting Capital.com infrastructure in cleartext – reducing scope to SAQ D rather than a full QSA engagement. CASS 7 safeguarding was extended by designing a dedicated segregated client money pool at a sponsor bank for card programme float, legally distinct from the investment firm’s existing client money pools. Under the dual-message clearing model, authorisation holds do not trigger e-money redemption – funds remain relevant for safeguarding purposes until the CLEAR message settles. MCC restrictions, velocity controls, and geographic limits were designed as a product configuration layer rather than hard-coded blocks, so risk appetite could be adjusted operationally without engineering involvement.

ARCHITECTURE

The programme’s architecture rests on four interconnected domains: the trading ledger, the internal card ledger, the issuer processor ledger, and the settlement and safeguarding banking layer. Two diagrams represent the core flows.

Cross-currency internal fund movement – card to CFD

This sequence shows how a GBP card-to-EUR CFD transfer is decomposed into two regulated ledger operations, with an FX conversion executed through the FX engine only after the first leg completes. The design separates the card debit from the FX event to preserve compensating transaction capability and auditability. A single-operation approach would have made partial-failure recovery architecturally unresolvable and reconciliation opaque.

Dual-message authorisation and settlement – card spend flow

This diagram shows how a card spend event travels from merchant terminal through the card network to Capital.com’s delegated authorisation gateway, how an authorisation hold is placed on the internal card ledger without redeeming e-money, and how the subsequent CLEAR message triggers settlement against the CASS 7 safeguarding pool. The dual-message model was chosen over a single-message model because authorisation holds under a dual-message system do not constitute spent funds – safeguarding obligations remain intact until clearing – which is the correct treatment under CASS 7 for a regulated investment firm. The 2-second ISO 8583 timeout window was the hard performance constraint driving the delegated authorisation architecture.

[[HTML SEQUENCE DIAGRAM]]

OUTCOMES

The programme is in active build. The following have been validated.

Validated programme milestones

• BIN sponsor contracted – interchange economics, settlement SLA, and delegated authorisation API specification agreed and executed before engineering began
• PCI DSS scope confirmed as SAQ D – PAN data vaulted at issuer, not transiting Capital.com infrastructure
• CASS 7 safeguarding structure designed – segregated client money pool at RBS, legally distinct from the investment firm’s existing pools, with dual-message clearing model confirmed as the correct safeguarding treatment
• Internal fund movement model defined – trading-to-card transfers are explicit ledger events with eligibility checks, multi-operation decomposition for cross-currency flows, and daily reconciliation against processor ledger
• Financial model validated across three scenarios with AUM retention as primary board metric; early cohort modelling projects 10–18% LTV uplift for active cardholders versus matched non-cardholders