E-money, wallets and newer instruments

E-money is electronically stored monetary value that represents a claim on the issuer and is accepted as a means of payment by parties other than the issuer. It is typically prepaid, so the customer loads value into a wallet or a card, and then spends it with merchants or transfers it to other users. Mobile wallets, prepaid cards, and some stored value accounts are all forms of e-money. Unlike a bank deposit, e-money is not a deposit in the legal sense in many jurisdictions, and the issuer must safeguard customer funds separately, usually in a segregated account with a bank. The regulatory treatment is therefore different, even though the customer experience can feel very similar to a bank account. Wallets can be closed loop, where value can only be spent within one merchant or one ecosystem, or open loop, where value can be spent anywhere the scheme is accepted. Open loop wallets often sit on top of a card or a bank account, and the wallet is then a convenient front end rather than a separate store of value. In some markets, wallets have become the primary payment instrument, leapfrogging cards and cheques, especially where mobile phone adoption is high and bank branch access is limited. For an analyst, the key is to identify where the value is actually held, who is liable if the wallet provider fails, and how a payment from a wallet settles with the merchant. Newer instruments also include instant payments, request to pay, and account to account payments initiated through open banking. These instruments reuse the credit transfer concept but add real time settlement, richer data, or a new initiation channel. Request to pay, for example, lets a biller send a request that the payer can approve, pay in full, pay in part, or decline, which blends push and pull features. When you encounter a new instrument, resist the temptation to treat it as entirely new. Ask which underlying model it follows, where settlement occurs, and what happens on failure, and you will quickly understand how it fits into the existing payment landscape. Worked example with real numbers: a customer loads EUR 300 onto a wallet from a bank account, and the wallet balance becomes EUR 300 of e-money, a claim on the electronic money institution, safeguarded in a separate account under Directive 2009/110/EC. The customer pays a merchant EUR 45 from the wallet, the wallet balance falls to EUR 255, and the merchant e-money balance rises to EUR 45. The merchant redeems EUR 45, the institution pays EUR 45 from the safeguarding account to the merchant bank account, and the merchant receives bank money. At no point did the customer hold a bank deposit, and the merchant received e-money first and bank money only on redemption, which is why the wallet terms must state the redemption right and the timing in plain language. Failure and recovery: a wallet payment fails when the balance is insufficient, and the recovery is to load the wallet, not to overdraw it, because e-money cannot be overdrawn. An e-money issuer failure is different: the safeguarded funds should be available to holders, but the process takes weeks, and the holder must be told that e-money is not covered by deposit guarantee, because it is not a deposit. A merchant who accepts e-money without understanding that settlement depends on the issuer discovers the difference only when the issuer is in difficulty, which is why the product must disclose the issuer, the safeguarding and the redemption right before the first payment. For a business analyst, product owner or subject matter expert, the checklist for any e-money or wallet product is to name the issuer and its authorisation, the safeguarding method and the safeguarding bank, the redemption right and timing, and to state plainly that e-money is not a deposit and is not covered by deposit guarantee. The wallet ledger must reconcile to the safeguarding account every day, and any shortfall is a safeguarding breach, escalated immediately. The payment messages at the wallet boundary are often proprietary, but the load and the redemption still map to a pain.001 and a camt.053 at the bank account, so the requirement must map the wallet ledger to the bank ledger for every load, payment and redemption.