The Cross-Border Tokenization Problem in Europe
- Jun 10
- 6 min read
Written by Nicolas Grebenkine, CEO of Aetsoft
Nicolas Grebenkine is CEO of Aetsoft, an emerging tech software services company. As an investor and an entrepreneur, he’s launched 10+ products across AI, blockchain, fintech, and sustainable energy. Recognized in international accelerators, he now helps startups attract venture capital and scale globally.
When a tokenization project expands from Switzerland into the EU, teams prepare for a heavier compliance burden. The real challenge is subtler. The EU asks for the same things Switzerland does, in its own way, so reaching it usually means rebuilding a finished product to a new standard rather than bolting extra rules onto it. That gap, between the paperwork teams budget for and the engineering they actually face, is the cross-border tokenization problem in Europe.
I have written before about why crypto products fail in production, and about why the real work of tokenization is the operating model rather than the token. The thread connecting them is that a regulated digital-asset product is a system, shaped by the constraints it was built to satisfy. Change those constraints and you have changed the system, even when the token on the ledger looks identical. A border changes them more than almost anything else.
Both regimes ask for the same things
There is a common assumption that the EU is simply heavier than Switzerland, and that crossing the border means a longer list of obligations. The reality is more particular.
A regulated tokenized product has to answer the same core questions wherever it operates. Who may hold the asset and receive transfers. How and where it sits in custody. How it can be offered, and to whom. What has to be recorded and reported. Switzerland asks all of this. So does the EU. The two sets overlap heavily, yet they rarely line up exactly, and neither contains the other.
A product that satisfies Swiss requirements is finished and working. It has simply been built to one specification, and that specification is local.
The work is re-engineering
The difficulty shows up when those shared functions have to meet a different standard. Take custody. A Swiss project can often work with a local custodian or banking partner that already understands digital assets, and that relationship is enough to operate. Bring the same asset toward an EU fund structure or a regulated counterparty, and the question narrows to something specific: is it held in a form their own rules recognise? Same asset, different yardstick.
The pattern repeats across the product. Eligibility logic written for one market may not map onto how another defines who can hold what. Reporting built for one supervisor seldom transfers untouched to the next. Each of these is the original requirement redone to a standard set elsewhere, rather than a new task added on top. I have covered where those differences show up in more detail. Here, the point is the shape of the effort, not the catalogue of it.
That is why the effort gets underestimated. A new feature is bounded and visible. Reworking custody, onboarding and reporting reaches back into parts of the product everyone had marked as done.
Where the cost actually lands
This shifts where the cost of expansion falls, usually away from where teams expect it. Companies budget the EU as a legal exercise: another opinion, another filing, another review. Those costs are real but modest next to the engineering, the work of reshaping the operating model so the same asset behaves correctly under a second regime. Price the border as paperwork and the rebuild comes as a shock.
In the projects we have taken across this line, the hardest constraint has consistently been the engineering calendar, not the legal review. A team that treated the EU as a formality discovers, well into the move, that custody, onboarding and reporting all need rework before the first EU client can be served. The product rarely fails outright. It stalls. In a market where moving early still counts for something, a stall has a price of its own.
"Teams expect the EU to mean more rules. More often it means different rules, and the same functions have to be rebuilt to meet them. That is engineering work, not a bigger legal budget." – Artem Kirylin, Commercial Director at Aetsoft and individual member of the Crypto Valley Association
Why is this surfacing now?
These teams are not new to production. Many have run tokenized products for years. The change sits on the EU side of the equation, not with them.
The European target only recently became firm. On the crypto-asset side, MiCA reached full application for crypto-asset service providers at the end of 2024, and its transitional periods are now closing, with an outer limit of 1 July 2026 that several member states have already brought forward. Tokenized securities follow a separate track, under MiFID II and national securities and DLT regimes, which have been settling on their own timelines. Either way, a project that fixed its core design three or four years ago did so before today's EU framework was finalised, let alone enforced.
There is a further wrinkle. On the MiCA side, running under a transitional or national arrangement does not by itself grant the EU-wide reach that full authorisation carries. A product that has operated comfortably in one market for years may still need redesign before it can serve the rest of the EU. These teams reached production long ago. The work in front of them is meeting a target that only just stopped moving.
A decision worth making on purpose
This does not turn every project into a two-regime build from day one. A company serving a single market is right to build for that market, and a single-jurisdiction product is a legitimate, simpler thing to run.
The decision that matters is whether you expect to cross at all. Two-market design carries real upfront cost, retrofitting a finished product for a second regime usually carries more. If you know the EU is coming, accounting for it early is the cheaper path. If you know it is not, you spare yourself complexity you will never use. Both choices are sound. The one that hurts is the choice made by default, its consequences surfacing only after launch.
What designing for the crossing looks like
Designing for it does not mean building everything twice. The aim is a model where the parts most likely to differ between regimes, such as custody, eligibility and reporting, are treated as parameters set per jurisdiction rather than assumptions baked into the build. A custody model wired to one jurisdiction has to be opened up and reworked to serve another. A model that expected custody to vary absorbs the change with far less disruption.
It also means keeping legal classification and product architecture in one conversation from the start. When a change in how an asset is treated forces a change in how it was built, the two were never properly joined. Build it to be re-pointed at a new regime, not torn down and started over.
How we approach it
This is the work we do at Aetsoft. We act as a product engineering partner for regulated digital-asset platforms, and increasingly that means building the tokenization solution so a single asset can meet a second regime without coming apart. The challenge holds whether a team is working on real estate tokenization, tokenized equities, or asset tokenization more broadly, so we begin with blockchain consulting that maps the regimes and the operating model before any code is written.
Our own footing covers both sides of the question. Artem's individual membership in the Crypto Valley Association keeps us close to where many projects begin. Aetsoft's membership in House of Web3 Luxembourg keeps us close to where many of them need to operate.
The cross-border question in tokenization comes down to one thing: how differently the same product has to behave once it serves a second market, and whether that was planned for or found out the hard way.
Read more from Nicolas Grebenkine
Nicolas Grebenkine, CEO of Aetsoft
Nicolas Grebenkine is an entrepreneur, blockchain pioneer, and CEO of Aetsoft. Starting as an Investment Manager, he built expertise in spotting opportunities for emerging technologies: AI, blockchain, IoT. He has overseen the creation of 10+ in-house products, several featured in international accelerators. He now leads Aetsoft, a software company that delivers complex emerging tech solutions for enterprises and startups.
