StablR Cyber Incident: What Did the MFSA Supervise?
On 24 May 2026, Malta-regulated stablecoin issuer StablR Ltd detected irregularities in its platform infrastructure consistent with unauthorised external access. By the following day, the company had suspended the minting and redemption of its EURR and USDR tokens and acknowledged that their circulating supply was no longer fully backed at the 1:1 ratio required under MiCA. Exchanges and trading venues were asked to suspend trading, deposits and withdrawals.
As of 22 July 2026—almost two months after the incident—the latest official update identified by EFRI remained StablR’s notice of 8 July. StablR stated that the incident had been contained and that no further unauthorised issuance had occurred. Minting and redemption nevertheless remained suspended and StablR reported “no material changes” to its previous position.
This was not a peripheral IT outage.
For a fiat-backed stablecoin issuer, control over token issuance is the product. Under MiCA, e-money tokens are issued at par upon receipt of funds and must be redeemable at par. If an attacker can create additional tokens without corresponding reserves, the issuer loses control over its liabilities even where the previously safeguarded fiat assets remain untouched.
The StablR cyber incident therefore struck at the core of the regulated stablecoin model: control over minting, full backing and redemption at par.
It also occurred less than eleven months after EFRI had formally raised concerns with the MFSA about StablR’s management history, ownership and governance.
EFRI warned the MFSA in July 2025
In July 2025, EFRI asked the MFSA, with the European Banking Authority in copy, to reassess StablR’s electronic-money institution licence.
EFRI raised concerns about the role of former Payvision executives in StablR’s management, the publicly unclear ownership and control behind its Dutch parent Plutus B.V., and the absence of any public explanation of how Payvision’s serious AML and supervisory history had been considered during the MFSA’s fit-and-proper assessment. EFRI’s detailed findings on Payvision’s role in the Barak and Lenhoff investment-fraud networks are set out in a separate report.
EFRI did not claim that every former Payvision executive was personally responsible for every failure attributed to Payvision. The issue was supervisory memory.
A regulator assessing the competence, integrity and judgement of senior managers should examine their actual management history, the control environment in which they operated and the relevance of that history to their new functions. It should not treat a change of company name and business model as a clean regulatory slate.
EFRI has identified no substantive public MFSA response to those questions.
Less than eleven months later, the need for rigorous scrutiny of StablR’s governance and controls was no longer theoretical. A regulated stablecoin issuer managed by former Payvision executives admitted that unauthorised access had resulted in underbacked tokens and the suspension of its core issuance and redemption functions.
StablR is managed by former Payvision executives
StablR’s regulatory whitepaper identifies Gijs op de Weegh as chief executive officer and director and Corné van der Meijden as chief risk and operations officer and director. Both are also directors of StablR’s Dutch parent, Plutus B.V., and of STB Software Development B.V., the Dutch group company that owns StablR’s IT and platform.
Op de Weegh co-founded Payvision, served as its chief operating officer and remained on its management board until 30 April 2020. Van der Meijden served as Payvision’s chief financial officer and became a statutory management-board member in 2020.
Payvision was subsequently the subject of a Dutch criminal investigation concerning money laundering and compliance with Dutch AML legislation, covering the period from January 2015 through April 2020. The investigation against Payvision itself was closed without charges in April 2024, as the company was closed down by then. The Dutch Public Prosecution Service nevertheless imposed penalty orders of EUR 150,000 and EUR 180,000 on two former Payvision directors for having effectively directed years of structural AML violations.
None of this proves that op de Weegh or van der Meijden caused or contributed to the StablR incident. It does establish that the MFSA licensed an institution whose senior management came from a payment company with a directly relevant compliance and control history.
That history should have triggered enhanced scrutiny of governance, outsourcing, privileged access, internal controls, risk management and board oversight.
The public cannot determine whether it did.
The regulated entity did not own the technology platform
StablR’s corporate structure creates a separate supervisory question.
The whitepaper states that StablR Ltd is the licensed Maltese entity and owns the legal structure, policies and procedures. The IT and platform are owned by STB Software Development B.V., a Dutch sister company. Plutus B.V. owns both companies, and op de Weegh and van der Meijden sit on the boards of all three entities.
StablR’s incident announcements refer only to unauthorised access to its “platform infrastructure”. They do not identify which legal entity operated the compromised systems, who controlled the relevant privileged credentials, whether the affected minting authority belonged to StablR Ltd or the Dutch technology company, or whether an external service provider was involved.
This is not a corporate-formality issue.
DORA (Digital Operational Resilience Act) applies to electronic-money institutions and establishes requirements for ICT governance, incident management, operational resilience and the management of ICT third-party risk. A regulated entity cannot outsource regulatory responsibility merely because technology is owned or operated by another company within the same group.
The MFSA should therefore explain how it assessed StablR’s intragroup technology dependency before licensing the issuer, and what its post-incident investigation found about the division of operational responsibility.
StablR has not disclosed the essential facts
StablR has confirmed that the incident was contained, external cybersecurity specialists were engaged, its recovery plan was activated and the MFSA was notified. It has also stated that the safeguarded assets held before the incident remained intact.
What remains undisclosed is more important.
As of 22 July 2026, StablR had not publicly identified the verified root cause, the compromised key or access mechanism, the number of unauthorised tokens, the resulting reserve deficit, the amount realised by the attacker, whether affected tokens had been frozen or burned, who would finance the deficit or when redemption would resume. Its 8 July update stated only that the investigation continued and that operational details could not yet be shared.
StablR has also not publicly explained whether it recognises the unauthorised tokens as valid claims against the issuer.
That question is fundamental.
If the tokens are recognised, StablR or its shareholders must restore the missing backing. If they are not recognised, fungible tokens created through StablR’s official token contracts could carry different redemption rights depending on their transaction history.
That would undermine the legal certainty expected from regulated electronic money.
An ongoing forensic investigation may justify withholding information that could create further security risks. It does not explain why token holders have not been told the amount of the deficit, the legal status of their tokens or the conditions that must be met before redemption resumes.
Preliminary evidence points to a single-key failure
Reporting by The Block, citing blockchain-security firm Blockaid, indicates that the incident may have resulted from the compromise of one signer in a minting multisig configured with a 1-of-3 threshold. According to that preliminary reconstruction, the attacker obtained administrative control and minted approximately 8.35 million USDR and 4.5 million EURR without corresponding reserves. Tokens with a reported face value of approximately USD 10.4 million were exchanged, initially producing estimated net proceeds of around USD 2.8 million after severe slippage
StablR and the MFSA have not publicly confirmed this technical reconstruction or these amounts.
But if the reported configuration is correct, its implications are serious.
A wallet with three possible signers but a threshold of one does not provide meaningful multi-party approval. Any single authorised key can act alone. The additional keys provide alternative access, but do not protect issuance from the compromise of one signer.
That would be difficult to reconcile with the governance and security architecture described in StablR’s regulatory whitepaper
The whitepaper promised controls that apparently failed
StablR’s whitepaper states that its governance protocol requires a “threshold of approvers” for minting and burning in order to prevent unauthorised or fraudulent activity. It also says that multi-party-computation technology protects the private keys controlling issuance and ensures that StablR maintains full control over minting and burning.
StablR’s public website continues to describe its minting process as using institutional-grade infrastructure and decentralised MPC technology providing the highest level of security and governance.
Those representations now require precise answers.
Was the compromised minting authority protected by the approval structure described in the whitepaper? Did the production wallet require approval by more than one genuinely independent person? Was a separate owner or administrative key outside the advertised MPC controls? Did the compromise occur within StablR Ltd, STB Software Development or a third-party service provider? Did the MFSA examine the actual production configuration, or only the intended architecture presented during licensing?
A control does not exist merely because it appears in a whitepaper.
The Whitepaper May Create Personal Liability
MiCA does not treat the StablR whitepaper as harmless marketing material. Under Article 52, where an issuer infringes Article 51 by providing information that is not complete, fair or clear, or that is misleading, the issuer and the members of its administrative, management or supervisory body are liable to token holders for losses caused by that infringement. Any contractual exclusion or limitation of that liability is legally ineffective.
StablR’s current EURR whitepaper contains a declaration dated 2 December 2025 in the names of Cornelis Teunis Adrianus van der Meijden and Gijs op de Weegh. It confirms that, to the best of the management body’s knowledge, the information is fair, clear and not misleading and that no material information has been omitted.
The declaration is particularly relevant because it was made in their names. Potential liability under Article 52 is not, however, necessarily limited to the persons whose names appear below the declaration; the provision extends to the members of the relevant administrative, management or supervisory body.
The same whitepaper states that StablR continuously monitors whether reserves exceed the EURR supply and that controls have been implemented to ensure that EURR cannot be issued without corresponding fiat. It also describes approval and key-management arrangements intended to prevent unauthorised minting.
The cyber incident does not by itself prove that those statements were false when made. But if the production environment already allowed one compromised key to create unbacked tokens, or if the advertised MPC and approval controls did not apply to the actual minting authority, the discrepancy could engage Article 52 MiCA. The issue would no longer be merely whether StablR suffered an attack. It would be whether token holders were given an accurate account of the controls on which the stability and backing of the product depended.
An incident that caused underbacking and the suspension of redemption appears prima facie capable of affecting the assessment of the token. StablR should therefore state whether it considered Article 51(12) to be triggered, whether a modified whitepaper was notified and published and, if not, on what legal and factual basis no modification was considered necessary. From what we see, the white paper was not yet modified, accordingly.
Token holders seeking damages would still need to show the misleading or incomplete information, reliance affecting their decision to purchase, sell or exchange the token, and a resulting loss. But MiCA expressly places potential liability not only on StablR Ltd. It also places it on the members of the responsible management body.
Full backing was promised—then redemption stopped
The StablR whitepaper contains a deeper legal inconsistency. It states that all EURR holders have a right to redemption at any time and at par value. Elsewhere, however, it suggests that holders without an existing contractual relationship may use direct redemption only in “extraordinary circumstances”, with the board deciding whether those circumstances exist. The recovery section even contemplates lowering the peg after consultation with the MFSA.
These provisions are difficult to reconcile with Article 49 MiCA, which grants holders a claim against the issuer and requires redemption at any time and at par value. AML and customer-due-diligence procedures may govern how a redemption is processed. They cannot convert a directly applicable statutory right into a discretionary benefit or, without a separate legal basis, permit the issuer to reduce the redemption value below par.
StablR’s whitepaper grants EURR holders a claim against the issuer and the right to redeem their tokens at any time and at par value. Under normal circumstances, redemption payments should be processed within 24 hours.
Article 49 MiCA likewise requires e-money tokens to be issued at par upon receipt of funds and redeemed at any time and at par value upon request.
Following the incident, StablR acknowledged that the circulating supply was no longer fully backed and suspended redemption. During that period, holders could not exercise the defining contractual and regulatory right attached to an e-money token: redemption at par.
A short suspension may be justified as part of an emergency recovery process. However, it cannot remain indefinite, unexplained or unquantified.
Token holders must be informed of the deficit, how it will be covered, when redemption will resume and whether all valid tokens will ultimately be honoured at par.
Who bears the deficit?
The existence of intact pre-incident safeguarded assets does not resolve the problem. If additional tokens were created without additional reserves, the existing assets may remain secure while the issuer’s total token liabilities exceed those assets. StablR itself confirmed both propositions: the pre-incident safeguarded assets were intact, but the circulating supply was no longer fully backed.
The central question is therefore unavoidable:
Who is financing the backing deficit?
Will it be funded by StablR, Plutus B.V., existing investors, an insurer, a technology provider or recovered assets? Or are token holders effectively bearing the consequences through suspended redemption and distressed secondary-market sales?
Neither StablR nor the MFSA has provided a public answer.
“Proof of reserves” without current proof
StablR’s proof-of-reserves page states that EURR and USDR are fully backed and that daily reserve updates provide near-real-time visibility.
The same page currently displays dashes instead of figures for total supply, total reserves and the update date. The available independent reserve reviews cover the four quarters of 2025, not the period following the May 2026 incident.
The inconsistency is stark.
StablR publicly acknowledged that its circulating supply was underbacked. Its proof-of-reserves page continues to claim full backing while presenting no current supply figure, no current reserve figure, no verification date and no post-incident independent attestation.
A proof-of-reserves page without current reserves, current liabilities and a date of verification is not proof.
It is an assertion.
Where is the MFSA?
StablR stated that it notified the MFSA under DORA and MiCA, activated its recovery plan and remained in active dialogue with the regulator.
As of 22 July 2026, EFRI has identified no public MFSA account explaining the verified cause of the incident, the amount of unauthorised issuance, the size and funding of the backing deficit, the legal treatment of affected tokens, the conditions for resuming redemption or the remedial measures imposed.
The absence of a public statement does not prove that the MFSA has taken no confidential supervisory action.
It does establish a serious accountability gap.
A regulated issuer admitted that its tokens were underbacked and suspended the defining legal right attached to them. Token holders, exchanges and regulators across Europe remain dependent on limited announcements from the institution whose controls are under investigation.
The MFSA publicly states that it supervises crypto-asset entities through a risk-based and data-driven approach and identifies ICT risk, cyber resilience and third-party dependencies as significant supervisory concerns.
The StablR incident is the point at which those supervisory claims must produce a visible result.
The Payvision history remains relevant
The StablR cyber incident does not prove that its executives’ former Payvision roles caused the control failure. It does not establish that the MFSA’s original licensing decision was unlawful.
It does validate the reason EFRI raised the issue.
Fit-and-proper supervision should determine whether the people managing a regulated financial institution have the experience, judgement and control culture required to manage its risks. It is not a formal exercise completed by collecting application documents.
EFRI asked the MFSA in July 2025 how it had evaluated StablR’s management history, ownership and group governance. No substantive public answer followed. When the production controls later failed, the MFSA again provided no public account of what it had previously assessed or what it subsequently required.
The issue is no longer whether EFRI’s questions were uncomfortable.
It is why they remain unanswered.
EFRI's position
StablR and its management may themselves have fallen victim to a sophisticated cyberattack. At the very least, they now know what it feels like to be on the receiving end of a professionally organised scam.
The problem is what the incident exposed.
A regulated stablecoin issuer lost control of its token supply. Tokens without corresponding backing entered circulation according to preliminary on-chain analyses. Redemption was suspended. The advertised security and governance architecture appears difficult to reconcile with the reported technical configuration. Current reserve evidence is absent. The competent authority has issued no public account of its findings.
This is a practical test of whether MiCA and DORA protect consumers after a regulated stablecoin fails, not merely whether the rules look convincing before the failure.
EFRI calls on the MFSA to publish a non-confidential supervisory account addressing the verified root cause, the amount of unauthorised issuance, the reserve deficit, the legal treatment of affected tokens, the status of redemption and the remedial measures imposed.
The EBA/ESMA should examine whether MiCA’s backing, recovery and token-holder protection rules have been applied correctly. European authorities should also assess whether the MFSA’s licensing and ongoing supervision adequately addressed management history, intragroup technology dependence and privileged-access controls.
A stablecoin is not stable because its website says so.
It is stable only when every valid token is backed, every holder can redeem at par and the issuer remains in control of the power to create money.
StablR’s controls failed that test. The MFSA must now explain how this was able to occur under its supervision, what deficiencies it identified and what measures it imposed.
