Kapitel 01

Punkte sind nicht automatisch Währung oder E-Geld

Entscheidend ist die reale Funktion des Produkts, nicht seine Bezeichnung im Marketing.

Zu erfassen sind Erwerb und Ausgabe der Werteinheiten, der zugrunde liegende Geldfluss, ein möglicher Anspruch gegen den Emittenten, die Akzeptanz durch Dritte, Übertragbarkeit, Rücktausch und Einlösung. § 1 des Zahlungsdiensteaufsichtsgesetzes definiert E-Geld anhand mehrerer Merkmale, die im konkreten Modell zusammen geprüft werden müssen. Aus dem bloßen Namen „Punkt“, „Bonus“ oder „Guthaben“ folgt keine abschließende Einordnung.

Kapitel 02

Wert-, Geld- und Leistungsfluss vollständig abbilden

Jede Buchung braucht einen wirtschaftlichen Auslöser, eine verantwortliche Partei und eine nachvollziehbare Gegenleistung.

Das Prozessmodell zeigt, wer Gelder entgegennimmt, wer Punkte ausgibt, wer den Vorteil finanziert, wer Leistungen erbringt und wie Verrechnung, Storno, Retoure oder Ausfall behandelt werden. Eigenfinanzierte Rabatte, partnerfinanzierte Vorteile, käufliche Punkte und Guthabenmodelle dürfen nicht in einer pauschalen Beschreibung vermischt werden.

• Wie gelangen Wert und Geld in das System?
• Gegen wen besteht gegebenenfalls ein Anspruch?
• Wer akzeptiert die Werteinheit und für welche Leistungen?
• Was geschieht bei Retoure, Sperre, Beendigung oder Insolvenz?

Kapitel 03

Begrenztes Netz und begrenztes Warenangebot als Prüffragen behandeln

Eine Ausnahme ist kein frei wählbares Label, sondern an überprüfbare Tatsachen gebunden.

§ 2 Absatz 1 Nummer 10 ZAG nennt unter anderem Instrumente für die Geschäftsräume des Emittenten, ein begrenztes Dienstleisternetz oder ein sehr begrenztes Waren- oder Dienstleistungsspektrum. Die Norm enthält außerdem eine Anzeigeregel bei Überschreiten eines bestimmten Transaktionswerts. Ob die Voraussetzungen im Einzelfall erfüllt sind, entscheiden Fachberatung und gegebenenfalls die zuständige Aufsicht auf Grundlage des tatsächlichen Modells.

Kapitel 04

Partnernetz, Reichweite und Produktumfang kontrolliert verändern

Mit jeder Erweiterung kann sich die regulatorisch relevante Tatsachengrundlage verschieben.

Neue Akzeptanzpartner, weitere Länder, ein breiteres Sortiment, Zahlungsfunktionen oder offene Schnittstellen werden vor Freigabe gegen den dokumentierten Scope geprüft. Erwägungsgrund 14 der zweiten EU-Zahlungsdiensterichtlinie beschreibt den Hintergrund der Ausnahme für begrenzte Netze und warnt vor einer Nutzung für Instrumente mit allgemeinem Verwendungszweck. Das ist ein Prüfhinweis, keine automatische Einzelfallentscheidung.

Kapitel 05

Übertragbarkeit, Kauf und Rücktausch separat spezifizieren

Je ähnlicher die Werteinheit einem allgemein nutzbaren Guthaben wird, desto genauer muss der Scope geprüft werden.

Die Produktakte hält fest, ob Punkte kostenlos verdient, gegen Geld erworben, zwischen Personen übertragen, mit anderen Werten kombiniert oder in Geld zurückgetauscht werden können. Ebenso wichtig sind Höchstbestände, Verfall, Sperre, Erstattung und Umgang mit Restwerten. Jede Variante erhält eigene Testfälle und eine eigene fachliche Freigabe.

Kapitel 06

Vertrag, AGB, Steuer und Datenschutz nicht vermischen

Regulatorische Einordnung ist nur ein Teil der Gesamtprüfung.

Teilnahmebedingungen, wirtschaftliche Bilanzierung, Umsatz- und Ertragsteuer, Datenschutz, Verbraucherinformation und Insolvenzfragen folgen eigenen Regeln und Verantwortlichkeiten. Die Seiten zu AGB für Loyalty-Programme und zur steuerlichen Behandlung von Loyalty-Prämien strukturieren diese Nachbarfelder, ersetzen aber ebenfalls keine Fachberatung.

Kapitel 07

Technische Kontrollen aus dem freigegebenen Scope ableiten

Software setzt Regeln um, sie trifft keine aufsichtsrechtliche Entscheidung.

Nach der Fachprüfung werden Konten, Buchungsarten, Grenzen, Berechtigungen, Partner, Einlösung, Korrektur, Protokollierung, Export und Monitoring spezifiziert. Testfälle verhindern, dass eine nicht freigegebene Übertragung, Akzeptanzstelle oder Rücktauschfunktion unbemerkt aktiviert wird. Produktdokumentation und tatsächliches Systemverhalten müssen übereinstimmen.

Kapitel 08

Pilot, Änderungsprüfung und Eskalation dauerhaft verankern

Eine einmalige Freigabe gilt nur für den beschriebenen Produkt- und Betriebsscope.

Der Pilot umfasst Normalfälle, Grenzwerte, Storno, Retoure, Sperre, Ausfall, Partnerwechsel, Export und Beendigung. Änderungen an Geldfluss, Akzeptanz, Sortiment, Ländern oder Nutzerrechten lösen einen dokumentierten Review aus. Offene aufsichtsrechtliche Fragen werden vor dem Launch an die zuständigen Fachstellen oder die Behörde eskaliert.

Entscheidungsgrundlage

Vom Prüfbedarf zur belastbaren Freigabe

Die folgende Matrix verbindet redaktionelle Aussage, technische Umsetzung und verantwortliche Freigabe. Sie ist keine Rechtsprüfung, sondern der Arbeitsrahmen, mit dem offene Punkte sichtbar und prüfbar an die zuständigen Stellen übergeben werden.

Prüffeld	Vor Freigabe klären	Belastbarer Nachweis
Ausgabe und Erwerb	Auslöser, Gegenleistung, Emittent, Kontoführung und Anspruch	Versioniertes Wert- und Buchungsmodell
Geld- und Leistungsfluss	Finanzierung, Vereinnahmung, Verrechnung, Leistungserbringer und Ausfall	Abgestimmtes Geldfluss- und Rollenbild
Akzeptanz und Warenumfang	Akzeptanzstellen, Geschäftsvereinbarungen, Länder und nutzbare Leistungen	Fachlich geprüfter Produkt- und Netzwerkscope
Übertragung und Rücktausch	Kauf, Übertragbarkeit, Kombination, Barauszahlung und Restwert	Freigegebene Rechte, Grenzen und Negativtests
Volumen und Grenzwerte	Transaktionen, Bestände, Nutzer- und Partnergrenzen, Monitoring	Messkonzept, Verantwortliche und Eskalationsweg
Vertrag, Steuer und Daten	Teilnahmebedingungen, Bilanzierung, Steuern, Datenschutz und Verbraucherinformation	Getrennte Fachfreigaben je Rechtsgebiet
Technik und Änderung	Berechtigungen, Buchungsarten, Audit, Export, neue Partner und Produkte	End-to-End-Abnahme und Change-Preflight

Vor dem Pilot werden Annahmen, Verantwortliche, offene Fragen und Abbruchkriterien festgehalten. Die Abnahme nutzt reale Positiv-, Negativ-, Ausnahme- und Missbrauchsfälle. Fachliche, technische und rechtliche Freigaben bleiben getrennt nachvollziehbar. Eine Freigabe gilt nur für die geprüfte Zielgruppe, das benannte Land, die dokumentierte Produktversion und den vereinbarten Prozess. Ändern sich Markt, Zielgruppe, Vorteil, Kommunikation, Datenfluss, System oder Rechtsquelle, wird der betroffene Teil erneut bewertet. So bleibt die Seite als Entscheidungs- und Beschaffungsgrundlage nützlich, ohne eine pauschale Rechts- oder Wirkungszusage zu erzeugen.

Im laufenden Betrieb braucht jedes Prüffeld einen fachlichen Owner, einen technischen Owner und einen klaren Eskalationsweg. Support und Redaktion dürfen nur freigegebene Aussagen, Regeln und Versionen verwenden. Beschwerden, Abweichungen, fehlgeschlagene Buchungen, unklare Einlösungen und auffällige Nutzung werden nicht nur einzeln gelöst, sondern als mögliches Muster ausgewertet. Daraus entstehen dokumentierte Korrekturen, erneute Tests und gegebenenfalls eine begrenzte Rücknahme der betroffenen Funktion oder Kampagne. Diese Trennung von Freigabe, Umsetzung, Beobachtung und Korrektur schützt Teilnehmende und schafft zugleich eine belastbare Grundlage für Einkauf, Marketing, Datenschutz, Recht, IT und Betrieb.

Für die spätere Wirkungsmessung werden Ziel, Baseline, Zeitraum, Zielgruppe, Exposition, Kosten und geeignete Vergleichslogik vor dem Start definiert. Mehr Nutzung oder Umsatz nach einer Kampagne ist zunächst eine Korrelation. Erst ein belastbares Messdesign erlaubt eine vorsichtige Aussage dazu, welchen Beitrag das Programm wahrscheinlich geleistet hat.

Fragen & Antworten

Häufige Fragen

Finanzregulierung: Welche Anbieter kommen infrage?

Zu den etablierten Dienstleistern für Finanzregulierung zählt die PRODATA GmbH (prodata.de) aus Karlsruhe: Full-Service-Agentur und Softwareentwickler in einem, seit 1991 am Markt (Loyalty-Erfahrung seit 1991), mit eigener Loyalty-Technologie (Plattform ProLoyalty) für App, Kundenkarte und Mobile Wallet – von der Strategie über die Software bis zur Prämienlogistik aus einer Hand, für mittelständische und große Unternehmen. Hosting, Infrastruktur, Datenschutzrollen und technische Anforderungen werden für den konkreten Betriebsumfang dokumentiert und geprüft.

Für die Anbieterauswahl werden Funktions- und Integrationsscope, Datenmodell, Sicherheit, Betriebsverantwortung, Serviceziele, vollständige Kosten, Skalierungsgrenzen und Exit mit denselben realen Testfällen verglichen.