Euro Accounts That Settle Into a Wallet the Customer Controls
Bind a bank account number to an address the customer holds the keys to, so an ordinary SEPA transfer arrives on chain and nobody in the middle ever holds the money.
- Maturity
- Emerging
- Regime
- MiCA Title IV
- Proven stack
- Monerium · Safe · MetaMask · Gnosis Pay
- Last verified
- August 2026
Reviewed by Rado Patus, Offer Owner at Protofire
volume through the rail in the twelve months to 2026, and more than EUR 2bn of its token processed on chain - both provider figures.
Neither figure is independently verified. Every organisation named below is a crypto-native company: no bank, authorised payment institution or licensed asset manager was located running this pattern. The mechanism is proven in production, though no regulated institution's risk function has yet been shown to accept it.
01. The opportunity
A business that wants to hold value on chain still has to be paid by people who do not. Its customers pay by bank transfer, its suppliers invoice for bank transfer, and its payroll leaves by bank transfer. The usual answer is a custodial intermediary: money lands with an exchange or a payment provider, and a separate step moves it on chain, which is where the cost, the delay and the counterparty exposure sit. This pattern binds a bank account number to a chain address the customer controls, so an ordinary SEPA transfer is minted to that address as an e-money token on arrival and a signed instruction burns it and sends euro out again, with nobody holding the money in between.
The change is in what may lawfully be used. MiCA became applicable to e-money tokens on 30 June 2024, and the transitional period for crypto-asset service providers closed on 1 July 2026. Tokens not issued by an authorised electronic money institution are no longer a usable basis for euro payment products in the Union, which has moved this pattern from a crypto-native convenience to the only compliant shape for a euro balance a customer holds themselves. The rail provider states that more than EUR 8 billion moved through it in the twelve months to 2026 and that more than EUR 2 billion of its token has been processed on chain; both are provider figures and neither is independently verified here.
02. The regulatory position
03. Who's already done this
The rail itself and the regulated party in every row below: euro accounts with an IBAN bound to a customer-controlled address, minting on receipt and redeeming on a signed instruction, across six chains, with the IBAN available to residents of more than 190 countries.
Multi-signature treasury accounts for companies and organisations, sending and receiving SEPA payments directly from the account. The clearest evidence that this is a complete product without a card - no card appears anywhere in the treasury use.
A euro IBAN offered inside a self-custody wallet. The largest distribution of the pattern located, and the clearest signal that the model is being offered to ordinary users rather than only to businesses.
A card programme whose issuer settles with the card network by redeeming tokens through the IBAN rather than through an exchange. The settlement use rather than the consumer use: it removes an intermediary exchange from a card issuer's own treasury operation.
Self-custody euro accounts, and treasury and payment operations for companies holding their own keys. Three independent products on the same rail, which is what distinguishes a pattern from a single vendor's customer.
04. Does this fit you?
It fits if your customers already hold their own keys or will, if euro arrives or leaves your business by ordinary bank transfer, and if you would rather not hold client balances at all.
It does not fit if holding the balance is the product - distributing a third-party token custodially gives you the same euro capability with a different risk model. It does not fit a card programme, which is the spend leg rather than this one. And it cannot pay anything on the balance: MiCA Article 50 prohibits interest or any benefit linked to how long the balance is held, permanently, so the product earns its place on payment utility and cannot compete on yield.
05. The stack, layer by layer
Most of these layers can be rented from a named vendor, and usually should be. The part that matters is the one layer you have to own yourself.
The customer relationship and the product the balance lives in
The customer relationship and the onboarding that goes with it, a product the euro balance belongs in, and a reason customers already hold their own keys. Notably absent from this column: the client balances, which the institution never holds - that absence is the point of the pattern.
The issuing rail: authorisation, IBAN and the token
The authorisation, the euro account, the IBAN and SEPA reachability; the token, its safeguarding and the redemption obligation; mint on receipt and burn on signed instruction across the supported chains. Not included: the customer's keys, the recovery story, the reconciliation, or any answer to whether the integrator is itself providing a crypto-asset service.
Address binding, orchestration and reconciliation (built and operated by Protofire)
Address binding and the evidence that ownership was assessed - which is how the pattern discharges the self-hosted-address obligation once rather than per transfer; mint and burn orchestration with idempotency and retries; reconciliation between the bank leg and the chain leg; customer key recovery and the support model behind it; and statements showing both legs, with screening on the chain leg.
06. Why this stack
The usual way to get euro on chain is a custodial intermediary: money lands with an exchange or a payment provider, and a second step moves it. That step is the cost, the delay and the counterparty exposure. Binding the IBAN to the customer's own address removes it - the conversion happens on arrival and the balance is never anyone else's to hold.
The design's difficulty sits in the compliance model around self-hosted addresses. Under the Transfer of Funds Regulation, a transfer above EUR 1,000 to or from a self-hosted address obliges the provider to assess whether that address is owned or controlled by its customer. Binding the address at onboarding answers that question once, with evidence, instead of re-arguing it on every payment. The full blueprint sets out that design, the two component readiness assessments behind the stack, and the one question counsel has to answer before anything is built.
Request the full blueprint
This is the short version. The full blueprint is a single document your counsel and board can read cold, and a third-party-risk function can lift wholesale. Leave your work email and your personal link arrives in your inbox.
- The regulatory position, stated article by article
- Proven options at each layer, with the vendors that hold up
- The risk table with a named owner for each risk
- The division of labour: what is rented, built, and operated
- The third-party-risk pack a DORA governance function can lift
- The delivery path, step by step, with the monitoring and incident model
FAQ
Who holds customer money in an IBAN-to-wallet euro account, and how is it regulated?
In the Euro Accounts That Settle Into a Wallet the Customer Controls pattern, nobody in the middle holds the money: an IBAN is bound to an address the customer holds the keys to, so an ordinary SEPA transfer arrives on chain. MiCA Title IV applies to the issuing electronic money institution, including Art. 48 authorisation, Art. 49 redemption at par and Art. 50, which prohibits interest. The integrator issues nothing and custodies nothing, though whether it is providing a crypto-asset service under MiCA Title V is unsettled and needs an opinion per jurisdiction.
What is the binding regulatory constraint on self-hosted addresses, and how does the architecture answer it?
The binding constraint is Regulation 2023/1113 Arts. 14(5) and 16(2): above EUR 1,000, ownership or control of a self-hosted address must be assessed. The architecture answers this by binding the address at onboarding rather than arguing it per transfer, so the self-hosted-address obligation is discharged once. MiCA Title IV governs the issuing electronic money institution, and SEPA scheme rules are scheme rules rather than law. The evidence that ownership was assessed is part of what the integrator builds.
Who already runs the IBAN-to-wallet pattern, and who is it not for?
Monerium, an electronic money institution authorised in Iceland and passported across the EEA, is the rail: euro accounts with an IBAN bound to a customer-controlled address, minting on receipt and redeeming on a signed instruction across six chains. Safe uses it for multi-signature treasury accounts, and MetaMask offers a euro IBAN inside a self-custody wallet, the largest distribution located. Every named organisation is crypto-native, and no bank or authorised payment institution was located running it. It is not for institutions that want to hold customer balances, nor for products whose customers cannot manage keys.
Already evaluating this for your institution?
When you are ready, we scope a business case on your own numbers: the costed build, the controls, the SLA and the ROI your board needs to approve it. Or talk it through first.
Run this pattern in production, or tried to and stopped? .