Safeguarding in der Praxis: E-Geld-Kontoarchitektur für EMI-Lizenzierung

---

EMD2 Artikel 10 fordert von E-Geld-Instituten, Gelder, die im Austausch gegen elektronisches Geld entgegengenommen wurden, zu sichern. Die Gelder müssen bis zum Ende des nächsten Geschäftstags auf einem segregierten Konto bei einem Kreditinstitut angelegt oder in sichere, risikoarme Anlagen investiert werden. Zu jedem Zeitpunkt muss das Institut nachweisen können, dass Kundengelder vollständig gedeckt sind.

Safeguarding ist eine Kontoarchitektur, keine Reporting-Anforderung, die auf bestehende Infrastruktur aufgesetzt wird. Das Ledger muss strukturell Vermischung verhindern, das Mischen von Kundengeldern mit den eigenen Mitteln des Instituts, durch separate Kontotypen, erzwungene Isolation und Echtzeit-Sichtbarkeit des Safeguarding-Saldos.

Regulierer akzeptieren nicht „wir gleichen monatlich ab und es passt immer." Sie fordern, dass die Architektur Vermischung konstruktionsbedingt verhindert. Der Unterschied ist bei Prüfungen relevant.

Die Kontoarchitektur

Ein Safeguarding-konformes Ledger unterscheidet vier Kontokategorien:

Die fundamentale Gleichung:

Summe(Kunden-E-Geld-Salden) ≤ Summe(Safeguarding-Kontosalden) + Summe(Float-Salden)

Zu jedem Zeitpunkt. Nicht am Monatsende. Nicht nach der Reconciliation. In dem Moment, in dem der Regulator fragt.

Wenn ein Kunde EUR 100 einzahlt:

DEBIT  safeguarding:eur     100,00    (Aktiva steigen, Bank hat das Geld erhalten)
CREDIT customer:alice:eur    100,00    (Verbindlichkeit steigt, wir schulden Alice EUR 100)

Beide Seiten der Buchung erhalten die Gleichung aufrecht. Der Safeguarding-Saldo steigt um denselben Betrag wie die Kundenverbindlichkeit. Wenn eine Seite ohne die andere erfasst wird, ein Bug, ein Crash mitten in der Transaktion, ein fehlgeschlagener Webhook, lehnt Double-Entry die unvollständige Buchung ab. Die Gleichung wird durch die eigene Invariante des Ledgers aufrechterhalten, nicht durch Anwendungsdisziplin.

Vermischung verhindern

Vermischung ist die Kardinalsünde der E-Geld-Regulierung. Sie bedeutet: Das Institut hat Kundengelder für eigene Zwecke verwendet. Auch vorübergehend. Auch versehentlich.

Drei architektonische Mechanismen verhindern sie:

1. Kontotyp-Flags im Ledger.

Jedes Konto trägt einen Typ: customer_emoney, safeguarding, fee_revenue, operating, float. Der Typ wird bei Kontoerstellung gesetzt und ist immutable. Er ist kein Label, er ist eine Einschränkung, die beeinflusst, welche Überweisungen erlaubt sind.

2. Überweisungsregeln, die von der Domain-Schicht erzwungen werden.

Eine Überweisung von einem Safeguarding-Konto auf ein Betriebskonto wird standardmäßig blockiert. Der einzige erlaubte Pfad für Gelder von Safeguarding zu Betrieb ist über einen expliziten Gebührenentnahme-Workflow: Dem Kunden wird eine Gebühr berechnet (Reduktion des E-Geld-Saldos), und der Gebührenbetrag wird von Safeguarding zu Betrieb transferiert. Dieser Workflow wird journalisiert, auditiert und erfordert explizite Autorisierung in der Orchestrierungsschicht.

Die Sequenz für eine monatliche Gebühr von EUR 2,00:

Schritt 1: DEBIT  customer:alice:eur    2,00    (Verbindlichkeit sinkt, Alice schuldet weniger)
           CREDIT platform:fees:eur     2,00    (Umsatz steigt, Gebühr verdient)

Schritt 2: DEBIT  safeguarding:eur      2,00    (Aktiva sinken, Gelder freigegeben)
           CREDIT operating:eur         2,00    (Eigenkapital steigt, eigene Mittel des Instituts)

Beide Schritte sind Teil eines einzigen Durable Workflows. Wenn Schritt 1 erfolgreich ist und Schritt 2 fehlschlägt, wiederholt die Workflow-Engine Schritt 2 vom Journal. Der Safeguarding-Saldo gerät nie aus dem Gleichgewicht mit dem Kundensaldo, weil die zwei Bewegungen in einem einzigen Workflow gekoppelt sind, nicht über unabhängige Prozesse verstreut.

3. Echtzeit-Safeguarding-Saldoprüfung.

Das System kann jederzeit einen Safeguarding-Report generieren:

Kunden-E-Geld gesamt:       EUR 1.247.891,23
Safeguarding-Saldo:         EUR 1.198.442,00
Float (ausstehendes Settlement): EUR   52.100,00
Deckung:                    EUR 1.250.542,00
Überschuss:                 EUR     2.650,77   (>0 = konform)

Wenn der Überschuss negativ ist, ist das Institut unzureichend abgesichert. Das System löst einen Alert aus. Das Operations-Team hat Minuten, nicht Tage, zur Untersuchung und Korrektur.

Float und Settlement-Timing

Zwischen Zahlungsinitiierung und Settlement sind Gelder im Transit. Ein Kunde empfängt eine SEPA-Lastschrift: Die Bank des Begünstigten hat den Einzug eingereicht, aber die Bank des Zahlers hat noch nicht abgewickelt. Die Gelder werden dem E-Geld-Konto des Kunden gutgeschrieben (Verbindlichkeit steigt), aber der entsprechende Aktivaanstieg hängt vom Settlement-Zyklus ab.

Während dieses Fensters beinhaltet die Safeguarding-Gleichung Float:

Kundensaldo:            EUR 100,00    (Kunde sieht EUR 100)
Safeguarding:           EUR   0,00    (Bank hat die Gelder noch nicht erhalten)
Float (SDD ausstehend): EUR 100,00    (Settlement erwartet in D+5)
Deckung:                EUR 100,00    (Float zählt zur Deckung)

Das Haltefrist-Modell verfolgt dies präzise. Gelder im Status SETTLED_PENDING werden als Float gezählt, für Safeguarding-Zwecke gedeckt, aber dem Kunden noch nicht verfügbar. Nach Ablauf der Haltefrist und Übergang der Gelder zu SETTLED_AVAILABLE wechseln sie von Float zu Safeguarding (die Bank bestätigt den Empfang).

Wenn während der Haltefrist ein Return erfolgt (R-Transaktion), wird der Float reduziert und der E-Geld-Saldo des Kunden storniert. Die Safeguarding-Gleichung rebalanciert automatisch, weil beide Seiten sich zusammen bewegen.

Reporting-Anforderungen

Die EMI-Lizenzierung bringt spezifische Reporting-Pflichten mit sich. Die Architektur muss diese Reports aus dem Ledger produzieren, nicht aus einer separaten Reporting-Datenbank, nicht aus einer ETL-Pipeline und nicht aus einer Tabelle.

Die Daten für jeden Report stammen aus derselben Quelle: dem immutablen Double-Entry-Ledger. Ausstehendes Kunden-E-Geld ist die Summe aller customer_emoney-Kontosalden (Haben-normal). Safeguarding-Deckung ist die Summe aller safeguarding-Kontosalden (Soll-normal) plus float-Salden. Der Report ist eine Abfrage, keine Konstruktion.

Das ist der Vorteil, von Tag eins auf Double-Entry zu bauen. Die Bilanz ist eine Eigenschaft des Ledgers, kein abgeleitetes Artefakt. Die Safeguarding-Gleichung ist eine Teilmenge der Bilanzgleichung (Aktiva = Verbindlichkeiten + Eigenkapital). Sie wird jedes Mal verifiziert, wenn eine Überweisung gebucht wird, weil jede Überweisung ausgeglichen sein muss.

Häufige Safeguarding-Fehler

Drei Muster, die Safeguarding-Risiko erzeugen:

1. Gemeinsame Bankkonten. Das Institut verwendet ein Bankkonto für sowohl Kundengelder als auch Betriebsmittel und verlässt sich auf interne Buchhaltung, um die Aufteilung zu verfolgen. Wenn die Bank das Konto einfriert (aus beliebigem Grund, AML-Untersuchung, Streit, Insolvenz der Bank), sind alle Gelder eingefroren, einschließlich Kundengelder. EMD2 fordert physische Segregation: ein dediziertes Bankkonto für Safeguarding, getrennt vom Betriebskonto.

2. Fehlende Float-Verfolgung. Kundensalden beinhalten ausstehende Settlements (der Kunde sieht die Gutschrift), aber der Safeguarding-Saldo beinhaltet nicht den entsprechenden Float. Der Safeguarding-Report zeigt ein Defizit, das nicht tatsächlich existiert, oder schlimmer, einen Überschuss, der ein echtes Defizit maskiert, weil der Float doppelt gezählt wird.

3. Gebührenentnahme ohne Workflow-Kopplung. Gebühren werden von Kundensalden abgezogen (Verbindlichkeit reduziert), aber die entsprechende Bewegung von Safeguarding zu Betrieb geschieht in einem separaten, asynchronen Prozess. Wenn der asynchrone Prozess fehlschlägt oder verzögert ist, hält das Safeguarding-Konto vorübergehend mehr als es sollte, was technisch konform aber operativ verwirrend ist, oder hält weniger als es sollte, wenn das Timing umgekehrt ist.

Jeder dieser Fehler ist durch Architektur vermeidbar. Separate Bankkonten. Explizite Float-Kontotypen. Durable Workflows, die die zwei Seiten einer Gebührenentnahme koppeln. Die Muster sind nicht komplex. Sie müssen bewusst sein.

---

Weiterlesen: Das Ledger | Sicherheit & Compliance

---

Quellen:

• EMD2, Richtlinie 2009/110/EG, Art. 7 (Safeguarding-Anforderungen), Art. 10 (Schutz von Geldern)
• PSD3/EMD3, COM/2023/366 (Vorschlag zur Zusammenführung von PSD2 und EMD2)
• Ley 21/2011 (Spanien), Art. 8-10 (Safeguarding für spanische EMIs)
• BaFin: Leitfaden zu Safeguarding-Anforderungen für E-Geld-Institute
• HGB §246, Verrechnungsverbot, Kundenvermögen darf nicht gegen Verbindlichkeiten des Instituts aufgerechnet werden