Lösungen · Finanzdienstleistungen
Eine Anwendung für Finanzdienstleistungen wird daran gemessen, was an ihren Rändern passiert: was im Journal eingetragen wird, was geschieht, wenn der Kunde seine Daten zurückverlangt, was aus der vorvertraglichen Information sichtbar ist und was passiert, wenn eine geplante Aufgabe nicht ausgeführt wird. Wir bauen die Mechanik; die Kreditpolitik bleibt Ihre.
Bereits gebautEine in Produktion befindliche Kreditplattform, von außen heute überprüfbar: Der öffentliche Teil ist eine statisch kompilierte Anwendung mit 50 Bildschirmen, darunter vier Rechner — Kredit, Eignung, Refinanzierung, Zahlungsplan — Seiten nach Kredittyp, vorvertragliche Information und eine Route, über die der Kunde seine personenbezogenen Daten anfordert; der Business-Teil ist ein modularer Backend in TypeScript mit 16 Modulen und 18 Tabellen im Datenschema, darunter Vertrag, Zahlung, Audit-Log, Anfrage zu personenbezogenen Daten, hochgeladenes Dokument, täglicher Kennzahlen-Schnappschuss und Ausführung geplanter Aufgaben. Die Sitemap in der Produktion listet 227 Adressen auf, und die rumänischen wie auch die russischen Routen antworten beide — von mir am 06.09.2026 geprüft. Die von uns genannte Einschränkung: Der Beleg stammt aus dem Code und den öffentlichen Antworten, nicht aus dem internen Verhalten des Servers — ich habe nicht geprüft, auf welcher Version die Produktion läuft, und auch nicht, ob alle 16 Module live aktiv sind.
Ein Kreditunternehmen braucht keine Website. Es braucht eine vollständige Kette: Der Antrag geht online ein, durchläuft einen Entscheidungsfluss, erzeugt einen Vertrag, erstellt einen Zahlungsplan und hinterlässt eine Spur im Audit. Jedes fehlende Glied in der Kette wird zu einem Menschen, der Daten von einem Ort an einen anderen kopiert, und im Finanzdienstleistungsbereich ist jede manuelle Kopie nicht nur ein Zeitproblem, sondern auch ein Compliance-Problem.
Die Struktur, die wir bauen, spiegelt das direkt in den Daten wider. Auf der Plattform, auf die wir verweisen, umfasst das Schema 18 Tabellen, und ihre Liste sagt mehr als jede Architekturbeschreibung: Antrag, Vertrag, Zahlung, Einmalcode, Sitzung, Rückrufanfrage, Benachrichtigungsvorlage, Benachrichtigungsprotokoll, täglicher Kennzahlen-Snapshot, Ausführung einer geplanten Aufgabe, Artikel, Adressweiterleitung, Sichtbarkeitseinstellung, interne Notiz, Audit-Log, hochgeladenes Dokument, Antrag zu personenbezogenen Daten. Das Backend ist in 16 Module aufgeteilt, darunter eines, das ausschließlich den Rechten der betroffenen Person gewidmet ist.
Der öffentliche Teil ist kein Dekor: vier Rechner — Kredit, Eignung, Refinanzierung und Zahlungsplan — plus separate Seiten nach Kreditart und die vorvertragliche Information. In der Verbraucherkreditvergabe ist die vorvertragliche Information keine Image-Seite: Es ist die Pflicht, die Bedingungen darzustellen, bevor sich der Mensch bindet. Wir behandeln sie als Produktanforderung, nicht als juristischen Text, der am Ende angehängt ist. Die rumänischen Routen bleiben ohne Präfix, und die russischen laufen über ein eigenes Segment, mit kanonischen Labels und Alternativen, die aus der Sprache der aktiven Route generiert werden.
Und die Grenze, die vor dem Vertrag gesagt werden muss: Der Entscheidungsfluss über Anträge — Regeln, Schwellenwerte, Genehmigung — ist Ihrer. Wir bauen die Mechanik, durch die der Antrag zirkuliert, dokumentiert wird und zum Vertrag wird. Wir schreiben nicht die Kreditpolitik und übernehmen nicht die Bewertung eines Antragstellers; das sind Entscheidungen mit rechtlichen Folgen, die der autorisierten Institution gehören.
Was dazugehört
Der Antrag geht online ein und lebt als eigene Entität, mit sichtbarem Status und einem Nachverfolgungsbildschirm für den Kunden. Hochgeladene Dokumente haben ihre eigene Tabelle, der Vertrag seine eigene, die Zahlung ebenfalls. Der Unterschied zu einem Formular, das eine E-Mail sendet, ist, dass man nach drei Monaten aus den Daten die Frage beantworten kann: „Was ist mit dem Antrag vom 12. März passiert“.
Vertrag und Plan werden nicht manuell in einem separaten Dokument zusammengesetzt: Sie entstehen aus den Daten des genehmigten Antrags. Das ist die einzige Variante, in der die Zahl im Vertrag und die Zahl im Plan nicht voneinander abweichen können, und der Kunde, der mit dem Dokument in der Hand anruft, spricht über dasselbe wie der Operator, der ins System schaut.
Kredit, Eignung, Refinanzierung und Zahlungsplan — separate, öffentliche Bildschirme ohne Authentifizierung. In der Verbraucherkreditvergabe ist der Rechner die erste echte Interaktion: Der Mensch will die Rate sehen, bevor er mit jemandem spricht. Und die Refinanzierung ist ein anderer Rechner als der Kreditrechner, nicht derselbe unter anderen Bezeichnungen.
Eigene Seite, nicht ein Absatz im Footer. Der Grund ist praktisch: Wenn die Information nicht auf dem Weg liegt, den der Mensch vor der Unterzeichnung geht, erfüllt sie weder für ihn noch für die Institution ihren Zweck. Der Text gehört Ihnen und Ihren Juristen; wir bauen den Ort, den Zeitpunkt und die Nachvollziehbarkeit.
Es gibt eine öffentliche Seite, über die der Kunde seine personenbezogenen Daten anfordert, ein spezielles Backend-Modul und einen Verwaltungsbildschirm für die eingegangenen Anfragen sowie eine Tabelle, in der sie leben. Die praktische Folge: Die gesetzliche Antwortfrist kann eingehalten werden, ohne dass jemand die Datenbank manuell öffnen muss — und es kann nach einem Jahr nachgewiesen werden, dass sie eingehalten wurde.
Das Audit-Log ist eine eigene Tabelle, getrennt von den internen Notizen der Betreiber. Die Trennung zählt bei einer Prüfung: Das eine ist die technische Aufzeichnung dessen, was passiert ist, das andere ist, was ein Kollege zu einer Akte geschrieben hat. Vermischt wird das erste unlesbar und das zweite zum Dokument.
Es gibt eine Tabelle für die Ausführungen der geplanten Aufgaben und eine für die täglichen Kennzahlen-Snapshots. Auf einer Finanzplattform ist eine Aufgabe, die drei Nächte hintereinander nicht gelaufen ist, ein schwerwiegenderes Problem als eine ausgefallene Seite: Von außen ist es nicht sichtbar, aber es verschiebt die Zahlen. Deshalb wird die Ausführung geschrieben und nicht angenommen.
Die rumänischen Routen bleiben ohne Präfix, die russischen laufen über einen eigenen Abschnitt, mit kanonischen und aus der Sprache der aktiven Route generierten Alternativbezeichnungen. In der auf Produktion befindlichen Sitemap gibt es 227 Adressen. Für ein Kreditunternehmen in der Republik Moldau ist der russische Teil keine Höflichkeitsübersetzung — er betrifft die Hälfte der Antragsteller.
Vorabprüfungen vor der Veröffentlichung, mit separatem Befehl in Produktion ausgeführte Datenbankmigrationen, Generierung von Secrets, Sicherungskopie und Wiederherstellung der Datenbank — alles als Skripte im Repository, nicht als Schritte in einem Dokument. In einem System, das Verträge und Zahlungen verwaltet, muss „Wiederherstellung“ ein Befehl sein, den Sie ausprobiert haben, nicht eine Absicht.
Traseul
Was eine eingereichte Anfrage, eine genehmigte Anfrage, eine eingegangene Zahlung bedeutet; was mit einer Anfrage geschieht, auf die nicht geantwortet wurde; was geschlossen ausfällt, wenn ein externer Dienst nicht antwortet. Wir liefern das Dokument mit dem Vokabular und den Invarianten, weil in einer Finanzplattform ein Begriff, der in zwei Bedeutungen verwendet wird, später zwei verschiedene Zahlen in zwei Berichten ergibt.
Das Audit-Log und die Dokumentenverwaltung werden nicht am Ende hinzugefügt; sie sind Teil der ersten funktionierenden Version. Wir liefern den vollständigen Ablauf von der Anfrage bis zum Vertrag, mit seiner Nachverfolgbarkeit, auf Testdaten — nicht Bildschirme, die über einer leeren Datenbank gut aussehen.
Die öffentlichen Bildschirme, die Rechner, die Seiten nach Kreditart und die vorvertragliche Information, mit den rumänischen Adressen ohne Präfix und den russischen auf einem eigenen Abschnitt, mit korrekten kanonischen Bezeichnungen. Wir liefern die aus Daten generierte Sitemap und die Prüfung, dass beide Versionen antworten.
Vorabprüfung vor der Veröffentlichung, Migrationen in Produktion mit separatem Befehl, Generierung von Secrets, Sicherungskopie und Wiederherstellung — geprüft, nicht nur geschrieben. Wir übergeben das Repository, das Inbetriebnahmedokument und die Zugänge. Die Wiederherstellung der Datenbank wird bei der Übergabe einmal vor Ihnen demonstriert.
Die Daten
Die Regeln unterscheiden sich von einer Branche zur anderen. Dies sind die, die im Finanzdienstleistungsbereich gelten.
Ein Fall
Die Ausgangslage
Die ursprüngliche Anforderung in einem Kreditprojekt klingt fast immer gleich: „eine Website mit Antragsformular”. Das Problem entsteht im zweiten Monat, wenn jemand fragt, wo der Vertrag ist, wer die Akte geändert hat und wie wir auf einen Antrag auf Zugang zu personenbezogenen Daten innerhalb der gesetzlichen Frist antworten.
Was wir gebaut haben
Wir haben die Plattform in zwei Hälften gebaut, im selben Repository. Der öffentliche Teil ist eine statisch kompilierte Anwendung mit 50 Bildschirmen: vier Rechner — Kredit, Eignung, Refinanzierung, Zahlungsplan — Seiten nach Kreditart, vorvertragliche Information, Verfolgung des Antragsstatus und eine Seite, über die der Kunde seine personenbezogenen Daten anfordert. Der Geschäftsteil ist ein modulares Backend in TypeScript, mit 16 Modulen — darunter Authentifizierung, Rollenrechte, der Antragsfluss, Dokumente, Zahlungen, Benachrichtigungen, geplante Aufgaben und eines für die Rechte der betroffenen Person — über einem Schema mit 18 Tabellen: Antrag, Vertrag, Zahlung, Einmalcode, Sitzung, hochgeladenes Dokument, Audit-Protokoll, Antrag zu personenbezogenen Daten, Lauf einer geplanten Aufgabe, täglicher Kennzahlen-Snapshot und der Rest.
Was dabei herauskam
Die Kette ist vollständig: Der Antrag kommt herein, durchläuft den Prozess, erzeugt Vertrag und Zahlungsplan, und jeder Schritt hinterlässt eine Spur. Anträge zu personenbezogenen Daten haben ihren eigenen Ablauf, mit Administrationsbildschirm, sodass die gesetzliche Frist eingehalten und nachgewiesen werden kann. Der öffentliche Teil ist von außen prüfbar: 227 Adressen in der Sitemap, mit beiden lebenden Sprachversionen.
Was der Fall nicht sagt
Der Nachweis stammt aus dem Code und den öffentlichen Antworten, nicht aus dem internen Verhalten des Servers: Wir haben nicht geprüft, auf welcher Version die Produktion läuft, und auch nicht, dass alle 16 Module live aktiv sind. Der Entscheidungsfluss über Anträge — Regeln, Schwellenwerte, Genehmigung — gehört dem Kunden; wir haben die Mechanik gebaut, nicht die Kreditpolitik.
Fragen
Sie. Die Regeln, Schwellenwerte und die Genehmigung sind die Politik der autorisierten Institution, nicht des Softwareanbieters. Wir bauen die Mechanik, durch die der Antrag zirkuliert, dokumentiert wird, zum Vertrag und Zahlungsplan wird und eine Spur hinterlässt. Ein Anbieter, der die Kreditentscheidung an sich nimmt, verkauft etwas, das er nicht verkaufen darf.
Es gibt eine öffentliche Seite, über die er es verlangt, ein eigenes Backend-Modul, einen Administrationsbildschirm und eine Tabelle, in der der Antrag lebt. Also kann fristgerecht geantwortet und später nachgewiesen werden. Was keine technische Entscheidung ist: was gelöscht werden kann und was gemäß der Finanzgesetzgebung aufbewahrt werden muss — das wird vor der Implementierung mit Ihren Juristen festgelegt.
Aus den Daten des genehmigten Antrags, zusammen mit dem Zahlungsplan — beide aus derselben Quelle, damit sie nicht voneinander abweichen können. Was bei Ihnen bleibt, ist der Inhalt des Vertrags und seine Bedingungen. Ein manuell in einem separaten Dokument erstellter Vertrag ist der klassische Ort, an dem zwei verschiedene Zahlen für denselben Kredit auftauchen.
Weil bei Verbraucherkrediten die Informationen auf dem Weg bereitgestellt werden müssen, den der Kunde vor der Bindung durchläuft, nicht in einer Fußzeile. Wir behandeln sie als Teil des Produkts: Ort, Zeitpunkt und Nachverfolgbarkeit liegen bei uns, der Text bei Ihren Juristen.
Mindestens so viele, wie unterschiedlichen Entscheidungen entsprechen. Auf der von uns zitierten Plattform sind es vier — Kredit, Eignung, Refinanzierung, Zahlungsplan — weil Refinanzierung nicht dieselbe Berechnung ist wie ein neuer Kredit und der Zahlungsplan eine andere Frage beantwortet als die Rate. Ein einziger Rechner mit vielen Feldern ist schwerer zu nutzen als vier einfache.
Nein, und das ist eine Regel, keine Präferenz: Wir bauen und testen mit Testdaten. Der Zugriff auf echte Daten erfolgt, wenn nötig, mit benannten Personen, für einen festgelegten Zeitraum und mit Protokollspur. In einem Finanzsystem ist „ich musste in die Produktion schauen“ ein Satz, der in einem Protokoll erscheinen muss, nicht in einer Diskussion.
Man sieht es, weil die Läufe in eine eigene Tabelle geschrieben werden, neben den täglichen Momentaufnahmen der Kennzahlen. Das ist gerade deshalb wichtig, weil eine Aufgabe, die nicht gelaufen ist, nach außen kein sichtbares Symptom erzeugt — die Website antwortet, die Bildschirme sehen gut aus, aber die Zahlen bewegen sich nicht mehr.
Keine Volumenzahl, keinen Zinssatz, keine Anzahl von Anträgen oder Kunden, selbst wenn sie öffentlich auf seiner Website angezeigt wird — weil es seine Behauptung ist, nicht unsere Messung. Was wir zeigen können, ist die Struktur: wie viele Module, welche Tabellen, welche öffentlichen Bildschirme, was vor der Veröffentlichung geprüft wird. Dieselbe Regel gilt auch für Ihre Arbeit.
Der öffentliche Teil kann jetzt überprüft werden: Die Sitemap hat 227 Adressen, und die rumänische und russische Version eines Rechners antworten beide. Der Backend-Teil wird aus dem Code gelesen — Module und Datenschema — nicht aus dem Verhalten des Servers: Wir haben nicht geprüft, auf welcher Version die Produktion läuft, und auch nicht, dass alle Module im Live-Betrieb aktiv sind, und wir schreiben das lieber, als den gegenteiligen Eindruck zu lassen.
Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.