{"id":63,"date":"2026-05-04T15:49:49","date_gmt":"2026-05-04T14:49:49","guid":{"rendered":"https:\/\/lukaskoren.tech\/?page_id=63"},"modified":"2026-05-04T15:49:49","modified_gmt":"2026-05-04T14:49:49","slug":"capital-com-greenfield-debit-card-programme","status":"publish","type":"page","link":"https:\/\/lukaskoren.tech\/?page_id=63","title":{"rendered":"Capital.com – Greenfield Debit Card Programme"},"content":{"rendered":"\n

The brief<\/h4>\n\n\n\n

Capital.com is a global CFD trading platform with millions of active traders managing investment portfolios across equities, crypto, and commodities. The business had identified a structural retention problem: traders were withdrawing funds from their CFD accounts to spend money in the real world, and that withdrawal represented both a liquidity event and a permanent churn risk. The strategic hypothesis was simple – if Capital.com could issue its traders a debit card that bridged their investment portfolio and their everyday spending, withdrawal churn would decrease, assets under management per user would grow, and the card would become a genuine moat rather than a commodity feature.<\/p>\n\n\n\n

When I joined as Principal Product Manager in April 2025, there was no issuer relationship, no BIN, no compliance framework, no technical architecture, and no product. My mandate was complete zero-to-one ownership of the programme.<\/p>\n\n\n\n

What I walked into<\/h4>\n\n\n\n

The complexity here was not a product complexity problem \u2014 it was a regulatory, commercial, and architectural complexity problem arriving simultaneously. A card programme for a CFD firm is not a simple card programme. The e-money regulatory perimeter, safeguarding obligations, scheme rules, and the ledger interaction between a CFD wallet and a card wallet all had to be designed from first principles. There was no template to follow.<\/p>\n\n\n\n

The first thing I did was map the full dependency chain: issuer selection drove BIN configuration which drove settlement currency design which drove ledger architecture which drove compliance framework which drove the technology stack. You cannot work on any one of these in isolation – a decision made in contract negotiations with a card issuer constrains what your engineers can build six months later.<\/p>\n\n\n\n

I spent the first eight weeks working through every layer of this stack before committing to a vendor or an architecture.<\/p>\n\n\n\n

The shadow ledger implements strict double-entry accounting with append-only immutability – no record is ever deleted, only reversed. Every transaction carries a debit account, a credit account, a transaction ID for idempotency, a system source, and a created-by timestamp for full audit trail. This architecture was a hard regulatory requirement: the FCA safeguarding framework under PSD2 requires that client balances be reconcilable against safeguarded bank accounts daily, and that reconciliation breaks be identified, logged, and resolved within defined windows.<\/p>\n\n\n\n

The card processor selection came down to Mastercard vs Visa at a scheme level, and this was a strategic decision with long-term economic consequences. I authored the analysis and the recommendation internally. Visa operates a fixed billing currency model at BIN level: every cross-currency transaction is converted by Visa before settlement, which means the scheme becomes the FX counterparty and an unremovable cost (0.25%\u20130.55% per FX transaction) is embedded in every foreign spend. Mastercard allows the issuer to decouple billing currency from account currency and settle directly in the transaction currency when a matching balance exists – which means the issuer retains full FX control. For a product designed to eventually be FX-first and multi-currency, Visa was structurally incompatible. Mastercard was the only viable primary network.<\/p>\n\n\n\n

I also drove the multi-BIN architecture exploration with Marqeta \u2014 specifically the question of whether a single physical card could host multiple PANs, each mapped to a different BIN, network, and billing currency, with PAN selection occurring at the pre-authorisation layer based on transaction currency. This is the architecture that enables genuine zero-FX products without cross-subsidisation, and it was a central open question during vendor due diligence.<\/p>\n\n\n\n

The ledger data model I specified follows an account-transaction-entry hierarchy:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The dual-message card flow creates a two-step ledger cycle: on authorisation, a CARD_PAYMENT_REQUESTED entry moves funds from USER_BALANCE to USER_RESERVED (the funds are earmarked but not spent). On T+1 clearing, a CARD_PAYMENT_COMPLETED entry moves funds from USER_RESERVED to USER_PAYMENT (the e-money is redeemed). A reversal cancels the reservation and restores the balance in a single atomic operation. This separation is what makes safeguarding calculations accurate: only USER_PAYMENT entries represent spent e-money; USER_RESERVED entries remain as safeguarding obligations until cleared.<\/p>\n\n\n\n

Roadmap design<\/h4>\n\n\n\n

I designed and owned the full four-quarter 2026 roadmap, sequenced deliberately to validate assumptions before committing to irreversible infrastructure decisions.<\/p>\n\n\n\n

Q1 2026 – Internal Validation.<\/strong> Virtual cards only. GBP. UK IBANs. Funding and withdrawal flows. Six happy-path customer journeys and four unhappy-path journeys. No external customers, no regulatory exposure. The purpose was to prove the e2e card flow worked end-to-end on the platform before loading any real money. Success gate: all journeys pass QA, reconciliation is accurate, no orphaned ledger entries.<\/p>\n\n\n\n

Q2 2026 – Market Entry MVP.<\/strong> Physical card issuance. Funding directly from the CFD account. Merchant of Record scheme validation with Checkout.com. Transaction enrichment. Consumer Duty compliance including unhappy-path customer service journeys. Semi-automated reconciliation. The success metric was not a vanity adoption number \u2014 it was validation that card usage increased Customer Behaviour Value (CBV) and reduced withdrawal churn among the pilot cohort.<\/p>\n\n\n\n

Q3 2026 – Engagement & Differentiation.<\/strong> EU expansion. Multi-currency accounts for UK users. Cross-product withdrawal journeys from additional investment products directly into the card wallet. Cashback investment loyalty programme tied to trading activity. The FX economics of this phase depend entirely on the Mastercard multi-currency settlement architecture validated in Q1 and Q2.<\/p>\n\n\n\n

Q4 2026 – Strategic Moat.<\/strong> Internalise card authorisation. Internalise the authoritative ledger. Zero-balance card. Auth Against Assets (AAA) \u2014 the card authorises against a live portfolio value rather than a pre-funded cash balance. This is the feature that no mainstream neobank can replicate without the underlying investment infrastructure Capital.com already owns.<\/p>\n\n\n\n

PRD: Investment Cashback<\/h4>\n\n\n\n

Alongside the core programme, I authored a standalone Product Requirements Document for an Investment Cashback feature – the mechanism by which everyday card spend would be automatically converted into incremental AUM. This was not a standard cashback product. The core design insight was that paying cashback as cash has low perceived value and weak retention impact; investing it automatically removes decision friction and creates a compounding psychological lock-in as the portfolio grows.<\/p>\n\n\n\n

The PRD was structured around five testable hypotheses, each with a defined primary metric:<\/p>\n\n\n\n

H1 (Investment Activation):<\/strong> Auto-investing cashback increases monthly investment frequency because it reframes routine spending as a low-friction investment action. Metric: average monthly investment actions per user.<\/p>\n\n\n\n

H2 (AUM Growth):<\/strong> Auto-invested cashback increases AUM per user because passive contributions face lower behavioural friction than manual deposits. Metric: incremental AUM per card user vs control group.<\/p>\n\n\n\n

H3 (Card Spend Uplift):<\/strong> Direct linkage between card spend and portfolio growth increases total card spend because users perceive an additional return on every transaction. Metric: monthly card spend per active card.<\/p>\n\n\n\n

H4 (Churn Reduction):<\/strong> Accumulating invested balances decrease churn because users develop psychological switching costs tied to an invested balance they would have to liquidate and lose compounding returns on. Metric: 90-day churn rate.<\/p>\n\n\n\n

H5 (First Investment Conversion):<\/strong> Enabling cashback investing by default for non-investing card users increases first investment activation because the feature removes decision-making and perceived downside risk. Metric: % of non-investing users converting to first investment.<\/p>\n\n\n\n

The economic constraint I defined: cashback cost must not exceed 20% of gross margin generated by incremental AUM over 12 months. This prevents the feature from becoming a subsidised acquisition cost with no unit economic recovery path. MVP exclusions included multi-asset splits, gamification, and merchant-specific offers – the minimum viable version was a single investment target, daily execution, and a hard cap enforced at the user level.<\/p>\n\n\n\n

Economics<\/h4>\n\n\n\n

Why the numbers matter, and how I derived them.<\/strong><\/p>\n\n\n\n

A debit card programme for an investment platform has a fundamentally different economics model to a standalone neobank card. The card is not primarily a revenue product – it is a retention and AUM growth instrument. Measuring it purely on interchange income misses the point.<\/p>\n\n\n\n

Interchange economics at scale.<\/strong> Domestic UK debit interchange is capped under the IFR at 0.2% for consumer cards. On \u00a31,000 of monthly spend per card, that generates \u00a32.00 of gross interchange income per month. A programme of 50,000 cards at that average generates \u00a3100,000\/month in gross interchange, from which scheme fees, processor fees, and card production costs are deducted to arrive at net interchange revenue of approximately \u00a340,000\u2013\u00a360,000\/month. That is not the business case – it is a contribution to unit economics. The business case is the AUM retained on platform that would otherwise have been withdrawn to fund everyday spending.<\/p>\n\n\n\n

The FX economics of Mastercard vs Visa.<\/strong> For a product targeting traders who travel and transact globally, the volume of cross-currency card spend could be material. At \u20ac500M of annual FX volume, Visa’s unavoidable FX cost (at 0.35% average) totals \u20ac1.75M per year. An internal FX engine running at 0.10% costs \u20ac500K per year – a saving of \u20ac1.25M annually at that volume. At \u20ac1B of FX volume, the annual saving is \u20ac2.5M. The break-even volume for the complexity cost of building an internal FX engine is approximately \u20ac200\u2013300M of annual FX volume. This is the analysis that underpinned the Mastercard primary network decision.<\/p>\n\n\n\n

Engineering estimate.<\/strong> A greenfield card programme of this complexity – issuer integration, proxy ledger, multi-currency shadow ledger, CFD wallet integration, regulatory compliance framework, consumer journeys – is a substantial engineering investment. Based on the architecture described and industry benchmarks for similar programmes (Monzo’s card infrastructure build was publicly estimated at approximately 18 months with a team of 30; Revolut’s initial card launch was approximately 12 months with a leaner team but narrower scope), I estimated the Capital.com programme at 12\u201314 months to full market MVP with a team of 6 backend engineers plus QA, compliance, and DevOps support. The Q1 internal validation milestone at approximately 6 months was structurally the right gate: it validated the hardest technical problems (ledger accuracy, reconciliation, authorisation flow) before committing to the regulatory and commercial costs of a public launch. Managing a 6-person backend team on this timeline, the engineering estimate was justified by decomposing the work into three sequential horizontal layers – card processor integration and authorisation flow (6\u20138 weeks), shadow ledger and double-entry engine (8\u201310 weeks), and safeguarding reconciliation and reporting (6\u20138 weeks) – rather than attempting to build all three in parallel, which would have introduced unacceptable integration risk.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

The brief Capital.com is a global CFD trading platform with millions of active traders managing investment portfolios across equities, crypto, and commodities. The business had identified a structural retention problem: traders were withdrawing funds from their CFD accounts to spend money in the real world, and that withdrawal represented both a liquidity event and a […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":44,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-63","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=\/wp\/v2\/pages\/63","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=63"}],"version-history":[{"count":1,"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=\/wp\/v2\/pages\/63\/revisions"}],"predecessor-version":[{"id":65,"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=\/wp\/v2\/pages\/63\/revisions\/65"}],"up":[{"embeddable":true,"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=\/wp\/v2\/pages\/44"}],"wp:attachment":[{"href":"https:\/\/lukaskoren.tech\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=63"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}