Fleuret raises €4M to build Europe's AI pentester.

Compliance and security in ship tokenization: what EU rules actually ask

Yanis Grigy, CEO5 min read

A tokenized ship is a vessel whose ownership, or a share of its income, is split into digital tokens that investors buy and hold online. The pitch is access: a slice of a bulk carrier instead of the whole hull. In the EU, compliance and security in ship tokenization start with one question that is not technical at all: which rulebook applies. The answer decides what you owe your supervisor, and the security risk that follows is mostly not where the marketing puts it.

First question: is the token a security?

On 19 March 2025, ESMA published its guidelines on when a crypto-asset qualifies as a financial instrument. The opening rule is blunt: "Tokenised financial instruments should continue to be considered as financial instruments for all regulatory purposes." Supervisors are told to take "a substance over form approach", so putting a share on a blockchain does not change what it is.

The test for a transferable security has three parts in the guidelines: the token is not a payment instrument, it belongs to a class of interchangeable securities, and it can be traded on the capital market. A token that gives holders a stake in the ship-owning company, or a right to its charter income, reads a lot like a share or a bond. If your lawyers land there, MiFID II and the investment firm rulebook apply, not crypto rules.

If it is not a security, MiCA catches it

ESMA describes MiCA as covering crypto-assets "that are not currently regulated by existing financial services legislation". The regulation became fully applicable across the EU on 30 December 2024, and the grandfathering window for providers already operating under national law ran until 1 July 2026 at the latest. That window has closed. A platform still operating without a MiCA authorisation or a MiFID licence now has a regulatory problem before it has a security one.

Either way, DORA follows

Here the two branches meet. DORA Article 2 lists both investment firms and crypto-asset service providers authorised under MiCA among the financial entities in scope. Article 24 requires a digital operational resilience testing programme, and Article 25 names penetration testing among the tests it must include. We cover the detail in our DORA penetration testing guide and the fintech scoping page.

So a ship tokenization platform does not escape operational resilience rules by picking one classification over the other. It picks which supervisor reads its test reports.

Where the money actually leaves

The clearest recent example did not break a token. On or about 21 February 2025, around $1.5 billion in virtual assets was stolen from the exchange Bybit, a theft the FBI attributed to North Korea under the name TraderTraitor. SecurityWeek's reporting traced the path: attackers compromised a developer machine at the wallet provider Safe{Wallet}, replaced a JavaScript file in its web interface on 19 February, and made it "appear as if the funds were being transferred to the correct address" while the money went to them.

Nobody broke the token. They broke the screen the signer trusted.

A ship tokenization platform has the same shape. The token lives on a ledger, but investors reach it through a web portal, identity checks run through an onboarding flow, an admin console mints and whitelists, an API pays out charter income, and someone approves transfers on a screen. A smart contract audit covers the first item. Everything else is a web application and an API, and that is where a supervisor reading your DORA test plan will look for evidence.

What to do this quarter

  1. Get the classification in writing. Ask counsel to apply the ESMA three-part test to your token and record the reasoning. Every later obligation depends on it.
  2. Map the platform, not the contract. List every web surface and API that touches investor money or identity, including the admin console and the payout service.
  3. Test the signing path end to end. The question is not whether the contract works, it is whether the screen a signer sees can be made to lie.
  4. Ask who controls your front-end code. Third-party scripts and the build pipeline that ships them were the entry point at Bybit. Know who can change them.
  5. Keep evidence an auditor can read. A pentest report that maps findings to DORA Article 24 and 25 saves a round of questions from your supervisor.

Two questions to take to your platform provider: when was the investor portal last tested by someone trying to move money, and who signed off the report?

I'm building Fleuret around exactly this gap: the web and API layer that sits in front of the ledger. See Fleuret in action.

Sources

Share this postShare on LinkedIn
TRY IT ON YOUR APP

Scan your own code, free.

The Free plan runs SAST, DAST, SCA and secret scanning for 2 users and 10 repos, no call needed. Several apps or an audit deadline? Book a demo instead.

Start freeBook a demo