Der Kunde

Ein britisches Fintech-Unternehmen hat Elinext beauftragt, eine Webanwendung zur Verwaltung von Bargeld und Liquidität zu entwickeln.

Herausforderungen

Im Jahr 2019, kurz vor dem Brexit, bereiteten sich Banken auf Störungen im Betrieb vor. Einige ihrer Kunden würden Zahlungen einstellen, um ihre Schulden neu zu organisieren, und das würde eine Kettenreaktion auslösen. Als Folge könnten die Banken selbst riskieren, ihren finanziellen Verpflichtungen gegenüber anderen Kunden nicht nachkommen zu können.

Ein britisches Fintech-Unternehmen hatte die Vision, ein Tool zu entwickeln, mit dem berechnet werden kann, ob eine Bank ihre Verpflichtungen erfüllen kann, falls ein Kunde ab dem Handelsschluss keine Zahlungen mehr leistet. Das Unternehmen hatte zuvor mit Elinext zusammengearbeitet und wusste, dass wir Erfahrung im Bereich Fintech haben.

Der Prozess

Der Kunde hat uns nur hochrangige Dokumentation mit rein finanziellen Spezifikationen zur Verfügung gestellt. Unsere Business-Analysten haben mit den Experten des Kunden zusammengearbeitet, um diese in technische Spezifikationen zu übersetzen, die von den Entwicklern verwendet werden können.

In der Zwischenzeit haben unser DevOps-Ingenieur und unsere Entwickler begonnen, die Entwicklungsumgebung und das Gerüst des zukünftigen Produkts vorzubereiten. Sobald die Technologie bereit war und die Spezifikationen geklärt waren, konnte die Entwicklung beginnen. Innerhalb eines Monats haben wir ein Minimum Viable Product (MVP) entwickelt.

Der erste Abschnitt musste innerhalb von sechs Monaten abgeschlossen sein. Die erste Onsite-Fintech-Konferenz nach dem Lockdown stand bevor und unser Kunde plante, das Produkt zu diesem Zeitpunkt zu präsentieren. Obwohl der Brexit abgeschlossen war, war eine Lösung wie die von uns beauftragte noch immer sehr gefragt.

Wir haben erfolgreich eine stabile, voll funktionsfähige Version des Produkts vor der Konferenz geliefert. Die nächsten drei Monate wurden damit verbracht, die Anwendung zu verbessern und zu optimieren.

Das Produkt

Das von uns entwickelte System ermöglicht es Banken und anderen Finanzorganisationen, die kurzfristigen Finanzierungsanforderungen auf der Grundlage von Transaktionshistorien zu verwalten und zu überwachen - von der höchsten Ebene bis hin zu einzelnen Transaktionen.

Zunächst können die Organisationen, die die Anwendung nutzen, ihre isolierten Infrastrukturen konsolidieren und Transaktionen aus jeder internen oder externen Quelle erfassen. Als Ergebnis entsteht eine einzige globale Sicht auf Bilanzen in allen Währungen und Konten.

Darüber hinaus dauert es nur wenige Minuten, um innerhalb des Systems ein umfassendes Stressszenario durchzuführen.

Das ultimative Ergebnis sind hochpräzise Analysen, die fundierte Entscheidungen ermöglichen und eine effektivere Erfüllung der Anforderungen an die Intraday-Liquiditätsberichterstattung ermöglichen. Die Lösung hilft Banken auch dabei, den BCBS 248 Intraday Liquiditätsmanagement-Rahmen zu erfüllen, der von verschiedenen Regulierungsbehörden weltweit implementiert wurde.

Bereitstellung

Um die GUI zu implementieren, haben wir Kubernetes mit Microservices und Angular kombiniert. Die auf Microservices basierende Architektur wurde gewählt, weil sie dem System eine hohe Fehlertoleranz ermöglicht - die oberste Priorität unseres Kunden.

Darüber hinaus verarbeitet das System viele Berechnungen und große Datenmengen, was eine automatische Skalierung erfordert. Kubernetes ist dafür gut geeignet.

Für die Überwachung des Systemzustands, das Alert-Management und die Erfassung von Traceability-Metriken haben wir das Open-Source-Überwachungssystem Prometheus eingerichtet. Unser Team hat es mit Hilfe des offiziellen Support-Teams von Grafana konfiguriert.

Microservices

Das System läuft auf sieben Microservices:

1. Die Speicherung statischer Bankdaten wie BIC, Konten, Währungen usw. wurde durch PostgreSQL ermöglicht.
2. Die Speicherung dynamischer Daten wie Transaktionen und Devisenkursen wurde durch MongoDB ermöglicht.
3. Berechnungen basierend auf Algorithmen und Operationen mit statischen und dynamischen Daten.
4. Der Import von dynamischen und statischen Daten.
5. Sicherheitsmapping für Benutzer (die Zugriff auf jedes Element haben).
6. Benutzerdefinierter oAuth2-Identitätsanbieter.
7. Die Reporter-Funktion zur Bereitstellung und Vergleich von Daten vor und nach den Berechnungen.

Die Microservices werden mithilfe von Redis untereinander synchronisiert. Dieselbe Technologie ist auch für den lokalen Cache verantwortlich.

Ergebnisse

Wir haben das Projekt termingerecht und innerhalb des festgelegten Budgets abgeschlossen. Bis zu 75 Banken und andere Finanzorganisationen verarbeiten täglich rund fünf Millionen Elemente innerhalb des Systems.