FinTech ist eine der wenigen Branchen, in denen »produktionsreif« eine rechtliche Definition hat. Wir bauen Payment-, Lending- und Risk-Plattformen für finanzierte Startups und lizenzierte Finanzinstitute — Backends, in denen jede Transaktion einen Trail hat, jede Integration einen Fallback und jede Compliance-Frage eine saubere Antwort. Architecture-first, EU-gehostet per Default, ausgelegt auf BaFin- und PSP-Due-Diligence — nicht auf hektische Reviews zwei Wochen vor Go-Live.
Die meisten FinTech-Projekte beginnen an einem von zwei Punkten: vor dem ersten regulierten Launch — wenn eine Demo-Integration auf echte Compliance trifft — oder 12–18 Monate später, wenn die Architektur keine neuen Partner, Produkte oder Regulatoren mehr aufnimmt. Beide Momente brauchen dasselbe: ein Backend, das aufhört, der limitierende Faktor zu sein.
Payment-Flows mit Tokenisierung, idempotenten Retries, Reconciliation und sauberen PSP-Grenzen (Stripe, Adyen, Mollie, Computop). Wir bauen Zahlungssysteme, in denen der Geldzustand explizit modelliert wird — nicht aus Side-Effects abgeleitet — und in denen ein PCI-DSS-Scope-Review Stunden dauert, keine Wochen.
Backends für Origination, Entscheidung und Servicing von Krediten. Risk-Pipelines, Score-Integration, KYC/KYB-Orchestrierung, Ratenpläne, Restrukturierungs-Flows. Ausgelegt auf Multi-Produkt-Lending-Portfolios ab Tag eins, nicht erst nach dem ersten Refactor.
Interne Tools für AML, Transaktionsmonitoring, Sanktions-Screening und Audit-Reporting. Event-sourced, wo es zählt, abfragbar für Aufsicht — designed für Audit-Queries ohne Engineering-Beteiligung.
B2B-FinTech-APIs und produktionsreife Partner-Integrationen: Account-as-a-Service, Karten-Programme, BaaS-Partner-Orchestrierung. Versioniert, rate-limitiert, durchgängig observierbar, mit einer Sandbox, die Produktions-Semantik widerspiegelt.
Fünf Muster, die wir in regulierten Backends immer wieder sehen — jedes überlebt den ersten Launch und taucht im ersten Audit, der ersten PSP-Integration oder dem ersten Refund-Zyklus auf.
Zustandsänderungen passieren als Nebeneffekt von HTTP-Calls statt als explizite Transitions. Reconciliation scheitert leise — die Lücke zeigt sich, wenn das PSP-Statement nicht passt.
Es gibt keine kanonische Antwort auf »Wie sieht diese Transaktion gerade aus?«. Jedes Audit wird zu manueller Rekonstruktion aus Logs.
AML, KYC und Reporting werden um bestehende Datenflüsse gewickelt, statt in sie hineindesignt. Datenherkunft ist nicht erklärbar — und die Aufsicht merkt es.
PSP-, KYC- und Core-Banking-Partner teilen sich State mit dem Produkt. Ein Partnerausfall kaskadiert in Refund-, Billing- und Onboarding-Fehler gleichzeitig.
Retries duplizieren Transaktionen, Refunds und Webhook-Processing. Der Bug zeigt sich unter Last, in Produktion, an dem Tag, an dem die Aufsicht im Raum sitzt.
Finanzierte EU-FinTech-Startups (pre-licence, E-Money, Zahlungsinstitute, BaFin-beaufsichtigt), Embedded-Finance-Teams in SaaS-Unternehmen, Banken in Modernisierungs-Tracks. Teams, in denen Compliance-Anforderungen Produktentscheidungen prägen — und nicht nachträglich folgen.
Default-Antwort: nein. Wir entwerfen Payment-Flows mit Tokenisierung und PSP-gehosteten Feldern, sodass Karteninhaberdaten unsere Systeme nie berühren. Der PCI-DSS-Scope wird auf das Minimum reduziert (typischerweise SAQ A oder A-EP). Wenn ein Use-Case PAN-Speicherung wirklich erfordert, behandeln wir das als isoliertes Subsystem mit eigenem Threat-Modell und eigener Zertifizierung.
Wir integrieren KYC/KYB-Provider (IDnow, Onfido, Veriff, Sumsub) über ein einheitliches Compliance-Gateway, sodass der Rest des Systems nicht von einem Anbieter abhängt. AML-Regeln und Reporting sind first-class Domain-Logik mit Audit Trail, Versionierung und Replay-Fähigkeit — kein Feature-Flag.
Append-only Event-Logs für zustandsverändernde Geld-Operationen, ergänzt durch aggregierte Read-Models für die UX. Wir machen nicht alles event-sourced — nur die Teile, in denen Reconciliation, Aufsicht oder Dispute-Handling eine vollständige Historie verlangen. Die Grenze ist eine Architektur-Entscheidung im Sprint, kein Default.
Beides. Wir haben für pre-licence-Teams, E-Money-Institute, Zahlungsinstitute und Partner regulierter Banken (Solaris, Banking Circle u. a.) geliefert. Die Engineering-Tiefe ist dieselbe; was sich ändert, ist die Compliance-Kopplung und wann die Aufsicht ins Gespräch einsteigt.
Nach dem 5-tägigen Architecture Sprint liegt das erste regulatorisch lieferfähige Release bei 4–6 Monaten für ein fokussiertes Produkt (Payment oder Lending), 8–12 Monaten für eine Multi-Produkt-Plattform. Wir vermeiden »Big-Bang«-Launches bewusst — phasenweise Releases halten Audit Trails sauber und entlasten das erste Aufsichtsgespräch.
Auditierbarkeit ist eine strukturelle Eigenschaft, kein nachträgliches Feature. Wir modellieren den Geldzustand als explizite Transitions (nicht als Side-Effects), führen append-only Event-Logs für zustandsverändernde Operationen, trennen Read-Models von Writes und taggen jeden Record mit Akteur, Quelle und Grund. Resultat: eine Audit-Anfrage — intern oder von der Aufsicht — ist ein Datenbank-Read, keine Forensik über Logs und Screenshots.
Fünf Tage. €3.500. Wir kartieren Ihre bestehenden Systeme, benennen Compliance- und Skalierungsrisiken, und liefern eine Architektur-Roadmap, die Ihr Team — oder unseres — umsetzt.
