Plattformarchitektur
Ein Kern, viele Oberflächen – so funktioniert die Plattform wirklich.
Ein Rundgang durch die Plattform, vom Ledger aufwärts: die Konten, KYC, Karten und Krypto, die sich einen Double-Entry-Kern teilen; wie eine einzelne Zahlung von „Create“ bis „Reconcile“ läuft; und wo App-Ebene, Operator-Konsole und regulierte Grenze jeweils liegen.
Der Kern
Ein Ledger unter allem.
Im Zentrum der Plattform steht ein einziges Konten-Ledger. Jedes Konto – ein Kunden-Wallet, ein Händlersaldo, ein Gebührenkonto, ein Settlement-Konto – ist ein Knoten in diesem Ledger, und jede Wertbewegung ist eine Doppelbuchung: ein Konto wird belastet, ein anderes gutgeschrieben, beide Seiten sind immer gleich hoch. Das Ledger ist append-only. Einträge werden nie bearbeitet oder gelöscht; eine Korrektur ist eine neue, gegenläufige Buchung, sodass sich die gesamte Historie, wie ein Saldo zu seinem aktuellen Stand kam, jederzeit nachvollziehen lässt. Konten, KYC-Status, ausgegebene Karten und Krypto-Adressen hängen alle am selben Kontomodell. Deshalb können eine Kartenautorisierung, eine Banküberweisung und eine On-Chain-Einzahlung auf einen Saldo gebucht werden, ohne dass eine Abstimmungsschicht getrennte Systeme zusammenflicken muss.
- 01Double-Entry: Jede Buchung geht auf, Soll gleich Haben
- 02Append-only: Korrekturen sind neue Einträge, keine Änderungen
- 03Ein Kontomodell für Fiat, Karten und Krypto
- 04Der KYC-Status wandert mit dem Konto, nicht in einer Nebentabelle
Eine Zahlung, Ende zu Ende
Eine Zahlung, von Create bis Reconcile.
Eine Zahlung ist kein einzelner Aufruf, sondern ein kurzer Lebenszyklus, und jede Stufe ist ein Zustand, den Ledger und Ihre Systeme gleichermaßen sehen. Jede Statusänderung löst einen Webhook aus, und jeder Schreibzugriff ist idempotent: Derselbe Schlüssel führt wiederholt zum selben Ergebnis, sodass eine erneut gesendete Anfrage nie doppelt belastet.
- 01
Create
Ein Intent wird eröffnet: Betrag, Währung, beteiligte Konten. Noch ist nichts bewegt – das Ledger verzeichnet einen ausstehenden Eintrag.
- 02
Authorize
Die Rail prüft Deckung und Risiko und legt eine Reservierung an. Bei einer Karte ist das die Autorisierung, bei einer Überweisung wird die Belastung reserviert.
- 03
Capture
Der reservierte Betrag wird verbindlich übernommen. Das Ledger bucht die Doppelbuchung, die den Wert tatsächlich zwischen den beiden Konten bewegt.
- 04
Settle
Die Gelder werden über die zugrunde liegende Rail verrechnet – Kartenscheme, Bank oder Chain –, und die Settlement-Konten werden mit echtem Geld abgeglichen.
- 05
Reconcile
Die Plattform gleicht ihre eigenen Buchungen mit dem Settlement-Report der Rail ab; was nicht übereinstimmt, wird markiert, nicht versteckt.
Webhooks und Idempotenz sind an jeder Schnittstelle dieses Ablaufs im Einsatz. Ihre Systeme erfahren von einer Zahlung durch ein Ereignis, nicht durch Polling, und jede Anfrage, die Sie nach einem Timeout wiederholen, führt über ihren Idempotenzschlüssel zum selben Ergebnis, sodass eine Wiederholung nie doppelt belastet. Der Service, der Authorize und Capture ausführt, ist das Payment-Gateway.
Die App-Ebene
Whitelabel-Apps obenauf, eine Plattform darunter.
Der Kern stellt Funktionen bereit; die App-Ebene macht daraus Produkte. Jede kundenseitige App – Web und Mobile – ist ein Whitelabel-Client, der dieselben Konten, Zahlungen und Karten im eigenen Branding darstellt. Das Theming ist token-basiert: Farben, Typografie, Radius und Abstände stammen aus einem Design-Token-System (PDS). So gestaltet ein Operator die gesamte Oberfläche um, indem er Tokens ändert, statt die App zu forken. Dieselbe Plattform lässt sich in sehr unterschiedliche Richtungen lenken – eine Consumer-Neobank, eine Acquiring-App für Händler, ein Kartenausgabeprogramm, eine Krypto-On-/Off-Ramp oder ein internes Operations-Tool –, ohne zu fünf getrennten Produkten zu werden. Es ist eine Plattform in verschiedenen Skins, jede konfiguriert statt neu gebaut.
- 01Whitelabel-Clients für Web und Mobile auf gemeinsamen APIs
- 02Token-basiertes Theming (PDS): per Konfiguration umgestalten, nicht forken
- 03Fünf Beispielrichtungen – Neobank, Acquiring, Issuing, Ramp, Ops
- 04Neue Oberflächen werden konfiguriert, nicht neu gebaut
Betrieb
Steuern Sie alles aus der Konsole – mit dokumentiertem Grund.
Hinter jeder App steht eine Operator-Konsole. Dort schlägt ein Support-Mitarbeiter ein Konto nach, sperrt ein Risikoanalyst eine Karte oder storniert ein Operations-Lead eine Buchung. Lesezugriff ist breit, privilegierte Aktionen sind es nicht. Alles, was Geld bewegt, Limits ändert oder die Gelder eines Kunden berührt, erfordert vor der Ausführung eine angegebene Begründung und erzeugt einen unveränderlichen Audit-Eintrag: wer, woran, wann und warum. Der Zugriff folgt dem Least-Privilege-Prinzip, sodass jeder Operator nur sieht und tut, was seine Rolle erlaubt. So funktioniert es in Protocore Center, der Operator-Konsole, und dieselbe Haltung steckt in jedem System der Plattform: Sensible Aktionen sind bewusst, zurechenbar und im Nachhinein prüfbar.
- 01Breiter Lesezugriff, geschützter Schreibzugriff – privilegierte Aktionen sind die Ausnahme
- 02Begründungspflicht vor jeder Aktion, die Gelder berührt
- 03Unveränderlicher Audit-Trail: wer, was, wann, warum
- 04Least Privilege je Operator-Rolle
Die Krypto-Brücke
Krypto und Fiat im selben Ledger.
Krypto ist auf der Plattform kein separates Silo; eine Krypto-Adresse ist einfach ein weiteres Konto im selben Ledger. Eine On-/Off-Ramp wandelt am Rand zwischen Fiat und digitalen Assets um: Ein Kunde lädt seinen Saldo per Karte oder Überweisung auf und erhält Krypto, oder er verkauft Krypto und lässt sich den Betrag auf ein Bankkonto auszahlen. On-Chain-Werte können bis auf die Bankschiene durchsettelt werden: Eine eingehende On-Chain-Zahlung wird dem Konto gutgeschrieben, umgewandelt und auf eine IBAN ausgezahlt, sodass der Empfänger ganz normales Geld auf einem ganz normalen Bankkonto sieht. Weil beide Seiten in ein Double-Entry-Ledger gebucht werden, ist ein Vorgang, der on-chain beginnt und als Banküberweisung endet, eine einzige abgestimmte Historie – nicht zwei Systeme, die von Hand abgeglichen werden.
- 01Eine Krypto-Adresse ist ein Konto wie jedes andere
- 02On-/Off-Ramp: Fiat und digitale Assets werden am Rand umgewandelt
- 03On-Chain-Settlement bis zur Auszahlung auf eine IBAN
- 04Eine abgestimmte Historie über beide Seiten
Die Build-Oberfläche
APIs, Webhooks und eine Sandbox zum Entwickeln.
Alles, was die Apps tun, läuft über eine dokumentierte API – Konto anlegen, Zahlung eröffnen, Karte ausgeben, Ramp starten. Beispielhafte Aufrufe sehen so aus: POST /v1/wallets oder POST /v1/payments; die Form ist REST mit einem Idempotency-Key bei jedem Schreibzugriff. Statusänderungen werden als Webhooks zugestellt, sodass Ihre Systeme auf Ereignisse reagieren, statt sie abzufragen. Entwickelt wird gegen einen Sandbox-Tenant – eine isolierte Kopie der Plattform mit Test-Rails, in der Sie den gesamten Ablauf von Create bis Reconcile durchspielen können, ohne echtes Geld zu bewegen. Was jedes Produkt Ihnen in welcher Stufe bereitstellt, legt sein Access Band fest; die Produktseiten erläutern, was eine Stufe jeweils umfasst.
- 01Dokumentierte REST-API, idempotente Schreibzugriffe
- 02Webhooks für jede Statusänderung – ereignisgesteuert, kein Polling
- 03Sandbox-Tenant mit Test-Rails, isoliert von der Produktion
- 04Umfang und Limits durch Access Bands je Produkt
Die ehrliche Grenze
Protocore baut die Software. Die Lizenz verantwortet den regulierten Teil.
Ein Zahlungsprodukt besteht aus zwei untrennbaren Teilen: der regulatorischen Erlaubnis, Geld zu halten und zu bewegen, und der Software, die es anweist, verbucht und abstimmt. Protocore baut die Software. Die regulierte Tätigkeit – Kundengelder halten, Konten ausgeben, Geld über ein Scheme bewegen – liegt bei der eigenen Lizenz des Operators oder bei einem lizenzierten Partner: einer Bank, einem E-Geld-Institut (EMI) oder einem Zahlungsinstitut. Die Plattform ist darauf ausgelegt, sich in die regulierten Rails einzufügen, die Sie mitbringen, und Kartendaten auf der Rail zu halten, sodass sie nie Ihre Server berühren. Sie ersetzt diese Erlaubnis nicht, und keine Software tut das. Wo die regulierte Grenze verläuft, entscheiden Sie gemeinsam mit Ihrem Partner, und die Architektur ist so gebaut, dass sie auf jeder Seite davon sauber aufsetzt.
- 01Eine Softwareschicht, keine Lizenz
- 02Regulierte Tätigkeit liegt beim Operator oder einem lizenzierten Partner
- 03Kartendaten bleiben auf der Rail, nicht auf Ihren Servern
- 04Gebaut für die regulierten Rails, die Sie mitbringen
Wo es weitergeht
Folgen Sie dem roten Faden weiter.
Jedes Konzept auf dieser Seite hat eine ausführlichere Heimat – die Definitionen, die Produkte und die Access Bands, die festlegen, was eine Stufe umfasst.
Idempotenz, Webhooks, Settlement, virtuelle IBAN, SCA – definiert.
Der Service, der Authorize und Capture ausführt.
Privilegierte Aktionen mit Begründungspflicht und Audit.
On-Chain-Werte, durchgesettelt bis auf eine IBAN.
Fiat und digitale Assets, am Rand umgewandelt.
Was jedes Produkt umfasst, Stufe für Stufe.
Sie möchten die Architektur für Ihr Vorhaben?
Erzählen Sie uns, was Sie bauen. Wir melden uns mit einem Systementwurf und der Lage der regulierten Grenze – nicht mit einem Pitchdeck.