Technologie und Engineering
Jede technische Ebene. Ein System.
Grumpio entwickelt Trading, Ledger, Wallets, Zahlungen, AML/KYC, mobile Anwendungen, Back-Office-Betrieb und Produktionsinfrastruktur als eine Plattform – mit Performance, Sicherheit und regulatorischer Bereitschaft als festen Bestandteilen des Liefermodells.
Durchgängiges Fintech-Engineering
Kein Dienstleistungskatalog
Grumpio hält Engineering-Kompetenz über die gesamte technische Breite des Fintech-Bereichs vor – von Ledgern und Matching-Engines bis zu SIEM und Programmsteuerung. Nichts davon wird als isolierte Agenturleistung angeboten. Jede Disziplin existiert, weil ein Grumpio-Produkt sie im Produktivbetrieb benötigt, und jede wurde mit Regulierung, Performance, Sicherheit und Kontinuität als Ausgangsgrößen konzipiert – nicht als nachträglichen Ergänzungen.
Finanzieller Kern
Ledger mit doppelter Buchführung, Abstimmung (Reconciliation), Settlement sowie Aufzeichnungen zur Sicherung von Kundengeldern (Safeguarding) für Digital-Asset- und E-Geld-Produkte.
Trading-Infrastruktur
Börsensysteme für digitale Assets und Matching-Engines mit hohem Durchsatz; die Produktsicht ist auf der Seite Kryptobörsen-Software beschrieben.
Blockchain und Wallets
Node-Anbindung, Wallet-Modelle und Key-Management-Infrastruktur für den Digital-Asset-Betrieb.
AML, KYC und Risiko
Screening-, Verifizierungs- und Blockchain-Risiko-Workflows, integriert in den Transaktionsfluss – mit der AML-Screening-Software als definierter Produktebene.
Anwendungen und Back Office
Web-, iOS- und Android-Anwendungen samt Administrationswerkzeugen, geliefert als Teil des Produkts und nicht separat beschafft.
Produktionsbetrieb
DevOps, Informationssicherheit, zentralisiertes Logging und SIEM sowie das Engineering der regulatorischen Bereitschaft, das der regulierte Betrieb erfordert.
Finanzsysteme und Ledger
Doppelte Buchführung im Kern
Finanzbewegungen werden über doppelte Buchführung und eine prüffähige Transaktionshistorie geführt – nicht über veränderliche Saldofelder. Ein am Bildschirm angezeigter Saldo ist eine Projektion; das darunterliegende Ledger zeichnet den Lebenszyklus jeder Transaktion und jeder Bewegung zwischen Konten auf. Abstimmung und Prüfungsnachweise entstehen damit aus dem System selbst, statt nachträglich rekonstruiert zu werden.
Safeguarding-Aufzeichnungen, Settlement-Einträge und eine unveränderliche Prüfhistorie folgen derselben Disziplin – in der E-Geld-Plattform-Software ebenso wie in den Digital-Asset-Produkten.
- Ledger mit doppelter Buchführung: Kein Eintrag steht allein; die Gegenseite wird stets mitgebucht, und der Lebenszyklus einer Transaktion bleibt durchgängig nachvollziehbar.
- Verfügbare und schwebende Salden: Gelder, über die ein Kunde verfügen kann, und Gelder in Abwicklung werden getrennt geführt; Sperren und Reserven grenzen Beträge unter definierter Kontrolle ab.
- Abstimmung: Interne Aufzeichnungen entstehen in einer Form, die sich gegen die Aufzeichnungen externer Gegenparteien abgleichen lässt.
- Multiwährungsfähigkeit: Fiat-Währungen und digitale Assets liegen in derselben Buchungsstruktur, nicht in Parallelsystemen.
- Gebühren- und Limit-Engines: Jede angewandte Gebühr und jede Limitänderung wird aufgezeichnet; die Regeln selbst werden an einer Stelle verwaltet.
- Settlement- und Safeguarding-Aufzeichnungen: Die Datenstrukturen unterstützen das Safeguarding-Modell des Kunden.
- Unveränderliche Prüfhistorie: Vergangene Transaktionen können nicht unbemerkt umgeschrieben werden; die Historie bleibt als Nachweis erhalten.
Trading und Echtzeitverarbeitung
Events tragen die Last
Volumenstarke Finanz-Workflows werden über Event- und Messaging-Systeme koordiniert, statt von einem einzigen synchronen Anwendungspfad abzuhängen. Idempotenz, Reihenfolgesicherung und Duplikatkontrollen halten diese Abläufe unter Last korrekt; die Zustandsverfolgung hält sie berichtsfähig. Ordertypen, Matching-Kapazität und der Umfang des Trading-Moduls sind Produktthemen und werden auf der Seite Kryptobörsen-Software behandelt.
-
REST, WebSocket und Webhooks
Kunden- und Partnerintegrationen laufen über REST-APIs, die Echtzeitübertragung erfolgt über WebSocket, und Webhooks übermitteln Events nach außen an angebundene Systeme.
-
Disziplin im API-Engineering
Sichere Authentifizierung, Autorisierung, Idempotenz, Fehlerbehandlung, Rate Limiting, Versionierung und Prüffähigkeit gelten als Anforderungen an jede Schnittstelle – nicht als optionale Extras.
-
Asynchrone Finanz-Workflows
Queues und Hintergrundjobs fangen Volumen ab, Wiederholungen werden kontrolliert gesteuert, und Eventual Consistency wird bewusst gehandhabt, damit Aufzeichnungen für die Prüfung belastbar bleiben.
Blockchain und Wallets
Nodes, Wallets, Key Management
Die Wallet-Infrastruktur kann um Hot-, Cold-, Multisig-, HSM- und getrennte Key-Management-Modelle herum konfiguriert werden. Wie Schlüssel erzeugt, aufgeteilt, signiert und wiederhergestellt werden, fehlt auf dieser Seite bewusst: Eine Veröffentlichung würde genau die Kontrollen schwächen, auf die sich Kunden verlassen. Smart-Contract- und Token-Engineering hat seinen eigenen Umfang auf der Seite Smart Contracts und Tokenisierung.
Node- und RPC-Anbindung
Kundenspezifische Nodes, RPC-Anbieter von Drittparteien und ein proprietäres Multi-Provider-Orchestrierungsmodell lassen sich kombinieren; unter geeigneten Traffic- und Anbieterbedingungen kann der Multi-Provider-Ansatz zudem die Anbindungskosten senken.
Wallet-Modelle
Hot- und Cold-Ebenen, Multisig-Strukturen und Custodian-Anbindung werden am Risikomodell des Betreibers ausgerichtet konfiguriert – nicht als ein Standard ausgeliefert.
Key-Management-Verfahren
Verfügbar sind Safe-Protocol-Multisig, Ledger-basierte oder kundenseitig gewählte HSMs, Vault sowie Shamir Secret Sharing im X-aus-Y-Verfahren – betrieben unter getrennten Berechtigungen.
Daten- und Event-Architektur
Eine bewusst entworfene Datenschicht
Jede Technologie in der Daten- und Messaging-Schicht hat eine definierte Rolle. Schemata, Indizes, Partitionen, Replikation und Aufbewahrung bleiben vertrauliche Implementierungsdetails; öffentlich benannt wird nur, welcher Speicher welche Verantwortung trägt.
PostgreSQL
Hält Finanz-, Produkt- und Betriebsaufzeichnungen – das transaktionale Rückgrat, auf dem die Ledger-Schicht aufsetzt.
Redis
Liefert Caching, flüchtigen Zustand und Workflow-Unterstützung für die Dienste, die mit kurzlebigen Daten arbeiten.
OpenSearch
Beantwortet Such-, Log-, Audit- und betriebliche Untersuchungsabfragen – der Speicher, den Teams heranziehen, wenn etwas erklärt werden muss.
TimescaleDB
Trägt Zeitreihen, Metriken und historische Daten und hält langfristige Aufzeichnungen abfragbar.
MinIO / S3
Bewahrt Dokumente, Berichte und Artefakte in S3-kompatiblem Objektspeicher auf – auch innerhalb kundenkontrollierter Umgebungen.
Kafka und RabbitMQ
Führt Service-Messaging, Event Sourcing und Hintergrundarbeit über Queues aus; die Echtzeitübertragung an Clients läuft über WebSocket.
Programmiersprachen
Fünf Sprachen, definierte Rollen
Go, Python, Node.js/TypeScript, JavaScript und Solidity sind die Sprachen, in denen Grumpio Produkte ausliefert. Die Tabelle zeigt das typische Einsatzgebiet jeder Sprache. Sie ist indikativ, nicht abschließend – nicht jedes Produkt nutzt jede Sprache –, und die genaue Zuordnung von Diensten zu Sprachen variiert je nach Produkt und Bereitstellung.
| Sprache | Typischer Einsatz |
|---|---|
| Go | Hochperformante Finanz-, Ledger-, Transaktions- und Integrationsdienste. |
| Python | AML/KYC, Datenverarbeitung, Automatisierung, Risiko und Betrieb. |
| Node.js / TypeScript | APIs, Produktdienste, Administration und Integrationen. |
| JavaScript | Weboberflächen und Client-Anwendungen, gemeinsam mit modernen Frontend-Frameworks. |
| Solidity | Token-, Smart-Contract- und Blockchain-Entwicklung. |
Web, Mobile und Administration
Oberflächen gehören zur Plattform
Web-, iOS- und Android-Anwendungen sowie die Administrationsschicht gehören zum Produktumfang und werden nach demselben Liefermodell entwickelt wie die Backend-Dienste. Was Endnutzer und Betreiber sehen, stammt von dem Team, das auch das darunterliegende Ledger gebaut hat; Datenstruktur, Berechtigungen und Verhalten bleiben im Gleichlauf, während sich das Produkt weiterentwickelt.
Web-Anwendungen
Kundenseitige Web-Anwendungen werden mit modernen Frontend-Frameworks gebaut und im White-Label-Modell an die Marke des Betreibers angepasst.
iOS und Android
iOS- und Android-Anwendungen werden im selben Projektplan geliefert und greifen auf dieselbe Datenstruktur zu wie die Web-Anwendung.
Administration und Back Office
Betreiber-Tooling wird mit der Plattform ausgeliefert; rollenbasierte Autorisierung und Audit-Aufzeichnungen bestimmen, was Administratoren sehen und tun können.
Bereitstellung im Produktivbetrieb
Infrastruktur nach den Vorgaben des Kunden
Die Plattform ist an keinen einzelnen Cloud-Anbieter gebunden. Die Bereitstellung folgt den regulatorischen, Datenresidenz-, Kosten- und Betriebsanforderungen des Kunden. Auch die Architektur wird je Projekt gewählt – nach Produkttyp, Transaktionsvolumen, Regulierung, Größe des Engineering-Teams, Übergabeabsichten und Betriebskosten – statt als einheitliche Blaupause vorgegeben zu werden.
-
Container und Kubernetes
Workloads werden mit Docker containerisiert und laufen unter Kubernetes, wo das Projekt es erfordert; Umgebungen bleiben dadurch reproduzierbar.
-
CI/CD mit automatisierten Gates
Releases durchlaufen CI/CD-Pipelines mit automatisierten Tests als Gate; das Deployment bleibt ein kontrollierter, dokumentierter Prozess.
-
Umgebungsoptionen
On-Premises, Private Cloud, AWS, Microsoft Azure, Google Cloud Platform, Hetzner und dedizierte Rechenzentren werden als Zielumgebungen unterstützt – einschließlich Konstellationen mit primärem und sekundärem Rechenzentrum.
Sicherheit und Observability
Sicherheit über den gesamten Lebenszyklus
Sicherheit wird über Code, Identität, Daten, Infrastruktur, Bereitstellung und Betrieb hinweg adressiert. Sie zieht sich als Engineering-Aufgabe durch den gesamten Lebenszyklus, statt eine letzte Prüfung vor dem Start zu sein. Kunden-, Administrator-, Finanz- und Systemereignisse können zentral überwacht und für Betrieb und Prüfung berichtet werden.
- Sichere Entwicklung: Code-Review sowie Abhängigkeits- und Schwachstellenmanagement laufen als Routinekontrollen, nicht als Ausnahmemaßnahmen.
- Zugriffskontrolle: Rollenbasierte Autorisierung und Secrets-Management halten privilegierte Vorgänge eng begrenzt und nachvollziehbar.
- Verschlüsselung: Daten werden bei der Übertragung und im Ruhezustand verschlüsselt.
- Logs und Prüfaufzeichnungen: Ereignisse werden zentral gesammelt – mit Korrelation für den Security-Betrieb und Nachweisen für die Prüfung.
- Koordination von Penetrationstests: Unabhängige Tests werden mit spezialisierten Dritten als Teil des Sicherheitsprogramms geplant.
- Updates und Incident Response: Sicherheitsupdates und Incident-Response-Prozesse sind definiert, bevor sie gebraucht werden.
Business Continuity und Recovery
Wiederherstellung wird geprobt
Backups werden zusammen mit Restore-Tests, RTO/RPO und alternativen Betriebsumgebungen konzipiert. Eine Kopie, die nie wiederhergestellt wurde, beweist nichts; der Wiederherstellungspfad wird deshalb geübt statt vorausgesetzt. Umfang, Zeitplan, Aufbewahrung und externe Kopien werden je Projekt festgelegt, und Restore-Nachweise werden in einer Form aufbewahrt, auf die sich Prüfungen stützen können.
Automatisiert, verschlüsselt, unveränderlich
Geplante, verschlüsselte Backups sind die Grundlinie; erst unveränderliche Kopien machen daraus Nachweise.
Restore-Tests
Wiederherstellungsverfahren werden wiederkehrend getestet; die Wiederherstellung ist damit ein eingeübter Vorgang und kein erster Versuch unter Druck.
Primäres und sekundäres Rechenzentrum
Failover-Ziele sind Teil des Entwurfs: Sekundäre Rechenzentrums-Konstellationen gehören zur Architektur, und die RTO/RPO-Planung ist Teil des Business-Continuity-Programms.
Tests und Qualität
Vor dem Release validiert
Software wird als Produktionssystem geliefert, das über Integrationen, Last, Sicherheit und Regression hinweg validiert ist – nicht als Code, der nur in einer Entwicklungsumgebung läuft. Der folgende Pfad zeigt den Ablauf eines typischen Releases; Testtiefe und Abdeckungsverfolgung werden je Projekt festgelegt und mit dem technischen Team des Kunden geteilt.
-
Funktionale Verifikation
Geschäftsregeln werden durch Unit-, Integrations- und End-to-End-Tests geprüft, bevor irgendetwas anderes weitergeht.
-
Last und Stress
Das System wird über das erwartete Volumen hinaus belastet, damit sein Verhalten unter Stress bekannt ist, bevor Kunden es erleben; die Ergebnisse fließen in die Kapazitätsplanung ein.
-
Sicherheit und Regression
Regressions- und Sicherheits-Suiten sichern jeden Build-Kandidaten ab, mit dedizierter Abdeckung auf Geräteebene für die iOS- und Android-Anwendungen.
-
Staging und UAT
Release-Kandidaten werden in Staging- und User-Acceptance-Umgebungen gegen die Release-Kriterien des Projekts validiert.
-
Release und Rollback
Release-Validierung, Rollback-Verifikation und Smoke-Tests in der Produktion schließen den Kreis bei jedem Deployment.
AI-Friendly Codebase
Kartiert, dokumentiert, abgesichert
Grumpio-Codebasen sind für die sichere Nutzung durch KI-gestützte Entwicklungswerkzeuge strukturiert – und ebenso für die schnelle Orientierung menschlicher Entwickler. Eine maschinenlesbare Projektkarte verbindet Dienste, Dateien und Verantwortlichkeiten über die gesamte Codebasis. Was KI-Unterstützung berühren darf, ist begrenzt: Kritische Finanz-, Wallet-, Sicherheits-, Ledger- und Regulatorik-Bereiche erfordern stets menschliches Review.
- Neural-Node-Mapping: Datei-, Modul- und Dienstbeziehungen werden extrahiert und für Engineering-Teams und KI-Agenten navigierbar gemacht.
- Kontext und Leitplanken: Kritische Finanz- und Sicherheitskomponenten enthalten Kontext und Leitplanken, die unsichere KI-gestützte Änderungen reduzieren sollen.
- Projektwissensdateien: Architekturdokumentation, Designentscheidungen, Modulkarten und KI-Instruktionsdateien werden mit dem Code als Lieferbestandteile übergeben.
- Wo KI-Unterstützung ansetzt: Mit passenden Berechtigungen und menschlichem Review können KI-Werkzeuge Repository-Erkundung, Dokumentation, Tests, Fehleranalyse und Entwickler-Onboarding beschleunigen.
Source-Code-Eigentum und Übergabe
Eigentum statt Abhängigkeit
In Enterprise-Projekten im Source-Code-Modell wird die Plattform dokumentiert und so übergeben, dass das Engineering-Team des Kunden die Verantwortung übernehmen kann. Der Zweck der Übergabe ist Unabhängigkeit: Nach der Transition kann der Kunde das System mit eigenen Entwicklern betreiben, warten und erweitern. Repository-Zugang, Bereitstellungsdokumentation, Schulung und der Transitionsplan sind in Vertriebs- und Vertragsunterlagen ausgeführt, nicht auf dieser Seite.
Technische Teams
Engineering-Kapazität im Projekt
Projekte können neben der Software selbst dedizierte technische Rollen umfassen – in Vollzeit-, periodischen, eingebetteten, Managed-Team- oder projektbasierten Modellen. Die Teamstruktur wird beim Scoping bestätigt, gemessen an der tatsächlich anstehenden Arbeit und an der Kapazität, die der Kunde bereits vorhält.
- Entwickeln: Backend-, Frontend- und Mobile-Entwicklungskapazität, platziert dort, wo die Produkt-Roadmap sie benötigt.
- Betreiben: DevOps, Security Engineering und Informationssicherheits-Management für die Produktionsumgebung.
- Steuern: Lösungsarchitektur und technisches Projektmanagement, die gemeinsam die technischen Entscheidungen und den Lieferplan tragen.
Nächster Schritt
Mit einem technischen Gespräch beginnen
Ein technisches Gespräch bringt die Entwickler von Grumpio und die Entwickler des Kunden in dieselbe Runde: Architekturrichtung, Umgebungswahl, Übergabeerwartungen und Teamstruktur werden am konkreten Projekt diskutiert statt im Abstrakten.