Start with what the EU already has. A stablecoin settlement market worth about $27.6 trillion a year. MiCA, enforced on stablecoins since June 2024 and on full CASP authorisation since January 2025. From October 2025, every EU bank and EMI has to send SEPA Instant. Settlement in seconds, around the clock. The regulation is set and the rails are live.

What licensed fintechs do not have is the layer that ties it together. They can hold a license, plug into a bank, plug into a wallet vendor, plug into a ramp. What they cannot easily build is the control plane above all of that: the part that decides who or what may move money, routes each instruction across the right provider, records it from authorisation through settlement, reconciles it, and hands an auditor a clean trail. That is the missing piece, and it is the piece we built.

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

The pattern

The licensed fintech sees the opportunity. Regulatory clarity and rail maturity have finally lined up at the same time. The board is asking. Users are asking. Competitors two coworking spaces over are shipping.

The licensed fintech still cannot ship. Not for lack of understanding. Many of these teams understand the rails better than the companies they compete with. They cannot ship because an in-house build runs 12 to 18 months of specialist engineering, plus a compliance hire or two who know MiCA and EU TFR Article 14 well enough to pass an internal audit, plus a handful of vendor integrations (custody, wallet infrastructure, ramp aggregation, Travel Rule, AML screening, EMI rails) that all have to be kept current as the regulation moves.

The number I hear most is around €1.5 to 3 million in first-year cost, before you count what the engineering team is not building instead.

So the licensed fintech does not ship. Or it ships something thin. A "hold an asset" feature that never moves the money or reconciles against anything. A checkbox that changes nothing.

That gap is not going to be closed by adding one more rail. The prior generation of infrastructure, the smart-contract wallet vendors, the ramp aggregators, the Travel Rule and screening specialists, each solved one slice well. None of them is the layer that governs an instruction across all of those slices, records it end to end, and hands a compliance team something they can pre-clear before the first BD call. Each one is its own contract, its own integration cycle, its own maintenance, its own sub-processor paperwork. Wire four of them together and you, not the vendor, own the seams between them.

What we built

OVAAL is the opposite bet. Instead of one more rail, we built the layer that sits above the rails. Think of it as a control plane for money movement: accounts and wallets (AA-native, ERC-4337, non-custodial), money movement routed across eligible providers (single-ramp on-ramps in Europe still fail roughly half the time, so routing and success scoring earn their place), settlement and reconciliation that follows an instruction from authorisation through receipt as one record, policy and automation that decides who or what may initiate a financial action and under which limits and approvals, and a risk and compliance layer wired into the execution path through configurable integrations: a Travel Rule provider, an AML screening vendor, sanctions and transaction-monitoring workflows, and audit-log export that an auditor will accept. Crypto is the first rail we proved on, not the ceiling of what the plane is for.

One SDK. One contract. One integration engineer from us. We designed the integration to land in roughly 4 to 8 weeks from signed paperwork to a partner's users being live; that is a design target, not a published case retro, and real timelines depend on scope, regulatory responsibilities and provider onboarding. You keep the license. You keep the user. You keep the brand. We are the infrastructure underneath.

What we are not

Worth being honest about the trade-offs:

  • We are not the deepest in any single slice. The prior-generation specialists, the smart-contract wallet vendors, the ramp aggregators, the Travel Rule houses, each go deeper in their own category than a control plane does. If raw depth in one capability matters to you more than collapsing the integration surface, the specialist is the right call, and we will tell you so on the first call.
  • We are non-custodial. If you need a licensed custodian holding the funds, that is not us. Signing authority sits on the end-user's passkey or MPC share, so end-user funds never sit in our infrastructure and cannot be trapped if OVAAL disappears. They stay on-chain, under the end-user's keys. It also keeps our liability posture clean: we orchestrate, we do not custody.
  • We do not hold a retail license. We are not going to become a CASP. Partners hold the authorisation; OVAAL operates within it. This is not a hedge, it is an architectural commitment. Every part of the control plane executes against the partner's compliance policy, not against a license of our own.
  • We do not operate in the US. The V1 scope is EU plus VARA plus CBB. The US regulatory picture is not clear enough for the model to hold, and the EU and MENA clarity is the whole point of the wedge.
  • We are not a consumer brand. Your users see your brand, not ours. "Powered by OVAAL" is a partner choice, and most partners do not surface us at all. We win when you win.

Why now

There is a real "why now" here, and it is worth stating plainly:

  • June 2024: MiCA stablecoin enforcement. EMTs such as USDC and EURC became the compliant default for EU flows, and USDT lost major EU CASP distribution over the months that followed. The settlement rails the control plane routes over are now legally stable in the EU, not speculative.
  • January 2025: MiCA full CASP. The full framework went live. Partners can plan around it and regulators can enforce it. The "maybe the rules will change" risk came off the table for anyone scoping a programmable-finance product.
  • October 2025: SEPA Instant send mandate. Every EU EMI and bank now has to send SCT Inst, so near-real-time settlement is the baseline rather than the exception. That is what makes settling a payment out of a digital-asset balance viable in Europe; before it, the latency was high enough that users dropped off mid-flow.
  • 2024 to 2025: account abstraction matured. ERC-4337 reached production on every major chain across 2023 and 2024. By 2025 the wallet infrastructure is no longer experimental, and passkey onboarding and session-key automation are primitives a control plane can build on reliably.
  • MENA runs in parallel. VARA in the UAE (from 2022) and CBB in Bahrain (from 2021) matured over the same window, so licensed fintechs in Dubai and Manama have a clearer path than their US counterparts.

Four of these five shifts finished inside the last 24 months. The window for a neutral control plane built for EU and MENA finance is open now, and it will not stay open forever. The single-purpose vendors will eventually try to bundle, or a large fintech API platform will reach into this space. The bet is that we get there first with an architecture partners actually trust.

Who we built this for

It is easier to name the partners directly, so you can judge whether we fit:

  • Priya, Head of Product at a licensed neobank in Amsterdam. You own the programmable-finance surface. You have been saying "we should do something here" for two years, and your eng team has been answering with an 18-month Gantt chart. The control plane settles that argument: you embed it under your own license and ship the surface without the build.
  • Omar, CTO at a VARA-licensed broker in Dubai. You have shipped the MVP and now you are choosing between deepening your own stack or bringing in a layer that lets you consolidate vendors and spend your engineers on what is actually your differentiation. Your architecture team will review our SDK the week it lands, and if it is not good enough they will say so.
  • Sofia, Head of Compliance at an EMI-turned-fintech in Vilnius. You kill any integration that cannot pre-clear with your auditor. We hand over the partner compliance pack, the DPA, sub-processor list, responsibility matrix and audit-log export, before the first BD call, so your review runs before your BD team loses momentum.
  • Jakub, VP BD at a wallet platform in Warsaw. You own partnership revenue and you need transparent commercials, clear co-marketing terms and a joint roadmap conversation. We publish our published commercial ranges and size per-partner terms on the first call.

We are not for everyone. Not for solo founders still working out their licensing path. Not for US-only fintechs. Not for teams that want to be maximally non-custodial and also want the plane to do things non-custodial architecture cannot. And not for teams trying to bolt us on halfway through a build they already committed to in-house. Come to us at the start, or for a specific capability you have decided to outsource, but not mid-build.

What is next

We are launching ovaal.io as a proper partner-acquisition site. The site is not the milestone; the milestone is the first partner going live, and that happens inside their app, not ours. But the site has to read like serious infrastructure, because when a licensed neobank CTO clicks through from a deck, what they find has to reinforce it rather than undercut it.

The site is not the hero. The partners we sign over the next 12 months are. If you are at a licensed EU or MENA fintech and the gap above is the one you keep hitting, I would like to talk.

Book an architecture review, or get the integration brief. Or email me directly.