Wallet-Linked IBAN Accounts for EMIs

Each customer has one IBAN, so an incoming credit already identifies the customer. Matching decides the address and chain, checks the customer's status and limits, and holds a payment that cannot be matched or fails screening for review or return to the payer. On a licensed issuer's rail the issuer mints on receipt, and the integration consumes its signed webhooks (HMAC-SHA256) to update your ledger and the customer's screen.

On your own token, the mint request goes out once the credit has settled in your safeguarding account, since MiCA requires issuance at par on receipt of funds (Article 49). Each request is keyed to its credit, so a duplicate webhook or a retry after a timeout cannot mint the same euros twice.

A payout starts with an order the customer's wallet signs. In Monerium's format the order names the currency, the amount, the destination IBAN and a timestamp no more than five minutes old. Verification of Payee, the check that the payee's name matches the IBAN, belongs before that signature, because the regulation places the name check before the payer authorizes the payment. On your own token we run it there, and on a licensed issuer's rail the product shows the result the issuer's API returns.

On your own token the SEPA payment leaves only after the burn is final, and a payment rejected after the burn follows a rule fixed in design, such as re-minting to the same address. Remittance text fits the scheme's 140-character field or an ISO 11649 creditor reference, so the payee can match it to an invoice.

The daily reconciliation we build compares three records: the e-money outstanding in the institution's ledger, the safeguarded funds behind it, and token supply read from the contract on every chain. Pending mints, held credits, payouts in flight and moves between chains each get their own line. On Monerium's rail a move between chains is a redeem on one chain and a dependent issue on the other, and the redeem does not finalize unless the issue succeeds.

Each break type has an owner in operations or finance, and since an issuing EMI must keep at least 30% of the funds received in separate credit-institution accounts (MiCA Article 54), the safeguarding side covers each account. The chain side comes from indexing mint and burn events, the job of our blockchain data indexing service, and a proof of reserve can publish the supply check onchain.

Receiving a mint and redeeming cost the customer no gas on EURe, because the issuer's system accounts submit both transactions. Only they can call the token's burn function, which first checks the address-ownership signature, as EURe's contract source shows. Sending tokens to someone else does cost gas, so we add a paymaster on ERC-4337 accounts, a relayer, or ERC-2612 permits, which EURe supports, letting the customer sign while a relayer submits.

The wallet type also decides custody. A self-custody key or a Safe leaves the customer as the only signer. An embedded or MPC wallet in which the operator holds a key share or a recovery power needs counsel's view on custody, given the payment-services rule in the rules section below.

SEPA Instant and the chains run at night and at weekends, so the system does too. We monitor webhook delivery, mint and burn times, payment status, reconciliation breaks, role changes on the token contract and upgrades on every chain. Incidents follow runbooks the institution approves, from an issuer API outage or a halted chain to a customer who needs a new binding after losing a wallet. We run it as part of our managed onchain operations, or train your team on the same runbooks.