Safeguarding in Practice: E-Money Account Architecture for EMI Licensing

---

EMD2 Article 10 requires e-money institutions to safeguard funds received in exchange for electronic money. The funds must be placed in a segregated account at a credit institution, or invested in secure, low-risk assets, by the end of the next business day. At any point in time, the institution must be able to demonstrate that client funds are fully covered.

Safeguarding is an account architecture, not a reporting requirement bolted onto existing infrastructure. The ledger must structurally prevent commingling, mixing client funds with the institution's own funds, through separate account types, enforced isolation, and real-time visibility into the safeguarding balance.

Regulators do not accept "we reconcile monthly and it always works out." They require the architecture to prevent commingling by construction. The difference matters during examination.

The Account Architecture

A safeguarding-compliant ledger distinguishes four account categories:

The fundamental equation:

Sum(client e-money balances) ≤ Sum(safeguarding account balances) + Sum(float balances)

At all times. Not at month-end. Not after reconciliation. At the moment the regulator asks.

When a customer deposits EUR 100:

DEBIT  safeguarding:eur     100.00    (asset increases, bank received the money)
CREDIT customer:alice:eur    100.00    (liability increases, we owe Alice EUR 100)

Both sides of the entry maintain the equation. The safeguarding balance increases by the same amount as the client liability. If one side is recorded without the other, a bug, a crash mid-transaction, a failed webhook, double-entry rejects the incomplete posting. The equation is maintained by the ledger's own invariant, not by application discipline.

Preventing Commingling

Commingling is the cardinal sin of e-money regulation. It means: the institution used client funds for its own purposes. Even temporarily. Even by accident.

Three architectural mechanisms prevent it:

1. Account type flags in the ledger.

Every account carries a type: customer_emoney, safeguarding, fee_revenue, operating, float. The type is set at account creation and is immutable. It is not a label, it is a constraint that affects which transfers are permitted.

2. Transfer rules enforced by the domain layer.

A transfer from a safeguarding account to an operating account is blocked by default. The only permitted path for funds to move from safeguarding to operating is through an explicit fee extraction workflow: the customer is charged a fee (reducing their e-money balance), and the fee amount is transferred from safeguarding to operating. This workflow is journaled, audited, and requires explicit authorization in the orchestration layer.

The sequence for a EUR 2.00 monthly fee:

Step 1: DEBIT  customer:alice:eur    2.00    (liability decreases, Alice owes less)
        CREDIT platform:fees:eur     2.00    (revenue increases, fee earned)

Step 2: DEBIT  safeguarding:eur      2.00    (asset decreases, funds released)
        CREDIT operating:eur         2.00    (equity increases, institution's own funds)

Both steps are part of a single durable workflow. If step 1 succeeds and step 2 fails, the workflow engine retries step 2 from the journal. The safeguarding balance never gets out of sync with the client balance, because the two movements are coupled in a single workflow, not scattered across independent processes.

3. Real-time safeguarding balance check.

The system can generate a safeguarding report at any moment:

Client e-money total:      EUR 1,247,891.23
Safeguarding balance:      EUR 1,198,442.00
Float (pending settlement): EUR   52,100.00
Coverage:                  EUR 1,250,542.00
Surplus:                   EUR     2,650.77   (>0 = compliant)

If the surplus is negative, the institution is under-safeguarded. The system raises an alert. The operations team has minutes, not days, to investigate and correct.

Float and Settlement Timing

Between payment initiation and settlement, funds are in transit. A customer receives a SEPA Direct Debit: the creditor's bank has submitted the collection, but the debtor's bank has not yet settled. The funds are credited to the customer's e-money account (liability increases), but the corresponding asset increase depends on the settlement cycle.

During this window, the safeguarding equation includes float:

Client balance:       EUR 100.00    (customer sees EUR 100)
Safeguarding:         EUR   0.00    (bank hasn't received the funds yet)
Float (SDD pending):  EUR 100.00    (settlement expected in D+5)
Coverage:             EUR 100.00    (float counts toward coverage)

The holding period model tracks this precisely. Funds in SETTLED_PENDING state are counted as float, covered for safeguarding purposes but not yet available to the customer. After the holding period expires and the funds transition to SETTLED_AVAILABLE, they move from float to safeguarding (the bank confirms receipt).

If a return occurs during the holding period (R-transaction), the float is reduced and the customer's e-money balance is reversed. The safeguarding equation rebalances automatically because both sides move together.

Reporting Requirements

EMI licensing imposes specific reporting obligations. The architecture must produce these reports from the ledger, not from a separate reporting database, not from an ETL pipeline, and not from a spreadsheet.

The data for every report comes from the same source: the immutable double-entry ledger. Client e-money outstanding is the sum of all customer_emoney account balances (credit-normal). Safeguarding coverage is the sum of all safeguarding account balances (debit-normal) plus float balances. The report is a query, not a construction.

This is the advantage of building on double-entry from day one. The balance sheet is a property of the ledger, not a derived artifact. The safeguarding equation is a subset of the accounting equation (Assets = Liabilities + Equity). It is verified every time any transfer is posted, because every transfer must balance.

Common Safeguarding Failures

Three patterns that create safeguarding risk:

1. Shared bank accounts. The institution uses one bank account for both client funds and operating funds, relying on internal accounting to track the split. If the bank freezes the account (for any reason, AML investigation, dispute, insolvency of the bank), all funds are frozen, including client funds. EMD2 requires physical segregation: a dedicated bank account for safeguarding, separate from the operating account.

2. Missing float tracking. Client balances include pending settlements (the customer sees the credit), but the safeguarding balance doesn't include the corresponding float. The safeguarding report shows a deficit that doesn't actually exist, or worse, a surplus that masks a real deficit because the float is double-counted.

3. Fee extraction without workflow coupling. Fees are deducted from customer balances (reducing liability) but the corresponding movement from safeguarding to operating happens in a separate, asynchronous process. If the async process fails or is delayed, the safeguarding account temporarily holds more than it should, which is technically compliant but operationally confusing, or holds less than it should if the timing is reversed.

Each of these is avoidable through architecture. Separate bank accounts. Explicit float account types. Durable workflows that couple the two sides of a fee extraction. The patterns are not complex. They must be deliberate.

---

Read more: The Ledger | Security & Compliance

---

Sources:

• EMD2, Directive 2009/110/EC, Art. 7 (Safeguarding requirements), Art. 10 (Protection of funds)
• PSD3/EMD3, COM/2023/366 (proposal merging PSD2 and EMD2)
• Ley 21/2011 (Spain), Art. 8-10 (safeguarding for Spanish EMIs)
• BaFin: Guidance on safeguarding requirements for e-money institutions
• HGB §246, Prohibition of offsetting (Verrechnungsverbot), client assets must not be netted against institution liabilities