Fintech und Finanzdienstleistungen
Banking, Zahlungen und Hauptbücher verbunden für Echtzeitgenauigkeit und regulatorische Prüfung.
Warum Finanzprodukte an den Verbindungen scheitern
Ein Finanzprodukt ist selten ein einziges System. Es besteht aus einem Kernhauptbuch, Kartenverarbeitung, Identitätsprüfungen, Betrugscreening, Zahlungssystemen und einem ERP dahinter. Das Schwierige sind die Verbindungen dazwischen und das, was geschieht, wenn eine davon ausfällt. Wir entwerfen diese Verbindungen zuerst und schreiben den Fehlerpfad auf.
Harte regulatorische Fristen
Pflichten zur elektronischen Rechnungsstellung wie Saudi ZATCA Phase 2 und UAE PINT-AE sowie Resilienzregeln wie DORA kommen zu festen Terminen.
Daten, die nicht hinausdürfen
Regulierte Banken können Kunden- oder Finanzdaten nicht an öffentliche KI-Dienste im Ausland senden.
Manuelle Abstimmung
Batch-Dateien und Tabellen stehen noch immer zwischen Banken, Prozessoren und dem ERP.
Was sich ändert
Echtzeitgenauigkeit im Hauptbuch
Jede Buchung, Gebühr und Abwicklung automatisch abgestimmt, mit Ausnahmen an Menschen weitergeleitet.
Bereit für regulatorische Prüfungen
Zugriff begrenzt und protokolliert, jede Änderung nachvollziehbar, schon vor der Inbetriebnahme.
Souveräne KI
Dokumenten-KI und Assistenten, die in Ihrer eigenen Umgebung laufen und keine Daten hinausgeben.
Unser Leitkompetenzbereich
Fintech ist unsere Leitbranche. Wir bauen und integrieren die Software, auf der Banken, Zahlungsunternehmen, Kreditgeber, Vermögensverwalter, Versicherer und Wallet-Anbieter arbeiten, und wir kennen die Standards dieser Systeme: ISO 20022, ISO 8583, EMV, Open-Banking-APIs und die Dateiformate, auf die Banken noch immer angewiesen sind.
Wir entwickeln für regulierte Umgebungen. Zugriff ist begrenzt und protokolliert, sensible Daten bleiben außerhalb von Orten, an die sie nicht müssen, und jede Änderung ist nachvollziehbar. Ihre Compliance- und Risikoteams sehen vor der Inbetriebnahme, wie das System funktioniert, nicht danach.
Wo wir arbeiten
Was wir bauen
- Digital-Banking-Apps und -Portale für Privat- und Geschäftskunden
- Dienste, die das Kernbankensystem über APIs umhüllen und erweitern, statt es zu ersetzen
- Firmenkundenkanäle für Zahlungsdateien, Freigaben, Kontoauszüge und Liquiditätspositionen
- Backoffice-Werkzeuge für Betrieb, Zahlungsnachforschungen und Kundenbetreuung
- Technologie für islamische Finanzierung und Erweiterungen des Kernhauptbuchs
Typische Integrationen
- Kernbankensysteme über ihre APIs, Message Queues oder Batch-Schnittstellen
Was wir bauen
- Zahlungsorchestrierung, die jede Transaktion an das richtige Gateway, den richtigen Acquirer oder Zahlungsweg leitet
- Händler-Onboarding, Portale und Berichterstattung
- Abwicklungs-, Gebührenberechnungs- und Auszahlungsdienste
- Abstimmung, die Transaktionen, Abwicklungen und Kontoauszüge zuordnet
Was wir bauen
- Kreditoriginierung: Anträge, Dokumentenerfassung und Entscheidungsprozesse
- Kreditentscheidung mit Regeln und erklärbaren Modellen, die Kreditteams prüfen können
- Kreditbetreuung: Tilgungspläne, Raten, Rückstände und Inkasso
- Makler- und Partnerportale
Typische Integrationen
- Kreditauskunfteien, Open-Banking-Kontodaten und Identitätsprüfung
- Core-Banking- oder Kredithauptbücher und Ratenzahlung per Lastschrift oder Karte
Was wir bauen
- Kundenportale und -Apps mit Portfolios, Transaktionen und Dokumenten
- Portfolio- und Kundenberichte aus Depotbank- und Marktdaten
- Onboarding mit Fragebögen zu Geeignetheit und Risikoprofil
- Beraterwerkzeuge für Kundenreviews, Angebote und Rebalancing
Typische Integrationen
- Depotbanken, Makler und Marktdatenanbieter
- Portfoliomanagement- und CRM-Systeme
Was wir bauen
- Angebots- und Abschlussprozesse für Kunden und Makler
- Erweiterungen der Bestandsverwaltung für Produkte, Nachträge und Verlängerungen
- Schadenaufnahme mit Dokumenten-KI, Triage und Statusverfolgung
- Datenpipelines für Preisgestaltung und Risiko
Typische Integrationen
- Bestands- und Schadensysteme
- Prämieneinzug, Erstattungen und das Hauptbuch
Was wir bauen
- Wallet-Apps mit Aufladen, Überweisungen, Rechnungszahlung und Händlerzahlung
- Ein Wallet-Hauptbuch mit doppelter Buchführung und täglicher Abstimmung
- Kartenausgabe und tokenisierte Karten für mobile Zahlungen
- Limits, Gebühren und Loyalty-Regeln, die Betriebsteams selbst ändern können
Typische Integrationen
- Kartenausgabe-Prozessoren und Tokenisierungsdienste
Was wir bauen
- Große quantitative Modelle (LQM) für Finanzsimulationen
- Hochfrequenzhandelssysteme (HFT)
- Echtzeit-Erkennung von Betrug, Geldwäsche und Verhaltensanomalien
Typische Integrationen
- Marktdatenanbieter und Handelsplätze
Was wir bauen, verbinden und absichern
Digitale Kanäle
Web- und Mobile-Banking, Wallet- und Investment-Apps, für Kunden gestaltet und für die Last von Zahltagen und Monatsenden gebaut.
Kernerweiterungen
Dienste um das Kernbanken- oder Hauptbuchsystem, die Produkte und Kanäle ergänzen, ohne es riskant zu ersetzen.
Zahlungsorchestrierung
Routing, Wiederholungen und Failover über Gateways, Acquirer und Zahlungswege hinweg, mit jedem Versuch protokolliert.
Onboarding und KYC
Kunden- und Geschäftskunden-Onboarding mit Identitätsprüfungen, Screening und Dokumentenerfassung sowie einem klaren Weg zur manuellen Prüfung.
Betrugs- und Transaktionsüberwachung
Regeln und Modelle für maschinelles Lernen, die Transaktionen laufend bewerten und verdächtige für die Prüfung zurückhalten.
Abstimmung und Finanzen
Zuordnung über Hauptbücher, Prozessoren, Banken und das ERP hinweg, damit die Finanzabteilung mit Daten abschließt, denen sie vertraut.
Bankanbindung
Zahlungen und Kontoauszüge in ISO-20022- und MT-Formaten über Host-to-Host-Kanäle, EBICS oder Bank-APIs.
Kartenverarbeitung
Acquirer, Prozessoren und Kartenausgabeplattformen über ISO 8583 oder APIs, mit EMV-Terminals im Geschäft und 3-D Secure online.
Open Banking
Kontoinformationen und Zahlungsauslösung über regulierte Bank-APIs und Aggregatoren, mit ordnungsgemäß verwalteter Einwilligung.
Identität, KYC und AML
Identitätsprüfung, Sanktions- und PEP-Screening sowie Adverse-Media-Prüfungen, mit jedem Ergebnis für das Audit aufgezeichnet.
ERP und Hauptbuch
Buchungen, Gebühren und Abwicklungen ins ERP übernommen, damit die Finanzabteilung dieselben Zahlen sieht wie der Betrieb.
Kartendaten und PCI DSS
Wir gestalten so, dass Kartendaten nach Möglichkeit aus Ihren Systemen herausbleiben, durch Tokenisierung und gehostete Zahlungsfelder, was den PCI-DSS-Geltungsbereich verkleinert. Wo Kartendaten verarbeitet werden müssen, bauen wir nach den Kontrollen, die Ihr Prüfer testen wird.
Starke Kundenauthentifizierung
Wir bauen die Authentifizierungsabläufe, die Zahlungs- und Banking-Regeln verlangen, etwa Zwei-Faktor-Anmeldung und Transaktionssignierung, mit nur den Ausnahmen, die Ihr Risikoteam zulässt.
KYC- und AML-Kontrollen
Onboarding und Überwachung liefern die Nachweise, die Ihr Compliance-Team braucht: was geprüft wurde, wann, durch welchen Anbieter und wer entschieden hat.
Datenschutz
Wir vereinbaren vor Arbeitsbeginn, wo personenbezogene und finanzielle Daten gespeichert und verarbeitet werden dürfen, und gestalten nach DSGVO und lokalen Gesetzen wie dem UAE PDPL und dem Saudi PDPL, wo sie gelten.
Audit-Trails und Resilienz
Jede Änderung an Geld, Limits und Berechtigungen wird protokolliert und ist nachvollziehbar, und Systeme werden so gebaut, dass sie sicher ausfallen und sich erholen, wie es Resilienzregeln erwarten.
So arbeiten wir
Reifegrad prüfen
Ein Principal Engineer prüft Umfang, Systeme, Daten und regulatorische Anforderungen.
Verbindungen entwerfen
Die Integrationsschicht, ihre Fehlerpfade und ihr Audit-Trail werden zuerst entworfen.
Umsetzen und betreiben
Schrittweise Releases hinter Abnahmegates, dann gemanagter Betrieb unter vereinbarten Servicelevels.
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
Ein digitales Finanzprodukt von Anfang bis Ende
Eine Banking- oder Wallet-App spricht mit einer einzigen API-Schicht. Dahinter stehen Identitätsprüfungen, Kartenverarbeitung und das Kernhauptbuch. Transaktionen werden laufend geprüft, und alles Verdächtige wird für die Prüfung durch einen Menschen zurückgehalten.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 9 Schritten
Der Ablauf Schritt für Schritt
- Von Kunde nach Banking- oder Wallet-App: Registriert sich, zahlt und überweist (primärer Ablauf).
- Von Banking- oder Wallet-App nach API-Schicht: Anfragen, über REST/JSON · OAuth 2.0 (primärer Ablauf).
- Von API-Schicht nach KYC- und AML-Anbieter: Identitäts- und Screening-Prüfungen, über REST/JSON · webhook (primärer Ablauf).
- Von API-Schicht nach Core Banking oder Hauptbuch: Buchungen und Salden, über REST/JSON · ISO 20022 (primärer Ablauf).
- Von API-Schicht nach Kartenprozessor: Kartenausgabe und -steuerung, über REST/JSON (primärer Ablauf).
- Von Kartenprozessor nach Core Banking oder Hauptbuch: Kartentransaktionen, über ISO 8583 (asynchron).
- Von API-Schicht nach Betrugs- und Transaktionsüberwachung: Zu prüfende Transaktionen als Ereignisstrom (asynchron).
- Von Betrugs- und Transaktionsüberwachung nach Compliance- und Betriebsteam: Zur Prüfung zurückgehalten (Fehlerpfad).
- Von KYC- und AML-Anbieter nach Compliance- und Betriebsteam: Fehlgeschlagene oder unklare Prüfungen weitergeleitet (Fehlerpfad).
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
ERP zur Bank: Zahlungen hinaus, Kontoauszüge herein
Freigegebene Zahlungen verlassen das ERP als signierte ISO-20022-Dateien über einen host-to-host-Kanal. Statusberichte und Kontoauszüge kommen denselben Weg zurück und werden offenen Posten zugeordnet. Ablehnungen und nicht zugeordnete Zeilen gehen mit dem Grund an Ihr Team.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 10 Schritten
Der Ablauf Schritt für Schritt
- Von ERP nach Integrationsschicht: Freigegebener Zahlungslauf, über REST/JSON · IDoc (primärer Ablauf).
- Von Integrationsschicht nach Sicherer Bankkanal: Signierte und verschlüsselte Zahlungsdatei, über ISO 20022 pain.001 · OpenPGP (primärer Ablauf).
- Von Sicherer Bankkanal nach Bank: An die Bank übermittelt, über SFTP H2H (primärer Ablauf).
- Von Bank nach Sicherer Bankkanal: Statusberichte und Kontoauszüge, über pain.002 · camt.053 · MT940 (asynchron).
- Von Sicherer Bankkanal nach Integrationsschicht: Abgeholt und validiert, über SFTP H2H (asynchron).
- Von Integrationsschicht nach Abstimmungs-Engine: Kontoauszugszeilen, über camt.053 (asynchron).
- Von Abstimmungs-Engine nach ERP: Zugeordnete Buchungen verbucht, über REST/JSON (primärer Ablauf).
- Von Integrationsschicht nach Treasury- und Finanzteam: Abgelehnte Zahlungen mit Grundcode, über pain.002 RJCT (Fehlerpfad).
- Von Abstimmungs-Engine nach Treasury- und Finanzteam: Nicht zugeordnete Zeilen: eine Abstimmungsdifferenz (Fehlerpfad).
- Von Treasury- und Finanzteam nach ERP: Korrigiert und erneut übermittelt (Fehlerpfad).
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
Kartenzahlungen: an der Kasse autorisiert, später abgewickelt, im ERP abgestimmt
Das Terminal oder der Checkout fragt das Gateway, das Gateway fragt den Acquirer, und der Acquirer leitet an Kartennetzwerk und Kartenausgeber weiter. Abwicklungsdateien kommen später und werden im ERP Umsätzen und Gebühren zugeordnet. Eine Zeitüberschreitung löst ein Storno aus, damit der Kunde nie doppelt belastet wird.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 8 Schritten
Der Ablauf Schritt für Schritt
- Von EMV-Terminal oder Online-Checkout nach Zahlungsgateway: Autorisierungsanfrage, über EMV · REST/JSON (primärer Ablauf).
- Von Zahlungsgateway nach Acquirer: Autorisierung, über ISO 8583 (primärer Ablauf).
- Von Acquirer nach Kartennetzwerk und Kartenausgeber: An den Kartenausgeber weitergeleitet, über ISO 8583 (primärer Ablauf).
- Von Acquirer nach Zahlungsgateway: Genehmigt oder abgelehnt, über ISO 8583 (asynchron).
- Von Acquirer nach Integrationsschicht: Abwicklungs- und Gebührendateien, über SFTP (asynchron).
- Von Integrationsschicht nach ERP: Abgewickelte Umsätze, Gebühren und Auszahlungen, über REST/JSON (primärer Ablauf).
- Von Zahlungsgateway nach EMV-Terminal oder Online-Checkout: Keine rechtzeitige Antwort: automatisches Storno, über ISO 8583 0400 (Fehlerpfad).
- Von Integrationsschicht nach Zahlungsbetriebsteam: Abweichung in der Abwicklung oder Chargeback (Fehlerpfad).
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
Open Banking: Daten und Zahlungen mit Einwilligung des Kunden
Der Kunde erteilt seine Einwilligung, der Konnektor hält die Tokens, und jeder Aufruf bei der Bank wird autorisiert und protokolliert. Wenn eine Einwilligung abläuft oder zurückgezogen wird, fragt die App den Kunden erneut, statt stillschweigend zu scheitern.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 7 Schritten
Der Ablauf Schritt für Schritt
- Von Kunde nach Ihre App oder Plattform: Erteilt Einwilligung (primärer Ablauf).
- Von Ihre App oder Plattform nach Open-Banking-Konnektor: Konto- und Zahlungsanfragen, über REST/JSON (primärer Ablauf).
- Von Open-Banking-Konnektor nach Bank-APIs oder Aggregator: Autorisierte API-Aufrufe, über OAuth 2.0 · FAPI · REST (primärer Ablauf).
- Von Bank-APIs oder Aggregator nach Open-Banking-Konnektor: Salden, Transaktionen und Zahlungsstatus, über REST/JSON · webhook (asynchron).
- Von Open-Banking-Konnektor nach ERP oder Hauptbuch: Vereinheitlichte Transaktionen, über REST/JSON (primärer Ablauf).
- Von Bank-APIs oder Aggregator nach Open-Banking-Konnektor: Einwilligung abgelaufen oder zurückgezogen, über HTTP 401 · 403 (Fehlerpfad).
- Von Open-Banking-Konnektor nach Ihre App oder Plattform: Kunde um Erneuerung der Einwilligung gebeten (Fehlerpfad).
Ergebnisse im Finanzdienstleistungssektor
Fallstudien
- 99,4 % durchgängige Verarbeitung bei der automatisierten Abstimmung von camt.053-Kontoauszügen
Automatisierte ISO-20022-Treasury-Anbindung per Host-to-Host und Echtzeit-Freigabe für E-Rechnungen
Wie eine kommerzielle GCC-Großbank der Tier-1-Klasse SAP S/4HANA über ISO 20022 an ihre Bankanbindungen angeschlossen und jede E-Rechnung in Echtzeit bei ZATCA und PINT-AE freigegeben hat.
- 52 % geringere monatliche Ausgaben für KI-Tokens und GPU-Inferenz durch semantisches Caching und Small-Model-Routing
Air-gapped souveräne LLM-Plattform, Multi-Agenten-Automatisierung mit MCP und Token-FinOps
Wie ein reguliertes Finanzinstitut in Europa und der MENA-Region zweisprachige KYC- und Compliance-Aufgaben auf privaten Sprachmodellen automatisiert und seine KI-Inferenzkosten gesenkt hat.
So beginnen
Wie es weitergeht
Terminabstimmung
Unser Team schreibt Ihnen, um einen Termin für das Gespräch zu vereinbaren.
Beratungsvorgespräch
Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Wahl des Tracks
Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.
KI-native Produktteams
Geführte, funktionsübergreifende Pods aus Senior-Ingenieuren, ausgestattet mit agentischen Coding- und QA-Harnesses.
Projekte mit festem Ergebnis und Managed Services rund um die Uhr
Lieferung mit festem Umfang und Meilensteinen unter benannten Delivery-Leads sowie Application Managed Services rund um die Uhr unter SLA-Governance.
Der schnellste Einstieg ist das Paket Sprint für E-Invoicing-Vorgaben und ERP-Bereitschaft, eines unserer schnellen Zusammenarbeitspakete.
Wo Sie startenFragen und Antworten
Welche Fintech-Arbeit leistet XSIS?
Fintech ist unsere Leitbranche. Wir bauen Digital-Banking- und Wallet-Apps, Zahlungs- und Abwicklungsdienste, Kreditplattformen, Vermögensberichte und Versicherungsprozesse und verbinden sie mit Banken, Kartenprozessoren, KYC-Anbietern und ERP-Systemen. Kundennamen veröffentlichen wir ohne deren Zustimmung nicht, daher zeigen wir unsere Erfahrung über die Systeme und Standards, mit denen wir arbeiten, und in technischen Gesprächen mit Ihren Architekten.
Können Sie innerhalb unserer regulatorischen und Sicherheitsanforderungen arbeiten?
Ja. Wir arbeiten innerhalb Ihrer Richtlinien: Ihrer Zugriffsregeln, Ihrer Umgebungen, Ihres Änderungsprozesses und Ihrer Audit-Anforderungen. Vor Arbeitsbeginn vereinbaren wir, wie Daten behandelt werden, auf welche Umgebungen Ingenieure zugreifen dürfen und welche Nachweise Ihre Risiko- und Compliance-Teams brauchen. Wir beschreiben die angewandten Kontrollen verständlich, damit Ihre Prüfer sie bewerten können.
Müssen wir unser Kernbankensystem ersetzen?
In der Regel nicht. Die meisten Banken gewinnen mehr, wenn sie das Kernsystem in klar definierte APIs umhüllen und neue Produkte und Kanäle als Dienste darum herum bauen. Das hält das führende System stabil, während sich die kundennahen Teile schneller ändern. Wenn ein Kernsystem wirklich ersetzt werden muss, planen wir die Migration in Phasen, wobei beide Systeme abgeglichen werden, bis das alte abgeschaltet wird.
Wie gehen Sie mit Kartendaten um?
Wir gestalten so, dass möglichst wenige Systeme je eine vollständige Kartennummer sehen. Gehostete Zahlungsfelder, Tokenisierung und Netzwerk-Token belassen die Kartendaten beim Prozessor, was Ihren PCI-DSS-Geltungsbereich verkleinert. Wo ein System Kartendaten verarbeiten muss, bauen wir es nach den geltenden PCI-DSS-Kontrollen und dokumentieren sie für Ihren Prüfer.
Unterstützen Sie ISO 20022 und Echtzeitzahlungen?
Ja. Wir bauen Dienste, die ISO-20022-Nachrichten erstellen, validieren und lesen, sowohl für Unternehmenszahlungen und Berichte wie pain.001 und camt.053 als auch für die Interbankennachrichten von Echtzeit- und Großbetragszahlungssystemen. Jedes System und jede Bank hat eigene Regeln, daher arbeiten wir nach deren Implementierungsleitfäden und testen in deren Testumgebungen.
Können Sie Betrugs- und Transaktionsüberwachung bauen?
Ja. Wir kombinieren Regeln, die Ihre Analysten lesen und ändern können, mit Modellen für maschinelles Lernen, die auf Ihren eigenen Daten trainiert sind, und erklären, warum jeder Alarm ausgelöst wurde. Alarme gehen an eine Fallwarteschlange, in der Analysten entscheiden, und ihre Entscheidungen fließen in Regeln und Modelle zurück. Wenn Sie bereits spezialisierte Screening-Anbieter nutzen, binden wir sie an.
Was bestimmt die Kosten eines Fintech-Projekts?
Die Zahl der beteiligten Systeme und Partner, die geltenden regulatorischen Kontrollen, das Volumen und die Geschwindigkeit, die das System bewältigen muss, und wie viel Testaufwand Partner vor der Inbetriebnahme verlangen. Das Partner-Onboarding, etwa eine Bank- oder Prozessor-Zertifizierung, gibt oft das Tempo vor – mehr als der Code. Wir schätzen nach der Discovery und teilen die Arbeit in Phasen, die Sie einzeln finanzieren und freigeben können.
Beginnen Sie mit einem Gespräch, nicht mit einem Vertrag.
Sagen Sie uns, was Sie bauen, verbinden oder absichern möchten. Ein Architekt geht es mit Ihnen durch und empfiehlt dann, wo Sie beginnen sollten.