This post is probably the nerdiest thing I’ve written. For some reason I found myself wondering how crypto on/off-ramps actually work under the hood, not the marketing version, but the plumbing. So I decided to trace a single euro, end to end, from my Italian bank account to what I consider the closest thing to a real online euro: Monerium’s EURe.
Monerium is an Iceland based e-money institution that issues EURe under MiCA and which I already presented in a previous post. I picked Monerium because EURe is a programmable claim on safeguarded fiat sitting in the banking system and it represents, in my opinion, the first clean form of EURO on-chain, but the post is totally valid also for other forms of digital Euro, like EURC (issued by Circle).
Along the way I found myself having to understand each piece of infrastructure the money touches. I’ve included a short description of each rail: not just to pad the post, but because every one of them is a system that blockchain projects claim to want to replace. It’s worth actually knowing what you’re replacing.
The journey
Step1: Sepa Credit Transfer from Italian bank instructed
Everything begins with a standard SEPA Credit Transfer instruction (from now on SCT). I deliberately decided to use a SCT and not a SEPA Instant transfer for two main reasons. First, SEPA Credit Transfer currently processes more value than SEPA Instant (Instant is ~19% of SCT value). Second, SCT is an older rulebook and its transactions go through an older architecture of payments that, in my opinion, serves better my educational purpose.
A SEPA Credit Transfer, basically the workhorse of European retail payments, is a push payment, denominated in euros, settled across the SEPA zone with a standard T+1 cycle. The credit transfer I issue follows the SCT rulebook, based on the ISO20022 standard that the European payment ecosystem adopted in 2008. The SCT rulebook is only a rulebook, not a system, and it is concretely implemented and enforced by the Clearing infrastructure to which the payment is sent after my instruction.
The Originator transaction could host a number of fields, as described in the DS-01 table of the rulebook, but only a subset of them are actually mandatory for the Clearing infrastructure processing, as per table DS-02.
Essentially the SCT rulebook mandates only five fields in any transaction: originator name, beneficiary name, originator IBAN, beneficiary IBAN, and amount. Everything else is optional. This lack of mandatory extra information, like the P005 Originator address – only mandatory when either PSP is outside the EEA – or the T009 Remittance Information, creates a structural gap in approving the transaction on the Beneficiary side (Travel Rule), down the road.
NB. Remittance Information is not referring in any form to cross border remittances, it’s simply an old financial jargon to describe a textual description attached to the transfer
Step2 – Transfer clears on EBA STEP2
After that I confirm the transaction on my banking app, this is batched together with other transactions and sent to a Clearing house (STEP2) where it will be cleared.
STEP2 is the most important retail Automated Clearinghouse (ACH) in Europe. It is maintained by EBA Clearing, a consortium of 48 European banks. It is the only pan-european ACH with 4800 PSPs connected either directly or indirectly. It processed around EUR 84b/day in the first two months of 2026.
The Clearing process that happens in STEP2 is a key step in the processing of financial transactions and it is defined as the “process of transmitting, reconciling and, in some cases, confirming transfer orders prior to settlement, potentially including the netting of orders and the establishment of final positions”.
What concretely happens is that the Clearing System collects all the batches of transactions coming from all the banks connected to the system, and establishes the net positions of each bank: the net amount that a bank owes or is owed to the system.
As mentioned before and as explicitly stated in the SCT Rulebook, Clearing systems are the actual implementations of the SCT rulebook. They can implement the rulebook as they wish, provided that their implementation is compliant with the rules stated in EPC schemes.
Step3: Transfer settles with Central bank money at T2
After my payment has been cleared in STEP2, it will settle in T2, the Eurosystem’s Real Time Gross Settlement system (RTGS from now on). The settlement is the actual transfer of value that discharges the net obligations of the Originator’s bank, and it is executed by moving central bank money from the Originator bank’s account at the RTGS to the Beneficiary’s bank account at the RTGS.
T2, formerly Target 2, was created in 1999 and it is the backbone of the European Financial System and in 2024, it settled more than 400,000 billions of total value.
STEP2 is integrated to T2 via Ancillary System Interface (ASI). This is a standardised interface that allows ancillary systems (like retail payment systems, ACH) to settle their cash legs in central bank money. The actual settlement is done through what is called a settlement procedure, so a set of activities that will make money move from one T2 account to another one. STEP2 uses the procedure B – multilateral with guarantees. This procedure includes a guarantee logic: it means that if a participant (bank) lacks liquidity at settlement time, the guarantee fund covers the shortfall rather than the payment failing.
As per STEP2, participants can have different types of access to T2: direct or indirect. In July 2024, the eurosystem approved access by non-bank PSP to Target services. EMIs can now connect directly.
The Settlement step is the most important step in the entire payment flow. Settlement is the moment in which finality is achieved, so the point at which the payment becomes irreversible. Before Settlement a transaction is always reversible and recallable, after settlement it becomes final and irrevocable.
The definition of finality is fully clarified in the Settlement finality directive 98/26/EC. In this directive, transfer orders are considered irrevocable and legally protected from insolvency proceedings from the moment they are entered into a system following SFD rule. T2 is a designated system under SFD.
This step really differentiates a fiat transfer from a blockchain transfer: blockchain finality is substantially different and lacks recognition under SFD-type frameworks. A blockchain transaction is final after X blocks confirmation, this is a probabilistic definition of finality but it has no legal basis, so a blockchain transaction cannot be considered final in legal terms. MiCA does not resolve the underlying legal finality question and on ramp/off ramp solutions like Monerium are essentially the bridge where two different finality regimes collide.
Step4: Monerium detects SEPA and starts compliance checks
Once my transaction has settled, Monerium can then process it and associate it to my account through the Beneficiary IBAN field of the SCT rulebook. The Beneficiary IBAN associated with my account is most likely a virtual IBAN issued under their EMI licence, a unique IBAN created in my name, permanently linked to my blockchain wallet address.
This design sidesteps the reconciliation problem that still plagues most on-ramps entirely. Rather than asking users to include a payment reference in the T009 Remittance Information field, the IBAN itself is the routing key. When my SCT arrives at that IBAN, the matching to my account and wallet is automatic. No reference needed, no risk of truncation, no manual investigation. Monerium has elegantly absorbed the reconciliation complexity at onboarding rather than at transaction time.
After Monerium has associated money to me, before making my funds physically available in the form of EURe, Monerium has to make two key checks: the KYC check and the Travel rule.
KYC Status
When I registered with Monerium, I went through an identity verification process. This is the standard KYC onboarding: document verification, liveness check, sanctions screening, PEP check. After this process, my account became active, an IBAN was generated and linked to me.
When a specific payment arrives, Monerium needs to verify that the inbound funds come from me, the person who was onboarded for that specific account.
If it doesn’t match and maybe a third party sent money to me on my behalf, Monerium has a compliance problem, not just a reconciliation problem.
In order to check this match, Monerium can use the fields that were submitted when I instructed the transfer: the field P001 Originator name travels with every SCT, but name matching alone might not be enough to fully clear the KYC check, so Monerium has to perform additional checks. This is one of the reasons why the transactions could be delayed.
Travel rule
The second key check to be performed is the so-called Travel Rule. The Travel Rule was instituted in 1996: financial institutions became obliged to pass originator and beneficiary info to the financial institution to which they are sending money. This rule was extended in 2019 by FATF to include virtual assets and VASP (Recommendation 16).
Based on the rule, the following info must travel with the transactions:
- Originator: name, account number and one of originator’s physical address, national identity number, customer id number or date of birth;
- Beneficiary: name, account number
This is more than what an SCT carries – SCT mandates only five fields in any transaction: originator name, beneficiary name, originator IBAN, beneficiary IBAN, and amount. In particular P005 Originator address is only mandatory when either PSP is outside the EEA, but it is mandatory for the travel rule. This creates a structural gap in the on ramp/off ramp transactions that nobody has really solved at architectural level.
The travel rule is already complex for traditional payments but becomes significantly harder to enforce for blockchain transactions, where wallet addresses carry no identity information and transfers can move across multiple hops without any compliance data attached. This tension between the travel rule’s data requirements and the architecture of public blockchains deserves a dedicated treatment and I’ll explore it in a future post.
Step5a: EURe tokens minted and delivered to the user’s wallet
After Monerium has checked the KYC Status and the Travel rule of my incoming transaction, it can mint my EURe and I can start using them.
Step5b: The real EURO sits in Monerium safeguarded account
Once I have my EURe in my wallet, the real euro doesn’t disappear, it moves simultaneously into a safeguarded account. Monerium is required under EMD2 to safeguard 100% of customer funds and hold them segregated from operational accounts in a credit institution or invested in low-risk, liquid assets.
In particular, MiCA’s Electronic Money Token provisions (Title III) tighten this further: as EURe is classified as an EMT, Monerium is subject to reserve, redemption, and disclosure requirements. In the end, the EURO backing the EURe is not Monerium’s, it is mine, ringfenced by regulation and always redeemable at par on demand.
Conclusions
The infrastructure I’ve just walked through was built over decades, layer by layer, to solve real problems: interoperability across borders, systemic risk in settlement, legal certainty in finality, compliance accountability across institutions. It works reliably, at enormous scale, every banking day. But it was designed for a previous generation of technology, and its limitations are structural rather than incidental. SEPA Instant has already addressed the speed problem within the existing architecture, so raw velocity is no longer the compelling argument for stablecoins that it once was.
What blockchain genuinely offers is something different. Programmability is a real and meaningful capability: these rails cannot host smart rules, let alone entire programmable financial agreements that execute autonomously. Adaptability to non-human agents is another real USP: the SCT model assumes a human originator, a human beneficiary, a static identity verified once at onboarding. In a world where AI agents and autonomous systems are becoming counterparties in financial flows, the identity and authorisation model of traditional payment rails becomes a genuine architectural constraint rather than just an inconvenience.
But the problems that stablecoins need to solve to replace this infrastructure are still serious. First, the double finality regime, where fiat achieves legal irrevocability under the Settlement Finality Directive and blockchain achieves only probabilistic confirmation with no legal equivalent, is a fundamental problem that must be addressed.
Second, blockchains are immutable but in the wrong way: they are operationally irreversible, making recalls or reversals impossible, yet they lack the legal finality that protects transactions in systems like T2, and, in theory, they also remain vulnerable to any actor with sufficient computing power or stake to rewrite the chain.
Finally, compliance is a structural weak spot: enforcing the travel rule within the VASP ecosystem is convoluted but achievable; enforcing it beyond that perimeter, while preserving the anonymity properties that give the technology much of its value, is probably not possible without a fundamental redesign.
The narrative behind most stablecoin projects is building new rails. That ambition is worth taking seriously. But doing it is genuinely more complex than the marketing suggests, not because the technology is immature, but because what you are proposing to replace is infrastructure that central banks, commercial banks, regulators, and hundreds of millions of people depend on implicitly, every day, without thinking about it. The long road to €1 on-chain is long for a reason.
The next blog post of this series will be “The long road to $1 on-chain”.
Resources
- SEPA Credit Transfer rulebook – link
- EPC SEPA CT Overview – link
- ISO 20022 standard – link
- STEP2 overview – link
- Eurosystem T2 overview – link
- Eurosystem Target Services Annual Report 2024 – link
- Settlement Finality Directive – link
- FinCEN Funds Travel rule – link
- FATF Travel rule – link
- e-money Directive 2 EMD2 – link
- MiCA Regulation – link
