{"id":151,"date":"2026-05-24T16:42:22","date_gmt":"2026-05-24T15:42:22","guid":{"rendered":"https:\/\/lukaskoren.tech\/?page_id=151"},"modified":"2026-05-24T22:18:25","modified_gmt":"2026-05-24T21:18:25","slug":"greenfield-debit-card-program","status":"publish","type":"page","link":"https:\/\/lukaskoren.tech\/?page_id=151","title":{"rendered":"Greenfield Debit Card Program"},"content":{"rendered":"\n

Turning a CLV Thesis into Regulated Money Movement Infrastructure<\/em><\/p>\n\n\n\n

\n\n\n\n

TL;DR<\/strong><\/h3>\n\n\n\n

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\u201318% higher lifetime value than matched non-cardholders. In active build, targeting public beta Q2 2026.<\/p>\n\n\n\n

CONTEXT<\/strong><\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

PROBLEM<\/strong><\/h3>\n\n\n\n

User problem<\/strong><\/p>\n\n\n\n

Capital.com traders – particularly the high-value segment – could not access gains or working capital without initiating a bank withdrawal and waiting 1\u20133 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.<\/p>\n\n\n\n

Business problem<\/strong><\/p>\n\n\n\n

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

Example: At \u00a35B AUM and a 0.5% annual revenue yield, every 1% of at-risk AUM retained is worth \u00a325M in preserved annual revenue. <\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
Technical and regulatory problem<\/strong><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
APPROACH<\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Economic framing and financial model<\/strong><\/p>\n\n\n\n
The programme was evaluated through a card-adjusted LTV formula rather than standalone card P&L. The base model:<\/p>\n\n\n\n
Base LTV = (Average gross revenue \u00d7 customer tenure) \u2212 CAC \u2212 cost to serve<\/code><\/pre>\n\n\n\n
The card programme was designed to improve each variable. The full card-adjusted model:<\/p>\n\n\n\n
Card-adjusted LTV =\n\n  Base LTV\n\n  + retained balance value\n  + trickle-back trading revenue\n  + interchange revenue\n  + FX conversion revenue\n  + interest income on sitting balances\n  + payment cost savings\n  \u2212 card operating cost\n  \u2212 card risk cost<\/code><\/pre>\n\n\n\n
Where:<\/p>\n\n\n\n
Retained balance value = retained balance uplift \u00d7 revenue yield on retained funds<\/code><\/pre>\n\n\n\n
Revenue yield on retained funds = gross trading revenue \u00f7 average funded balance<\/code><\/pre>\n\n\n\n
Trickle-back revenue = trickle-back funds \u00d7 trading turnover multiplier \u00d7 gross revenue yield<\/code><\/pre>\n\n\n\n
Trickle-back rate = funds moved back into trading \u00f7 funds moved from trading into card balance<\/code><\/pre>\n\n\n\n
Direct card revenue =\n\n  (card purchase volume \u00d7 interchange rate \u00d7 platform interchange share)\n  + (foreign spend volume \u00d7 FX markup \u00d7 platform FX share)\n  + (active cardholders \u00d7 average sitting balance \u00d7 net interest rate \u00d7 platform interest share)<\/code><\/pre>\n\n\n\n
Net interest rate = Bank of England base rate \u2212 1.5%<\/code><\/pre>\n\n\n\n
Average sitting balance = daily card spend \u00d7 2.33<\/code><\/pre>\n\n\n\n
  (assumption: ~30% of daily balance spent, ~70% retained as sitting liquidity)<\/p>\n\n\n\n
Early modelling projected 10\u201318% 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 – \u00a325M 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). <\/p>\n\n\n\n
Internal fund movement model<\/strong><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Issuer selection and commercial negotiation<\/strong><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Compliance and regulatory architecture<\/strong><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
ARCHITECTURE<\/strong><\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Cross-currency internal fund movement – card to CFD<\/strong><\/p>\n\n\n\n
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.<\/p>\n\n\n\n\n\n\n
\n\n  
\n    
<\/span>INTERNAL FUND MOVEMENT ENGINE \u2014 SEQUENCE DIAGRAM<\/div>\n    
SOLID = REQUEST  |  DASHED = RESPONSE  |  \u27f2 = INTERNAL OPERATION  |  ORANGE = OP 1  |  AMBER = OP 2<\/div>\n  <\/div>\n\n  
\n\n\n  <\/pattern>\n  <\/marker>\n  <\/marker>\n  <\/marker>\n  <\/marker>\n  <\/marker>\n  <\/marker>\n  <\/marker>\n  <\/marker>\n<\/defs>\n\n\n\n\nUSER<\/text>\n\n\nAPP<\/text>\n\n\nLEDGER \/<\/text>\nTRANSFER ENGINE<\/text>\n\n\nRISK<\/text>\nENGINE<\/text>\n\n\nFX<\/text>\nENGINE<\/text>\n\n\nCARDS<\/text>\nSERVICE<\/text>\n\n\nBIN<\/text>\nSPONSOR<\/text>\n\n\n\n\n\n\n\n\n\n\n\u25b6 SCENARIO \u2014 GBP Card \u2192 EUR CFD Transfer<\/text>\n\n\nSelect GBP card wallet \u2192 EUR CFD, enter \u00a3500<\/text>\n\n\nFetch FX rate<\/text>\n\n\nRequest mid-market rate<\/text>\n\n\nMid-market rate returned<\/text>\n\n\u27f2 Apply CFD FX markup<\/text>\n\n\nDisplay converted amount + fee<\/text>\n\n\nShow locked FX quote<\/text>\n\n\nConfirm transfer<\/text>\n\n\u27f2 Lock rate, create transfer record<\/text>\n\n\n\n\u25b6 OPERATION 1 \u2014 GBP Card \u2192 GBP CFD<\/text>\n\n\u27f2 Reserve \u00a3500 on card ledger (eligibility check)<\/text>\n\n\nNotify trading risk service<\/text>\n\n\nApproved (no margin conflict)<\/text>\n\n\nDebit internal card ledger<\/text>\n\n\nDebit user card ledger at processor<\/text>\n\n\nDebit confirmed<\/text>\n\n\u27f2 Update shadow ledger<\/text>\n\n\nCard leg complete<\/text>\n\n\u27f2 Credit GBP CFD account<\/text>\n\n\n\n\u25b6 OPERATION 2 \u2014 GBP CFD \u2192 EUR CFD (FX Conversion)<\/text>\n\n\u27f2 Reserve \u00a3500 in GBP CFD account<\/text>\n\n\nMargin and withdrawal risk check<\/text>\n\n\nApproved<\/text>\n\n\nExecute FX conversion at locked rate<\/text>\n\n\u27f2 Apply markup, source ECN liquidity<\/text>\n\n\nConversion complete<\/text>\n\n\u27f2 Debit GBP CFD account<\/text>\n\n\u27f2 Credit EUR CFD account<\/text>\n\n\nUSER<\/text>\n\n\nAPP<\/text>\n\n\nLEDGER \/<\/text>\nTRANSFER ENGINE<\/text>\n\n\nRISK<\/text>\nENGINE<\/text>\n\n\nFX<\/text>\nENGINE<\/text>\n\n\nCARDS<\/text>\nSERVICE<\/text>\n\n\nBIN<\/text>\nSPONSOR<\/text>\n<\/svg>  <\/div>\n\n  
\n    INTERNAL TRANSFERS \u00b7 GBP CARD \u2192 EUR CFD \u00b7 TWO-OPERATION DECOMPOSITION<\/span>\n    OP 1: CARD DEBIT + CFD CREDIT  |  OP 2: GBP\u2192EUR FX CONVERSION VIA MDFX ENGINE<\/span>\n  <\/div>\n\n<\/div>\n\n