E-Geld-Plattform-Software

E-Geld- und Zahlungs­infrastruktur

Konten, Salden, Ledger mit doppelter Buchführung, vIBAN, Karten, Zahlungen, AML/KYC und Back Office werden als ein Finanzsystem entwickelt statt als getrennte Einzelprodukte – Infrastruktur für E-Geld-Institute und Zahlungsinstitute im Vereinigten Königreich und in der Europäischen Union.

Audit Ready Compliance Ready On-Premises Option Source-Code Option

Das Kundenproblem

Das Produkt ist das Ledger

Wallet-Oberflächen und Karten sind die sichtbare Seite eines E-Geld-Geschäfts. Das operative Gewicht liegt darunter: korrekte Salden, Buchungen nach doppelter Buchführung, Abstimmung (Reconciliation) gegenüber Banken und Prozessoren, Daten zur Sicherung von Kundengeldern (Safeguarding) und die Prüfpfade, die eine Aufsichtsbehörde erwartet.

Aus Einzelprodukten zusammengesetzte Plattformen versagen unbemerkt. Salden werden editiert statt gebucht, Anbieterauszüge lassen sich nie vollständig abstimmen, und die Lücken zeigen sich im Zulassungsverfahren, bei einer Safeguarding-Prüfung oder bei einem Vorfall.

Grumpio behandelt die Plattform als ein Finanzsystem. Eine etablierte modulare Basis wird an Marke, Lizenzmodell und Anbieter des Instituts angepasst, während Bereitstellung und regulatorische Bereitschaft parallel voranschreiten: ein Umsetzungsplan, eine verantwortliche Stelle.

Modulumfang

Eine Plattform. Jede Zahlungsebene.

Die nachfolgenden Module arbeiten in einer Architektur und greifen auf dasselbe Ledger mit doppelter Buchführung und dasselbe Back Office zu, statt als getrennte Produkte zu laufen. Der Umfang wird je Projekt an Zulassung, Markt und Anbietervereinbarungen des Instituts konfiguriert; technische Fähigkeit wird stets von Zulassung und Abhängigkeiten von Drittanbietern unterschieden.

Konten und Salden

Kunden- und Unternehmenskonten mit schwebenden und verfügbaren Salden, Sperrbeträgen und einem kontrollierten Transaktionslebenszyklus über mehrere Währungen.

Ledger mit doppelter Buchführung

Finanzbewegungen werden über doppelte Buchungen und eine prüffähige Transaktionshistorie geführt statt über veränderbare Saldenfelder; Abstimmungsdaten werden systemseitig erzeugt.

vIBAN und Banküberweisungen

vIBAN-Zuweisung, Zuordnung eingehender Überweisungen, ausgehende Aufträge, Empfängerverwaltung und Webhooks. Der Live-Umfang richtet sich nach den Bank- und vIBAN-Anbieter-Vereinbarungen des Kunden.

Kartenprogramm-Integration

Lebenszyklus virtueller und physischer Karten, Verarbeitung von Autorisierungsereignissen, Ledger-Bewegungen, Limits und Sperrfunktionen. Grumpio gibt keine Karten aus und druckt sie nicht; das übernehmen regulierte Kartensysteme, Issuer und Prozessoren.

Fiat- und Krypto-Aufladung

Aufladung über Banküberweisung, vIBAN und anbietergestützte Verfahren. Krypto-Einzahlungen mit Wallet-Risikoprüfung und Umwandlung stehen zur Verfügung, wo Zulassung und Kartenprogramm dies zulassen.

P2P-Überweisungen

Interne Überweisungen mit Empfängerauflösung, Ledger-Buchung, Gebühren, Limits, Risikokontrollen und Benachrichtigungen.

Rechnungs- und Servicezahlungen

Ein Zahlungsmodul für Rechnungen und Dienstleistungen. Die Live-Abdeckung richtet sich nach dem lokalen Aggregator oder Rechnungszahlungs-Anbieter und dessen kommerziellen Vereinbarungen.

Virtueller POS und Händler

Händler-Onboarding, Zahlungslinks, Erstattungen, Settlement und Reporting. Merchant Acquiring richtet sich nach der Zulassung des Kunden sowie dessen Acquirer- und Prozessor-Vereinbarungen.

Abstimmung

Abstimmung von Bank-, vIBAN-, Kartenprozessor-, Händler- und Ledger-Daten mit Ausnahmebehandlung sowie Tages- und Periodenberichten.

Safeguarding

Safeguarding beginnt im Ledger

Die E-Geld-Plattform unterstützt Ledger, Abstimmung, Aufzeichnungen und operative Abläufe, die für die Umsetzung des Safeguarding-Modells des Kunden erforderlich sind. Methode und Kontenstruktur des Safeguarding bleiben Sache des Instituts; Aufgabe der Plattform ist, sie in den Betrieb zu überführen und nachweisbar zu halten.

  • Aufzeichnungen relevanter Gelder: Identifikations- und Klassifikationsdaten für die Gelder, die das Safeguarding-Modell erfasst.
  • Abstimmung: Abstimmung von Bank- und Safeguarding-Konten mit Ausnahme-Workflows und Periodenberichten.
  • Berichtsdaten: strukturierte Ausgaben für Safeguarding-Meldungen, Prüfungsarbeit und Abwicklungsnachweise.
  • Berechtigungen und Freigaben: rollenbasierte Kontrolle über Vorgänge mit Kundengeldern; administrative Aktionen werden mit Prüfpfaden hinterlegt.

Technische Struktur

Für den Produktionsbetrieb entwickelt

Die Plattform ist auf hohe Verfügbarkeit, horizontale Skalierung und Observability ausgelegt. Der Engineering-Ansatz – Daten- und Ereignisarchitektur, Bereitstellung und Sicherheit – wird auf der Technologie-Seite beschrieben.

Technischen Umfang prüfen
  • Gebühren- und Limit-Engine

    Transaktionsgebühren, Kundensegmente sowie Tages-, Monats-, Karten- und Überweisungslimits werden zentral administriert statt modulweise fest codiert.

  • Back Office und Berechtigungen

    Kunden, Konten, Salden, Überweisungen, Karten, Händler, Abstimmung und Reporting werden über rollenbasierte Berechtigungen administriert; Administratorenaktivität wird in der Prüfhistorie aufgezeichnet.

  • AML/KYC- und Screening-Workflows

    Onboarding, laufende Überprüfung und Wallet-Risikoprüfungen werden über AML-Screening und KYC-Verifizierung integriert – bereitgestellt durch Legichain oder vom Kunden gewählte Anbieter – und die Ergebnisse werden prüffähig gespeichert.

  • Web-, iOS- und Android-Anwendungen

    Kundenanwendungen und das administrative Back Office werden über Web und Mobile an Marke und Modulumfang des Instituts angepasst.

  • An Standards ausgerichtetes Engineering

    Ein an ISO 27001 ausgerichteter Sicherheitsansatz, ein an ISO 22301 ausgerichteter Business-Continuity-Ansatz und Kartenintegrationen, die an den einschlägigen PCI-DSS-Anforderungen ausgerichtet sind, gehören zum Liefermodell.

Regulatorischer Kontext

Zwei Märkte. Zwei Regelwerke.

Die E-Geld- und Zahlungsmodule sind um die einschlägigen FCA-, Safeguarding-, AML- und Informationssystem-Anforderungen herum strukturiert; die Lieferung umfasst ein jurisdiktionsspezifisches Bereitschaftsprogramm statt einer generischen Checkliste.

Plattformfähigkeit und Zulassung sind zu unterscheiden: Zulassungsart, Safeguarding-Methode und Anbietervereinbarungen folgen dem eigenen regulatorischen Modell des Kunden.

Bereitschaft bewerten
  • Vereinigtes Königreich

    Die Umsetzung wird um das Zahlungsdienste- und E-Geld-Regelwerk der FCA herum geplant, einschließlich der verschärften Safeguarding-Regeln, die seit Mai 2026 gelten, und der Erwartungen an die Operational Resilience (betriebliche Widerstandsfähigkeit) für erfasste Institute.

  • Europäische Union

    Der geltende PSD2- und EMD2-Rahmen, die starke Kundenauthentifizierung und DORA werden als laufende Betriebsanforderungen behandelt; das kommende PSD3- und PSR-Paket wird im Zuge seiner Finalisierung beobachtet. Die E-Geld-Plattform wird an die Zulassung im Herkunftsmitgliedstaat, das Safeguarding-Modell, die Zahlungsschienen und die Kartenprogramm-Struktur des Kunden angepasst.

Bereitstellung

Kundenspezifische Bereitstellung

Die Plattform ist nicht an einen Cloud-Anbieter gebunden. Die Bereitstellung folgt den regulatorischen, Datenresidenz-, Kosten- und Betriebsanforderungen des Kunden; Umgebungen können On-Premises, in einer Private Cloud, beim bevorzugten Anbieter oder in einem dedizierten Rechenzentrum installiert werden. Installation, Logging und Backup werden im Rahmen des Projekts konfiguriert.

On-Premises und dediziert

Installation auf vom Kunden gewählten Servern oder dedizierter Infrastruktur; Datenflüsse, Aufbewahrung und Zugriff werden am Betriebsmodell ausgerichtet konfiguriert.

Private und Public Cloud

Bereitstellung beim bevorzugten Cloud-Anbieter, geliefert mit Umgebungstrennung, Secrets-Management und Sicherheitskonfiguration.

DevOps und Übergabe

Containerbasierte Bereitstellung, CI/CD, Logging, Backup und Übergabeschulung für das technische Team gehören zur Installation.

Kommerzielles Modell

White-Label- und Source-Code-Optionen

Dieselbe Plattform wird über zwei Modelle geliefert, gewählt nach interner Engineering-Kapazität, Datenresidenz, Erwartungen an geistiges Eigentum und Supportmodell. White-Label-Kunden behalten eine vertragliche Option auf den Erwerb des Quellcodes zu definierten kommerziellen Bedingungen; die endgültigen Rechte sind in beiden Modellen vertraglich geregelt.

Vergleich der Liefermodelle; der endgültige Umfang wird vertraglich festgelegt.
Umfang White-Label Source-Code Enterprise
Ausgangsmodell Start auf Basis der etablierten Plattform unter einer Monats- oder Jahreslizenz Quellcode wird unter einer Lizenz geliefert, die einer benannten juristischen Person erteilt wird
Anpassung Markenauftritt, Modulauswahl, Gebühren- und Limitkonfiguration, Integrationen Voller Quellcode-Zugriff für die interne Entwicklung; eigenständiger Weiterverkauf ist nicht gestattet
Daten und Hosting Kundenkontrollierte Infrastruktur, wo rechtlich und technisch angemessen Vom Kunden gewählte Server, Rechenzentrum oder Cloud-Anbieter
Lieferumfang Installation, Schulung, laufender Support und Updates Quellcode, Deployment-Artefakte, technische Dokumentation, Übergabeschulung
Übergang Option auf Erwerb des Quellcodes zu definierten kommerziellen Bedingungen Übertragbar mit dem Verkauf der juristischen Person, soweit der Vertrag dies zulässt

Integrationen

Integrationen nach Kategorie

Die Plattform wird an die bestehende und geplante Anbieterlandschaft des Instituts angebunden. Der Integrationsumfang wird je Projekt durch Anbietervereinbarungen und technische Bewertung definiert.

  • Banken und Karten: Integrationsfähigkeit für Banken, vIBAN-Anbieter, Visa, Mastercard, Issuer-/BIN-Sponsoren und Kartenprozessor-Anbieter.
  • Zahlungsschienen: Banküberweisungs- und vIBAN-Flüsse, Mehrwährungsunterstützung und in der EU SEPA- und Instant-Payment-Integration, wo verfügbar.
  • KYC- und AML-Anbieter: Legichain oder vom Kunden gewählte Anbieter; Multi-Provider-Betrieb und Anbieterwechsel werden unterstützt.
  • Rechnungszahlungs-Aggregatoren: lokale Aggregatoren und Servicenetzwerke, wo das Produkt Rechnungs- und Servicezahlungen umfasst.
  • Benachrichtigungs- und Betriebswerkzeuge: E-Mail, SMS und Systeme für das operative Monitoring.

FAQ

Häufig gestellte Fragen

Nächster Schritt

Die Plattform wird gezeigt, nicht beschrieben

Eine Produktdemonstration behandelt den Modulumfang, das Ledger- und Abstimmungsmodell und die Lieferoptionen. Fragen zum Leistungsumfang werden am laufenden System beantwortet.