DEV Community: Stella Penso

How Curve's Card Aggregation Technology Actually Works

Stella Penso — Thu, 03 Sep 2026 12:01:49 +0000

Most people who've used Curve know the basic pitch: link all your bank cards, get one physical Curve card, pick which underlying account pays for each purchase.
What's less understood is the card aggregation technology making that possible, and it's a genuinely interesting piece of payments engineering, especially now that Lloyds Banking Group has acquired the company in a deal reportedly worth up to £120 million specifically to get access to it.

The core problem card aggregation technology solves

Card networks were never designed for one physical card to represent multiple underlying accounts. A Visa or Mastercard transaction assumes a fixed, known funding source at the point of authorisation.
Curve's card aggregation technology works around that by decoupling the physical card from the funding source entirely, the card itself is essentially a token, and the actual account that gets charged is decided dynamically, either by the user in the app or by automated rules the user has configured.

That's a meaningfully different architecture from a standard debit or credit card. Every linked card gets tokenized rather than stored in raw form, which means full card details are never shared with merchants during a transaction, reducing exposure if a merchant's systems are ever breached.
The tokenization layer isn't just a security nicety here, it's structurally necessary for the whole aggregation model to work, since the system needs a stable identifier to route against that isn't the underlying card number itself.

Rule-based routing is the interesting part

The card aggregation technology gets more sophisticated once you look at the automation layer. Users can define rules that trigger a specific underlying card automatically, for transactions above a certain amount, or falling into a particular spending category like groceries or travel. Premium tiers support effectively unlimited rules.
That's a real time decisioning problem: at the point of authorisation, the system has to evaluate the transaction against a user's configured rule set and route to the correct account, fast enough that it doesn't add noticeable latency to a card present transaction.

This is the same shape of problem as any rules engine sitting in a low latency critical path, evaluate a set of conditions, pick an outcome, and do it fast enough that the user never notices the decision happened. The stakes here are just a declined transaction at checkout instead of a failed API call.

"Go Back in Time" as a retroactive ledger operation

One of Curve's more unusual features lets users retroactively move a completed transaction from one linked account to another, after the purchase has already settled. Structurally, this only works because the card aggregation technology treats the transaction record and the funding source as separable, the merchant facing transaction stays fixed, but the internal ledger entry pointing to which underlying account actually paid can be rewritten after the fact.
It's closer to how a double entry accounting system separates a recorded event from its settlement than how most consumer banking apps handle a "transaction."

Why this was worth £120 million to a legacy bank

Lloyds serves more than 30 million customers and already has around 21 million mobile app users, but building real time multi account routing, tokenized card aggregation, and a rules engine from scratch inside a large, risk averse banking institution is a multi year undertaking with real execution risk.
Acquiring Curve's card aggregation technology outright compresses that timeline dramatically, Lloyds gets a working, regulated, already scaled system instead of a multi year internal build.

It's a pattern worth recognizing beyond this one deal: when card aggregation technology or any comparably complex financial infrastructure already exists, proven and regulated, in the market, acquiring it is frequently faster and lower risk than building an equivalent system internally, even for an organisation with far more engineering resources than the acquisition target.

The takeaway

Curve's card aggregation technology is a solid case study in decoupling a fixed external interface (a physical card, a card number) from a flexible internal system (dynamic routing, retroactive ledger changes). That separation is what let a company with roughly six million users build something a bank with 30 million customers found faster to buy than to build.
It's a pattern worth remembering for anyone designing systems where the external contract needs to stay stable while the internal logic needs room to evolve, a lesson we come back to often when covering UK fintech infrastructure deals at Entrepreneur Plus UK.

How Does iwoca Make Money? Inside the Data-Driven SME Lender Now Eyeing a Billion-Pound Sale

Stella Penso — Tue, 25 Aug 2026 07:42:43 +0000

What is iwoca? It's a UK fintech lender, founded in 2012 by Christoph Rieche and James Dear, built around a simple bet: traditional banks were too slow and too rigid to serve small businesses properly, and open banking data could underwrite them faster and more accurately than a manual credit committee ever could.
That bet has scaled into one of the UK's largest alternative SME lenders, backed by Augmentum Fintech and Commerzbank's CommerzVentures arm, and reportedly now the subject of a sale process advised by Qatalyst Partners that could value the company north of £1 billion.

So how does iwoca make money, exactly? Two engines, both built on the same underlying data infrastructure.

Engine one: the Flexi-Loan

The core product is the iwoca Flexi-Loan, an unsecured revolving credit facility ranging from £1,000 up to £500,000. Rather than a fixed lump-sum loan, businesses draw down what they need through the Flexi-Loan, repay early without penalty, and only pay interest on the days they're actually holding the money.
Rates typically start around 1.5%–2% per 30 days on the outstanding balance, working out to a representative APR that commonly lands in the high-40s for riskier borrowers, expensive relative to a high-street bank loan, but the point of the Flexi-Loan isn't to compete with a bank on price. It's to compete on speed and accessibility for businesses banks won't touch.

That's where iwoca's open banking lending model earns its keep. Instead of leaning on historical credit scores the way a traditional bank does, iwoca connects directly to a business's accounting software, bank accounts, and transaction history via open banking, and runs that live financial picture through its own risk algorithm.
This open banking lending approach means decisions often come back within hours rather than weeks. It's the same underwriting logic used by cash-flow lenders more broadly: real, current transaction data is a better predictor of repayment ability than a static score, even if it's a harder engineering problem to build reliably.

Engine two: iwocaPay

The second, faster-growing revenue stream is iwocaPay, iwoca's entry into B2B buy now pay later. Instead of lending directly to a business, iwocaPay sits inside another company's checkout or invoicing flow, at a WooCommerce or Shopify store, or synced through accounting platforms like Xero and QuickBooks, and lets a business's trade customers pay later while the seller gets paid immediately.
iwoca takes on the credit risk through iwocaPay and charges a fee on the transaction; the buyer either pays interest-free (if the seller absorbs the cost) or pays iwoca directly, depending on how the seller configures it.

This matters strategically because B2B buy now pay later is a genuinely fast-growing category in the UK, one of several the market is expected to consolidate around as compliance costs rise and open banking data becomes more available. iwoca isn't the only player, Kriya and Hokodo compete in the same B2B buy now pay later space, but it's one of the few with an existing SME lending book and underwriting engine to plug the product into.

Is iwoca FCA regulated?

Yes. If you've been asking yourself is iwoca FCA regulated before trusting it with your business's cash flow, the answer is straightforward: iwoca's consumer-facing credit activity is authorised and regulated by the FCA, which matters for anyone comparing it against unregulated invoice-factoring or informal lending alternatives.
Being FCA regulated doesn't make the product cheap, but it does mean standard consumer credit protections and complaint routes apply.

Where this is heading

The reported £1 billion+ sale process, with lending volumes up 60% year-on-year and the number of SMEs funded rising from 60,000 to 96,000 in a single year, suggests the model is scaling faster than most alternative lenders in the category.
Whether that ends in an acquisition by a strategic buyer or private equity, the underlying thesis stays the same: build the underwriting infrastructure once, then sell access to it two ways, direct loans through the Flexi-Loan, and embedded credit through iwocaPay, off the back of the same open banking lending data pipeline.

300 Customer Interviews Before Writing a Line of Code - The Discovery Process Behind Omnea

Stella Penso — Fri, 07 Aug 2026 07:21:56 +0000

Most "how we built it" write ups start with the tech stack. This one starts earlier: with 300 conversations a founder had with procurement leaders before deciding what to build at all.
Omnea's founder, Ben Freeman, spent that discovery phase hearing some version of the same complaint repeatedly, that procurement processes were widely disliked and the tools available were clunky, but nobody had actually rebuilt the stack from scratch.

Why this matters more than the eventual tech choices

It's tempting, especially as an engineer, to treat product discovery as a soft skill separate from the "real" work of building. But the actual technical decisions Omnea made afterward, betting on a two way data orchestration layer instead of a simple dashboard, prioritizing natural language intake over form based requests, only make sense in light of that discovery process.
If you skip straight to architecture without understanding the actual failure mode users are living with, you tend to build a technically impressive solution to the wrong problem.

From validated pain point to funding

The pattern that followed is a fairly clean funding trajectory worth noting for anyone tracking how enterprise SaaS companies scale post discovery: a $20 million Series A once the initial product had traction, followed roughly a year later by a $50 million Series B after the company had grown revenue roughly 5x and more than tripled headcount, bringing total funding north of $75 million.
Enterprise customers including Spotify, Wise, and MongoDB came on during that window, which is a meaningfully different growth signal than early consumer traction, enterprise sales cycles are slower and more scrutinized, so revenue growth at that pace usually reflects genuine operational value rather than a viral feature.

The discipline of staying narrow

One detail worth flagging for engineers specifically: Omnea didn't try to become a general purpose enterprise workflow tool. It stayed scoped to the supplier lifecycle, intake, approvals, risk management, renewals, rather than expanding sideways into adjacent problems the moment funding arrived.
That kind of scope discipline is hard to maintain once you have the resources to build more, and it's frequently the difference between a product that does one thing reliably and one that becomes brittle trying to do everything.

The takeaway

The unglamorous part of this story, the hundreds of unpaid conversations before a single line of production code, is usually the part that gets compressed into a single sentence in startup founder stories, right before the section about the funding round. But it's the part that actually determined whether the eventual architecture solved a real problem or an imagined one.
If you're building anything for an enterprise audience, the lesson generalizes cleanly: the discovery work isn't preamble to the engineering, it's the spec.

What Happens to Your Integration When Your Payments Vendor Gets Acquired

Stella Penso — Tue, 04 Aug 2026 07:14:05 +0000

If you follow UK tech news, fintech M&A shows up often enough that it's worth planning for as an engineering risk, not just a business one. A few recent examples make the pattern pretty clear.

The pattern shows up more than you'd think

When Visa acquired Plaid in a deal reported at $5.3 billion, the acquisition itself didn't break anything overnight, but it changed the trajectory of the product: enterprise first commercial terms became more prominent, and smaller teams increasingly found onboarding heavier than with leaner competitors.
TrueLayer's own migration from its Payments v2 API to v3 required developers to handle new mandatory request signing and restructure how pay-in creation and authorization were split into separate steps, a non-trivial integration change for anyone on the old version. And GoCardless's acquisition of the open banking provider Nordigen in 2022 came with a scaled-back free tier not long after, which pushed a chunk of smaller developers and indie fintechs to re-evaluate their stack entirely.

None of these are edge cases. If you build on a third-party payments API, at some point you are statistically likely to be on the losing end of an acquisition, a pricing change, or a forced migration.

Practical mitigation, not paranoia

You don't need to avoid third-party payment APIs, that's not realistic, but a few patterns meaningfully reduce your exposure:

Build a thin abstraction layer. Don't let your business logic call the vendor SDK directly from a dozen places in your codebase. Wrap payment initiation, mandate management, and webhook handling behind your own internal interface. When a provider changes its API surface or you need to swap providers, you're editing one adapter instead of hunting through your entire codebase.

Store your own canonical payment state. Don't treat the vendor's dashboard or API as your only source of truth. Persist mandate IDs, payment statuses, and webhook events in your own database, keyed by your internal references, not just theirs.
If a migration forces you to re-point to a new API version, or a new company entirely post-acquisition, you want your historical data intact and queryable without depending on the old vendor's API still working.

Watch for signal, not just announcements. Free-tier scale-backs, slower support response times, and increasingly enterprise-flavored sales conversations tend to precede bigger platform shifts. They're not proof of anything on their own, but they're worth tracking if a huge chunk of your revenue runs through one payment provider.

Budget migration time into your roadmap, even speculatively. Teams that treat "our payments provider might change" as a real possibility instead of a hypothetical tend to handle forced migrations (like the TrueLayer v2 to v3 move) in days instead of months, because the abstraction layer was already there when they needed it.

The underlying lesson isn't really about payments specifically. It's about recognizing that any vendor API you depend on is a dependency with its own business risk attached, and a little architectural distance up front is cheap insurance against a migration you didn't choose the timing of.

The Indie Hacker's Guide to UK Business Banking in 2026

Stella Penso — Sat, 01 Aug 2026 07:55:17 +0000

If you're building a SaaS or side project as a solo founder in the UK, your bank account is infrastructure as much a part of your stack as your hosting bill. Most founders pick a bank in five minutes because a friend mentioned it, then spend the next two years quietly overpaying or missing tooling they didn't know existed.

Here's what actually matters if you're bootstrapping, and which of the five main UK digital business accounts fits which kind of indie founder in 2026 because banking is one of those unglamorous decisions that quietly shapes how well you operate inside the wider UK startup ecosystem, long before anyone's talking about your product.

The five accounts, briefly

Starling Business — free, unlimited UK transfers, FSCS protected up to £85,000, real-time feeds into Xero, QuickBooks, and FreeAgent. As a fully licensed bank, it's the only one on this list that offers overdrafts and lending as you scale. The catch: it runs a hard credit check, which shows up on your credit file and can affect other lending applications if you're raising or applying for a mortgage around the same time.

Tide — built for speed. Account opens in under five minutes with no credit check, and the free plan includes three invoices a month plus categorisation. If you invoice clients directly (a lot of solo SaaS and consultancy founders do), this is the account that removes the most friction from getting paid. Transfers cost £0.20 each after the first five free ones monthly — at 50 transfers a month that's roughly £9.

Mettle — free forever, no transaction fees, and it bundles FreeAgent (normally around £150/year) at no extra cost. This is the strongest pick for a UK-only sole trader who wants accounting software handled without adding another subscription. Limitation: no international payments, single-user access, no overdraft — so it doesn't scale well past a one-person operation.

Monzo Business — Lite tier is free with FSCS protection up to £120,000 and a built-in Making Tax Digital tax tool. Pro tier (£9/month, first month free) unlocks invoicing and full accounting integrations. If you're GBP-only and want a bank-grade safety net without complexity, this is a clean option — just know invoicing sits behind the paywall.

Revolut Business — the one to reach for if you're selling internationally. Holds 25+ currencies at interbank rates for your first £1,000 monthly on the Basic plan, then charges 0.6% FX on weekdays. It's also the only account here with proper API access for automating payments and reconciliation relevant if you're building your own billing logic rather than relying purely on Stripe payouts. Costs £10/month minimum, so it's not the right pick if you're GBP-only.

Matching the account to your stage

Pre-revenue, testing an idea: Mettle or Monzo Lite. Zero cost, zero risk, and you can switch later without much pain.
First few paying clients, invoicing directly: Tide. The built-in invoicing pays for itself in time saved.
Scaling past £1k MRR, want lending headroom eventually: Starling. The credit-check trade-off starts making sense once overdraft or lending matters.
Selling to US/EU customers, getting paid in USD or EUR: Revolut. Multi-currency isn't a nice-to-have here, it's the whole point.

What nobody tells you about "free" banking

Every account on this list has a free tier, but "free" only means free at your specific transaction pattern. Tide's free plan turns expensive fast if you're doing 50+ transfers a month. Starling's Post Office cash deposit fee (0.7%, minimum £3) matters if you're taking cash payments. Read the fee schedule against how you'll actually get paid not against the marketing page.

The one-line takeaway

There's no universally "best" account here — there's a best account for how you get paid. Map your typical month (how many transfers, whether you invoice, whether you touch foreign currency) against these five before you commit, because switching banks mid-year is its own kind of tax on your time.

Fees, limits, and integration details current as of mid-2026 — always confirm directly with the provider before opening an account, as fee structures shift.

Allica Bank Just Hit Unicorn Status, Here's What's Actually Interesting About the Round

Stella Penso — Tue, 21 Jul 2026 08:29:27 +0000

A bank hitting a $1.2B valuation isn't usually dev.to material. But the shape of this raise where the money's going and what it signals about scaling a fintech internationally is worth a look, especially if you've ever wondered how "buy vs build" plays out at the company level, not just the codebase level.

The number

In February 2026, Allica closed a $155 million Series D (about £111 million), pushing its valuation to roughly $1.2 billion. That puts it in a pretty small UK club — Revolut, Monzo, Starling, and Zilch are the only other UK fintechs to cross the billion-dollar mark.

The investor lineup is arguably more interesting than the valuation itself. New money came from Ventura Capital, GLG, and Sona AM. But two existing backers TCV (in since 2022) and Blue Owl (in since 2021) doubled down too. Existing investors re-upping is usually a stronger signal than new logos showing up; it means the people who've had visibility into the real numbers for years are still buying in.

Where this sits in the funding timeline

Quick context: back in December 2022, Allica closed a £100 million Series C, backed by Warwick Capital Partners and Atalaya Capital Management (Atalaya had actually come in earlier, in November 2021). That round ran alongside a separate debt facility from British Business Investments worth noting because it shows two funding tracks running in parallel: equity to build the company, debt to actually fund the loan book.

Three years later, at the Series D, Allica had scaled to over 30,000 customers and about 5% penetration of its target market (established SMEs with 5–250 employees). Their own stated goal is to double that to 10% by 2028.

The part that makes this round different: it's funding expansion, not just more of the same

Every previous round funded UK lending. This one doesn't. A chunk of the Series D is explicitly earmarked for expansion outside the UK — reportedly Northern Europe and Allica appears to be leaning toward acquiring a bank there rather than building a new licence from scratch.

That tracks with how they've operated domestically. Both the Tuscan Capital and Kriya acquisitions point to a company that consistently chooses to buy capability rather than build it slowly in-house.
It's the same instinct playing out at a bigger scale: instead of spending 18 months getting licensed and building trust in a new market, buy an entity that already has both.

If you've ever made the buy-vs-build call on infrastructure do you stand up your own auth system or just buy Auth0 this is the company scale version of that same tradeoff.

AI gets a specific line item

The funding announcement also called out continued investment in Allica's proprietary tech stack, specifically AI applied to lending decisions. This lines up with earlier comments from CEO Richard Davies about using AI to speed up the lending pipeline and cut consultancy costs — not customer-facing AI features, just faster and cheaper decisioning under the hood.

So this raise isn't funding a new AI initiative, it's funding more of a discipline that was already underway, at a bigger scale.

There was also a government nod here: Economic Secretary to the Treasury Lucy Rigby pointed to the round both new and returning international investors as a signal of confidence in UK fintech more broadly.

Does "unicorn" actually change anything?

Not operationally. Allica isn't lending differently or running differently day-to-day because of a valuation number. What it does change is optionality easier access to future capital, and more credibility walking into acquisition conversations abroad.
It also puts Allica in the same sentence as Revolut, Monzo, and Starling in press coverage, even though its actual business (relationship-driven SME lending) looks nothing like theirs.

The real story

Zoom out and Allica's funding history has quietly shifted purpose three times:

Early equity + debt — build the domestic lending book
2022 Series C — scale that book further
2026 Series D — fund AI investment and the first move outside the UK The valuation is the headline everyone will repeat. The actual news is that redirection a fintech that spent five years heads-down on one country and one customer segment now has a war chest earmarked for doing the same thing somewhere else.

Whether "buy a bank instead of building a licence" works as cleanly abroad as the domestic acquisitions did is the open question. But it's a genuinely different playbook than most challenger banks have tried.