The EU has roughly 49 million crypto holders. It has a stablecoin settlement volume of about $27.6 trillion. It has MiCA, enforced on stablecoins since June 2024 and on full CASP authorization since January 2025, giving crypto its clearest operating framework anywhere in the world outside Singapore. And from October 2025, every EU bank and EMI must send SEPA Instant payments. Ten-second settlement, 24/7/365.

What the EU doesn't have yet: consumer-facing crypto products that actually work. Not "you can buy crypto on your exchange app" (that's been around for years). Something closer to "you can pay your rent, your utilities, and your subscriptions directly from stablecoin yield, without juggling five apps and a spreadsheet." Something that integrates into your existing bank or neobank as a feature shelf, not as a separate jurisdictional silo.

I've spent the last 18 months talking to the people on the inside of this gap. Heads of product at MiCA-licensed neobanks. CTOs at crypto-native fintechs. Compliance leads at EMIs who see the opportunity but can't get engineering to carve out a year and a half of roadmap. The same pattern comes up in every call.

The pattern

The licensed fintech sees the opportunity. MiCA plus SEPA Instant plus EURC plus USDC Europe equals a window where regulatory clarity and rail maturity finally align. Their board is asking. Their users are asking. Their competitors in three Berlin coworking spaces are shipping.

The licensed fintech can't ship. Not because they don't understand crypto. Many of them understand it better than the "Web3 native" companies they're competing with. They can't ship because an in-house build is 12 to 18 months of specialist engineering, plus 1 to 2 compliance hires who understand MiCA and EU TFR Article 14 well enough to pass an internal audit, plus 4 to 6 vendor integrations (custody, wallet infrastructure, ramp aggregation, Travel Rule, AML screening, EMI rails) that all have to be maintained as regulations evolve.

The number I hear most is "€1.5 to 3 million first-year cost, plus the opportunity cost of what our eng team is NOT doing instead."

So the licensed fintech doesn't ship. Or it ships something thin. A "hold crypto" feature that doesn't use the yield, doesn't pay bills, doesn't automate anything. A checkbox feature that doesn't differentiate.

That's the gap. And it's not going to be filled by the companies who built the early Web3 stack. ZeroDev, Biconomy, Privy, Safe{Core}, Onramper, Notabene, Chainalysis. Each of those is excellent at one thing. None of them stitch together into a unified stack that a compliance team can pre-clear before the first BD call. Each one is its own contract, its own integration cycle, its own ongoing maintenance burden, its own sub-processor paperwork.

What we're building

OVAAL is the opposite bet. Instead of another specialist layer, we're building the bundled stack. Wallets (AA-native, ERC-4337, non-custodial), ramp aggregation (with real success-probability scoring; single-ramp on-ramps in Europe still fail roughly half the time), bill-pay (from USDC and EURC via SEPA Instant rails, under the partner's MiCA-licensed EMI or banking authorization), automation (plain-English DCA, take-profit, DeFi macros), and the compliance stack that's non-negotiable in EU fintech (Travel Rule via Notabene or 21 Analytics, AML screening via Chainalysis or TRM, audit-log export that auditors actually accept).

One SDK. One contract. One integration engineer from us for the 4 to 8 weeks it takes to go from signed paperwork to the partner's users being live. You keep the license. You keep the user. You keep the brand. We're infrastructure.

What we explicitly aren't

I want to be honest about the trade-offs:

  • We don't have the depth of a specialist in any single category. ZeroDev's AA SDK is more mature than ours. Onramper covers more ramps. Notabene has more Travel Rule history. If depth in a single capability matters more to you than integration reduction, go with the specialist. We'll tell you that on the first call if it's the right answer.
  • We're non-custodial. If you need a licensed custodian holding the funds, we're not that vendor. Our architecture puts the signing authority on the end-user's passkey or MPC share. End-user funds never sit in our infrastructure. That means your users' funds can't be trapped if OVAAL disappears. They're on-chain, under the end-user's keys. It also means our liability posture is cleaner: we're not the custodian, we're the orchestrator.
  • We don't hold a retail license. We're not going to become a CASP. Partners hold the authorization. OVAAL operates within partners' authorization. This isn't a hedge. It's an architectural commitment. Every piece of our stack is designed to execute against partner's compliance policy, not against OVAAL's own licensing constraints.
  • We don't operate in the US. MiCA plus VARA plus CBB is the V1 scope. The US regulatory landscape isn't clear enough for the model to work, and our wedge is specifically the EU and MENA clarity.
  • We're not a consumer brand. Your users see your brand, not ours. "Powered by OVAAL" is a partner choice; most partners don't surface us at all. We win when you win. We lose when you lose.

Why now

There's a real "why now" for this bet, and it's worth stating plainly:

  • June 2024: MiCA stablecoin enforcement. EMTs (USDC, EURC) are the compliant default for EU consumer flows. USDT lost its major EU CASP distribution over the following months. The stablecoin rails the infrastructure depends on are now legally stable in EU, not speculative.
  • January 2025: MiCA full CASP. Full regulatory framework live. Partners can plan around it. Regulators can enforce it. No more "maybe rules will change" risk for partners scoping a crypto product.
  • October 2025: SEPA Instant send mandate. Every EU EMI and bank must send SCT Inst. Universal ten-second settlement. This is the thing that made bill-pay from crypto finally work in Europe. Previously, "pay your landlord in crypto" was slow enough that the user dropped off. After October 2025, it's card-rail-competitive on latency.
  • 2024 to 2025: Account Abstraction maturing. ERC-4337 shipped in production on every major chain during 2023 to 2024. By 2025, AA wallet infrastructure is not experimental. It's what serious Web3 products are deploying. Passkey onboarding and session-key automation are primitives we can reliably build on.
  • MENA runs parallel. VARA (UAE, from 2022) and CBB (Bahrain, from 2021) frameworks matured during the same window. Crypto-native fintechs in Dubai and Manama have a clearer path than their US counterparts.

Four of these five structural shifts finished happening within the last 24 months. The window for a bundled MiCA-native infrastructure layer is open now. It won't stay open forever. Specialist vendors will eventually bundle, or one of the big fintech API platforms will extend into this space. Our bet is that we get there first with an architecture partners trust.

Who we're building this for

I want to name the partners explicitly, so you can self-assess whether we're the right vendor for you:

  • Priya, Head of Product at a MiCA-licensed neobank in Amsterdam. You own the crypto product surface. You've been saying "we should do something in crypto" for two years. Your eng team has been saying "that's an 18-month build, here's the Gantt." We resolve this argument for you.
  • Omar, CTO at a VARA-licensed broker in Dubai. You've shipped the MVP. You're choosing between deepening in your own stack or bringing in infrastructure that lets you consolidate vendors and focus on the parts that are actually your differentiation. Your architecture team will review our SDK the week we send it; if it's not good enough, you'll tell us.
  • Sofia, Head of Compliance at an EMI-turned-crypto-fintech in Vilnius. You kill any integration that can't pre-clear with your auditor. We ship the partner compliance pack (DPA, sub-processor list, legal opinions, audit log export) before the first BD call, so your review can happen before your BD team loses momentum.
  • Jakub, VP BD at a wallet-provider startup in Warsaw. You own partnership-driven revenue. You need transparent commercials, clear co-marketing terms, and a joint roadmap conversation. We publish commercial ranges on ovaal.io/pricing and negotiate per-partner commercials on the first sizing call.

We're not for everyone. We're not for solo founders who haven't figured out their licensing path. We're not for US-only fintechs. We're not for CTOs who want to be maximally non-custodial and also want us to do things that non-custodial architecture can't do. And we're not for teams who want to bolt us on halfway through a build they've already committed to in-house. Come to us at the start, or come to us for a specific capability you've decided to outsource, but don't come to us mid-build.

What's next

We're about to launch ovaal.io as a proper partner-acquisition site. Not because the site launch is the product milestone. The product milestone is the first partner going live, which will happen inside a partner's app, not ours. But because getting ovaal.io to a credible-infrastructure register matters for the deck flow. When a MiCA-licensed neobank CTO receives a 40-slide deck and clicks through to our site, what they see has to reinforce the deck, not undercut it.

The site isn't the hero. The partners we sign over the next 12 months are. If you're at a licensed EU or MENA fintech and the gap I described above is the one you're hitting, I'd like to talk.

Get the integration brief. Or email me directly.