Die Versicherungsbranche hat den Vertrieb, das Underwriting und die Kundeninteraktion digitalisiert, doch der Geldfluss selbst erfolgt nach wie vor über veraltete Kanäle. Mit Finsurtech.ai möchten Mirela Dimofte und Andrew Sims die Art und Weise neu gestalten, wie Prämien und Schadensfälle bezahlt, abgerechnet, abgeglichen und in Ökosysteme eingebettet werden.
Seit Jahrzehnten investieren Versicherer massiv in Policenverwaltungssysteme, CRM-Plattformen und digitale Vertriebskanäle. Die zugrunde liegende Finanzinfrastruktur – also die Art und Weise, wie Prämien eingezogen und Schadensfälle bezahlt werden – ist jedoch nach wie vor weitgehend fragmentiert, manuell und bankenzentriert. Diese Lücke schränkt die Automatisierung, das Kundenerlebnis und Echtzeit-Versicherungsmodelle zunehmend ein.
Finsurtech.ai positioniert sich als eine speziell für Versicherungen entwickelte Zahlungsinfrastruktur. Anstatt generische Fintech-Tools anzupassen, konzentriert sich das Unternehmen auf die spezifische operative Komplexität der Branche: Mehrparteienabrechnungen, Makler, MGAs, grenzüberschreitende Zahlungsströme und Schadensauszahlungen.
Wir sprachen mit den Gründern Mirela Dimofte und Andrew Sims darüber, warum Versicherungen eine eigene Zahlungsarchitektur benötigen und was passiert, wenn Geld genauso schnell bewegt wird wie Versicherungsentscheidungen getroffen werden.
Die Versicherungsbranche hat viele Front-Office-Prozesse digitalisiert. Warum sind Zahlungen nach wie vor einer der am wenigsten modernisierten Bereiche?
Mirela Dimofte (MD): In den letzten zehn Jahren haben Versicherer begonnen, Vertrieb, Underwriting und Kundeninteraktion erfolgreich zu digitalisieren. Die zugrunde liegenden Geldflüsse wurden jedoch oft auf alten Schienen belassen. Die Zahlungsabwicklung wurde in der Vergangenheit eher als technische Back-Office-Funktion, denn als Teil der Kernarchitektur von Versicherungen betrachtet. Infolgedessen laufen Schadensfälle und Prämienzahlungen immer noch über fragmentierte Banküberweisungen, vorfinanzierte Konten und manuelle Abstimmungen, die oft über TPAs, MGAs und verschiedene interne Systeme verteilt sind.
Da diese Mechanismen «gut genug funktionierten», konzentrierten sich die Investitionen in der Regel auf Preisgestaltung, Produkte und Kundenportale und nicht darauf, wie Kapital tatsächlich bewegt wird, wenn ein Schadensfall reguliert oder ein Makler bezahlt wird. Angesichts des heutigen Umfangs und der regulatorischen Erwartungen führt diese Trennung zwischen Versicherungslogik und Zahlungsabwicklung zu Kapitalverlusten und operative Reibungsverlusten. Finsurtech.ai wurde gegründet, um genau diese Lücke zu schliessen, indem die Zahlungsarchitektur als erstklassiger Bestandteil des Versicherungsbetriebsmodells behandelt wird.
Was funktioniert innerhalb eines Versicherungsunternehmens nicht mehr, wenn die Zahlungsinfrastruktur nicht für die Versicherungslogik ausgelegt ist?
Andrew Sims (AS) Wenn die Zahlungsinfrastruktur nicht für Versicherungen entwickelt wurde, spiegelt sie eher die Arbeitsabläufe von Banken oder Zahlungsdienstleistern wider als die Logik von Schadensfällen und Policen. Dies führt zu einer strukturellen Diskrepanz zwischen dem, was im Schadenssystem genehmigt wurde, und der Ausführung der Zahlung selbst. Die Daten sind über Schadensplattformen, Bankenportale, Anbietersysteme und Tabellenkalkulationen verstreut, sodass niemand einen Echtzeit-Überblick über den gesamten finanziellen Lebenszyklus eines Schadensfalls hat.
Operativ äussert sich dies in manuellen Genehmigungen, Batch-Dateien und wiederholten Überprüfungen, nur um sicherzustellen, dass die richtige Partei unter den richtigen Bedingungen den richtigen Betrag erhält. Die Finanzabteilung muss dies durch Vorfinanzierungen und Puffer ausgleichen, die Schadenabteilung kämpft mit Verlusten und Nacharbeiten, und die Abstimmungsteams verbringen einen Grossteil ihrer Zeit damit, Transaktionen abzugleichen, die «von Haus aus korrekt» hätten sein können. Kurz gesagt: Die Disziplin bei der Ausführung hinkt hinter den Absichten bei der Schadenbearbeitung hinterher, und die Behandlung von Ausnahmen wird in der Regel zu einem eigenen operativen Aufwand.
Sie positionieren Finsurtech.ai als Infrastruktur und nicht als Zahlungsdienst. Worin besteht der Unterschied in Bezug auf die Architektur?
AS: Ein Zahlungsdienst konzentriert sich in der Regel auf die Abwicklung einzelner Transaktionen: Geld von A nach B überweisen, per Karte, Banküberweisung oder Wallet. Infrastruktur ist nach unserer Definition eine integrierte Kontrollschicht, die Schadensentscheidungen, Partnerlogik und Finanzierungsmechanismen durchgängig miteinander verbindet. Anstatt nur einen weiteren Kanal bereitzustellen, bettet Finsurtech.ai die Abrechnungsparameter direkt in die Zahlungsanweisung, und in einigen Fällen auch in das Zahlungsinstrument, ein und koordiniert die Abläufe über mehrere Banken, Systeme und Partner hinweg.
Architektonisch bedeutet dies, dass wir «unter den Produkten und Prozessen sitzen und nicht neben ihnen.
Wir übersetzen eine genehmigte Schadensentscheidung in ausführbare Regeln: wer darf bezahlt werden, für welche Leistungen, unter welchen Grenzen und setzen diese Regeln im entscheidenden Moment während des Abrechnungsprozesses durch. Dieselbe Infrastruktur kann virtuelle Karten, Sofortauszahlungen, Mehrparteienabrechnungen und andere Schienen unterstützen. Für Versicherer schafft dies eine einheitliche operative Grundlage für Prämien, Schadensfälle, Provisionen und Partnerabläufe, ohne sie zu zwingen, das proprietäre Zahlungsprodukt eines einzelnen Anbieters zu nutzen.
Wo sehen Sie heute die grössten Ineffizienzen: bei der Prämieneinziehung, der Schadenauszahlung, der Abstimmung oder der Partnerabrechnung?
MD: Alle vier Bereiche weisen strukturelle Ineffizienzen auf, aber die grössten wirtschaftlichen Auswirkungen entstehen in der Regel an der Schnittstelle zwischen Schadenauszahlung und Abstimmung, insbesondere wenn delegierte Befugnisse und komplexe Ökosysteme beteiligt sind. Bei der Schadenauszahlung werden Entscheidungen zu Bargeld; jede Schwäche in der Ausführungsdisziplin, wie Doppelzahlungen, Leistungen ausserhalb des Leistungsumfangs, Verzögerungen, wirkt sich direkt auf die Schadenquote und die Kapitalverwendung aus.
Der Abgleich absorbiert dann die nachgelagerten Kosten dieser Fragmentierung. Die Teams gleichen Kontoauszüge manuell mit Bordereaux, Partnerberichten und internen Hauptbüchern ab, oft Wochen oder Monate nach dem Ereignis. Partnerabrechnungen verstärken das Problem, da Gelder vorab an TPAs, MGAs oder Netzwerke gezahlt werden, um die begrenzte Kontrolle bei der Ausführung auszugleichen. Unser Ansatz besteht darin, diese Bereiche als einen zusammenhängenden Ablauf zu behandeln: Zahlungen werden zum Zeitpunkt der Abrechnung geregelt, und Daten auf Transaktionsebene werden automatisch generiert, sodass die Abstimmung und die Abrechnungen mit Partnern zu Nebenprodukten der Ausführung werden und keine separaten manuellen Prozesse mehr sind.
Was unterscheidet Versicherungszahlungen strukturell von E-Commerce- oder Bankzahlungen?
AS: Im E-Commerce sind die meisten Transaktionen einmalig und bilateral: ein Händler, ein Kunde, ein klares Produkt und eine sofortige Abrechnung. Im Bankwesen handelt es sich bei Zahlungen oft um Überweisungen von Konto zu Konto mit relativ einfacher Geschäftslogik. Versicherungszahlungen hingegen sind mehrteilig, zeitlich gestaffelt und eng mit Rückstellungen verbunden. Ein einzelner Schadenfall kann Versicherungsnehmer, Reparaturbetriebe, medizinische Dienstleister, Assistance-Partner, Broker und Rückversicherer betreffen, die jeweils ihre eigenen Verträge und Bedingungen haben.
Darüber hinaus sind die endgültigen Kosten eines Schadenfalls nicht im Voraus bekannt. Umfang und Preisgestaltung entwickeln sich im Laufe der Reparaturen oder bei Änderungen der Behandlungspläne weiter. Herkömmliche Zahlungssysteme wurden nie dafür konzipiert, diese dynamische Versicherungslogik zum Zeitpunkt der Abrechnung zu berücksichtigen. Finsurtech.ai löst dieses Problem, indem jede Zahlung als ein Instrument behandelt wird, das den Kontext des Schadensfalls, also Limits, autorisierte Leistungen und Gegenparteien enthält, sodass die Ausführung der technischen Absicht der Police und der Schadensentscheidung folgen kann.
Wie geht Ihre Plattform mit Mehrparteien-Zahlungsströmen um? Zum Beispiel mit Versicherern, Broker, Rückversicherern und Versicherungsnehmern in einer Transaktionskette?
AS: Wir beginnen mit der Modellierung der wirtschaftlichen Absicht der Transaktionskette: Wer trägt welchen Anteil der Kosten, wer sollte in welcher Reihenfolge bezahlt werden und unter welchen Bedingungen? Diese Logik wird dann in unsere Orchestrierungsebene eingebettet. Anstatt eine grosse Zahlung in das System zu schieben und «später zu sortieren», erstellen wir strukturierte Zahlungsanweisungen für jede Partei, jede mit ihren eigenen Parametern und Kontrollen.
Beispielsweise könnte ein Kfz-Schadenfall eine Reihe koordinierter Abläufe auslösen: eine virtuelle Karte für die Werkstatt, die auf autorisierte Arbeiten begrenzt ist, eine direkte Erstattung an den Versicherungsnehmer und eine Abrechnungsanweisung an einen Rückversicherer, sobald bestimmte Schwellenwerte erreicht sind. All dies basiert auf demselben Schadenfall und demselben Genehmigungskontext. Der Versicherer behält einen einheitlichen Überblick über den gesamten Lebenszyklus: Status, Beträge, Zeitplan, während jeder Beteiligte eine einfache, direkte Zahlung erhält. Die Komplexität wird in der Infrastruktur bewältigt, nicht in manuellen Prozessen.
Die Auszahlung von Versicherungsleistungen ist für Kunden ein emotional kritischer Moment. Was erfordert eine «Echtzeit-Schadensregulierung» technisch gesehen hinter den Kulissen?
MD: Bei der Echtzeit-Schadensregulierung geht es nicht nur um Geschwindigkeit, sondern auch darum, über genügend Kontrolle und Kontext zu verfügen, um im Moment der Entscheidung sicher Gelder freigeben zu können. Technisch gesehen erfordert dies eine Integration zwischen dem Schadenssystem, der Zahlungsorchestrierungsebene und den zugrunde liegenden Schienen. Die Schadenplattform sollte strukturierte Abrechnungsparameter, wie genehmigter Betrag, Gegenparteien und Bedingungen, über APIs oder in Stapeln an die Zahlungsebene weiterleiten.
Unsere Infrastruktur wandelt diese Daten dann in zweckgebundene Instrumente um, wie z.B. virtuelle Kartennummern oder Sofortauszahlungen, die diese Parameter im entscheidenden Moment durchsetzen und Autorisierung im Falle einer VCN oder Genehmigung zum Zeitpunkt der Konto-zu-Konto-Zahlungen.
Echtzeit-Entscheidungen hängen auch von sofortigem Feedback ab: Jede Autorisierung, Ablehnung oder Teilgenehmigung sendet strukturierte Daten an den Versicherer zurück. Dadurch entsteht eine Feedbackschleife, in der Deckungsentscheidungen, Kundenkommunikation und Zahlungsausführung innerhalb von Sekunden erfolgen, aber vollständig kontrolliert und überprüfbar bleiben.
Wie integrieren Sie sich in ältere Policenverwaltungssysteme, die nie für API-gesteuerte Finanzdienstleistungen konzipiert wurden?
AS: Viele Kernsysteme in der DACH-Region und in Mitteleuropa sind robust, aber monolithisch. Wir verlangen von unseren Kunden nicht, diese zu ersetzen. Stattdessen führen wir eine Integrationsschicht ein, die Ereignisse oder Dateien aus dem Kernsystem empfangen und in unsere Plattform importieren kann. Die Integrationsmuster reichen von Batch-Exporten über APIs bis hin zu ereignisbasierten Hooks, je nach Bereitschaft und Bedarf des Kunden.
Nach der Anbindung bleibt das Policenverwaltungs- oder Schadenssystem die «Quelle der Wahrheit» für Versicherungsschutz und Entscheidungen, während Finsurtech.ai zur Ausführungsmaschine für Zahlungen und Abrechnungslogik wird. Im Laufe der Zeit können Versicherer ohne eine radikale Migration von einer batchgesteuerten zu einer nahezu Echtzeit-Integration übergehen. Dieser Ansatz respektiert bestehende Investitionen und erschliesst gleichzeitig moderne Funktionen wie virtuelle Karten, programmierbare Auszahlungen und automatisierte Abstimmungen.
Die Abstimmung ist ein massiver Kostenfaktor im Versicherungsfinanzwesen. Wie viel davon kann realistisch automatisiert werden?
MD: Unsere Erfahrung zeigt, dass ein sehr grosser Teil der Abstimmungsarbeit darin besteht, die schlechte Datenqualität zum Zeitpunkt der Zahlung auszugleichen. Wenn jede Transaktion eine eindeutige Schadenreferenz, eine Servicekategorie, eine Anbieter-ID und einen Abrechnungskontext enthält, wird die Zuordnung zu einer regelbasierten Tätigkeit und nicht mehr zu einer manuellen Detektivarbeit. In diesem Umfeld kann der Grossteil der Abstimmungszeilen automatisiert werden, sodass sich die Mitarbeiter auf echte Ausnahmen konzentrieren können.
Finsurtech.ai erreicht dies, indem es strukturierte Datensätze auf Transaktionsebene als Teil des Zahlungsflusses selbst generiert. Das Zahlungsinstrument wird aus dem Schadenfall erstellt, sodass die von der Finanzabteilung verwendeten Identifikatoren bereits mit denen übereinstimmen, die in der Schadenbearbeitung und im operativen Geschäft verwendet werden. Kontoauszüge und Partnerberichte werden erfasst und automatisch mit diesem kanonischen Hauptbuch abgeglichen. Dadurch entfällt zwar nicht die Notwendigkeit einer Finanzaufsicht, aber die Abstimmung wird von einer monatlichen Feuerwehreinsatz zu einem kontrollierten, ausnahmegesteuerten Prozess.
Wer ist Ihr Hauptabnehmer: der CIO, der CFO, der Betriebsleiter oder der Vertriebsleiter?
MD: Die Hauptsponsoren sind in der Regel der CFO und der COO, oft zusammen mit dem Leiter der Schadenabteilung. Sie spüren die Auswirkungen von Zahlungseffizienzen am direktesten in den Schadenquoten, der Kapitalverwendung und den Betriebskosten. Gleichzeitig ist der CIO ein wichtiger Partner, da die Lösung Kernsysteme, Integrationsmuster und Sicherheitsarchitektur betrifft.
Häufig gibt es eine funktionsübergreifende Lenkungsgruppe: Die Finanzabteilung definiert Kapital- und Liquiditätsziele, die Schadenabteilung konzentriert sich auf Durchlaufzeiten und Verluste, der Betrieb auf Skalierbarkeit und die IT auf die architektonische Eignung. Führungskräfte aus den Bereichen Vertrieb und Bancassurance kommen hinzu, wenn Provisionsflüsse, eingebettete Versicherungen oder Partner-Ökosysteme im Fokus stehen. Finsurtech.ai wurde entwickelt, um all diesen Interessengruppen über eine gemeinsame Infrastruktur zu dienen, anstatt ein weiteres isoliertes Tool hinzuzufügen.
Wie profitieren Broker und MGAs direkt von einer modernen Zahlungsinfrastruktur?
AS: Broker und MGAs leben von der Qualität und Vorhersehbarkeit von Cashflows. Wenn Zahlungen verspätet, undurchsichtig oder inkonsistent sind, belastet dies die Beziehungen und das Betriebskapital auf allen Seiten. Mit einer modernen Infrastruktur können Abrechnungen nach klaren, programmierbaren Regeln und je nach Vereinbarung, Portfolio oder Transaktion geplant und ausgeführt werden, wodurch Streitigkeiten und manuelle Nachverfolgungen reduziert werden.
Da jede Zahlung an einen Schadenfall, eine Police oder eine Provision geknüpft ist, erhalten die Partner mehr Transparenz darüber, was bezahlt wurde und warum. Dies reduziert den Abstimmungsaufwand und ermöglicht es Brokern und MGAs, sich auf Wachstum und Service zu konzentrieren, anstatt Abrechnungen nachzujagen. In einigen Modellen können sie auch auf VCN-basierte Auszahlungen für von ihnen verwaltete Schadenkosten zugreifen, wodurch keine grossen, vorfinanzierten Guthaben mehr erforderlich sind. Das verbessert ihre Liquidität und gibt dem Versicherer gleichzeitig eine detailliertere Kontrolle und Transparenz über die von Partnern geleiteten Zahlungen.
Erfordern eingebettete Versicherungsökosysteme (Mobilität, Reisen, Plattformen) eine grundlegend andere Finanzarchitektur?
MD: Eingebettete Ökosysteme erhöhen die Komplexität in zweierlei Hinsicht: Erstens führen sie Nicht-Versicherungsplattformen wie Mobilitäts-Apps, Reiseportale oder Marktplätze als Vertriebs- und manchmal auch als Schadensfall-Kontaktpunkte ein.
Zweitens arbeiten sie oft mit hoher Frequenz und geringen Ticketgrössen, was für traditionelle batchbasierte Abrechnungsmodelle nur schwer effizient zu bewältigen ist. In diesem Sinne erfordern sie tatsächlich programmierbarere Finanzfunktionen.
Die Grundprinzipien bleiben jedoch dieselben: klare Regeln darüber, wer wann und unter welchen Bedingungen bezahlt werden soll, Echtzeit-Transparenz und eine starke Governance am Zahlungsort. Auch die Kernsystemarchitektur bleibt unverändert. Finsurtech.ai ist als erweiterbare Schicht aufgebaut, die eine Verbindung zu Plattformpartnern herstellt, Mikrotransaktionsflüsse verarbeitet und dennoch alles mit den Schadensfällen und der Policenlogik des Versicherers abgleicht. So können Versicherer an eingebetteten Ökosystemen teilnehmen, ohne für jeden Partner eine massgeschneiderte Zahlungslogik aufbauen zu müssen und ohne separate Systeme für unterschiedliche Vertriebsvereinbarungen zu benötigen.
Zahlungen bringen regulatorische Risiken mit sich: Schutzmassnahmen, AML, grenzüberschreitende Compliance. Wie strukturieren Sie die Plattform, damit sie in verschiedenen Rechtsräumen funktioniert?
AS: Wir gestalten die Architektur so, dass die regulatorischen Verantwortlichkeiten klar und nachvollziehbar sind. Die Plattform kann mit Zahlungspartnern (Banken, E-Geld-Institute, Kartenaussteller und Verarbeiter) in jedem Rechtsraum zusammenarbeiten, während sich Finsurtech.ai auf die Koordination, die Ausführung von Regeln und die Datenintegrität konzentriert. Dadurch können wir lokale Compliance-Rahmenbedingungen für AML, Sanktionsprüfungen und Schutzmassnahmen nutzen, ohne Versicherer zu einer einzigen Bankbeziehung zu zwingen.
Aus technischer Sicht stellen wir sicher, dass jede Transaktion die erforderlichen Metadaten enthält: Zahler, Zahlungsempfänger, Zweck, Schadensfallreferenz, geografische Lage, damit die Überprüfung und Berichterstattung genau und überprüfbar sind. Grenzüberschreitende Zahlungsströme können über geeignete Korridore geleitet werden, wobei die Währungsabwicklung und lokale Anforderungen in der Regel-Engine kodiert sind. Für Versicherer, die in der Schweiz, der EU und anderen Regionen tätig sind, bedeutet dies, dass sie ein einheitliches Kontrollsystem anwenden können und gleichzeitig die lokalen regulatorischen Besonderheiten berücksichtigen.
Über regulatorische Aufgaben und Partnermodelle hinaus befassen wir uns auch mit Datenhoheit und Datenschutz durch Technikgestaltung. Unsere Architektur kann auf verteilten Datenbanktechnologien eingesetzt werden, die sensible Daten innerhalb der erforderlichen Gerichtsbarkeiten aufbewahren und dennoch eine einheitliche logische Ansicht für den Versicherer bieten. Regionale Shards oder Tenants stellen sicher, dass Schweizer, EU- oder andere lokale Daten niemals genehmigte Standorte verlassen, wodurch nationale Anforderungen an die Datenresidenz und aufsichtsrechtliche Erwartungen erfüllt werden. Personenbezogene Daten werden in voller Übereinstimmung mit der DSGVO und den damit verbundenen Rahmenwerken verarbeitet, einschliesslich Zweckbindung, Minimierung, starker Verschlüsselung, Zugriffskontrollen und überprüfbaren grenzüberschreitenden Übertragungen unter Verwendung geeigneter Sicherheitsvorkehrungen.
Könnten Zahlungsdaten letztendlich zu Erkenntnissen für das Underwriting und das Management von Anbietern führen?
MD: Ja, wir glauben, dass Zahlungsdaten eine weitgehend ungenutzte Quelle für Underwriting-Erkenntnisse sind. Heute stützen sich viele Modelle auf statische Informationen und historische Schadensfälle, nicht jedoch auf die detaillierten Abrechnungsdynamiken hinter diesen Schadensfällen. Wenn jede Transaktion mit bestimmten Dienstleistungen, Anbietern, Zeitplänen und Verhaltensweisen verknüpft ist, ergeben sich Muster, die sowohl die Preisgestaltung als auch die Produktgestaltung beeinflussen können.
Beispielsweise können Anbieter oder Netzwerke, die regelmässig Zusatzkosten verursachen, längere Reparaturzyklen haben oder häufig wiedereröffnet werden, identifiziert und anders behandelt werden. Ebenso können bestimmte Kanäle oder Produktkonfigurationen im Laufe der Zeit unterschiedliche Kostenentwicklungsprofile aufweisen. Unsere Aufgabe ist es, einen sauberen, strukturierten Datensatz bereitzustellen, den Underwriter und Versicherungsmathematiker sicher nutzen können, ohne die Privatsphäre zu beeinträchtigen, um Annahmen zu Häufigkeit, Schwere und Inflation von Schadensfällen zu verfeinern.
Wenn Versicherer über vollständig programmierbare Geldflüsse verfügen würden, welche neuen Versicherungsprodukte würden dann plötzlich möglich werden?
MD: Vollständig programmierbares Geld ermöglicht es Versicherern, von einer Zahlung «nachträglich» zu einer Finanzierung genau definierter Ergebnisse nahezu in Echtzeit überzugehen. Dadurch werden parametrische und ereignisgesteuerte Produkte in großem Massstab weitaus praktischer, da Auszahlungen automatisch an zugelassene Gegenparteien freigegeben werden können, sobald die Bedingungen erfüllt sind. Ausserdem werden damit gestaffelte Leistungen möglich, wie Rehabilitations- oder Reparaturpakete, bei denen die Mittel schrittweise freigegeben werden, sobald die Leistungen erbracht werden.
Im Einzelhandel könnte man sich schadensgebundene Geldbörsen oder virtuelle Karten vorstellen, die eine sofortige Genehmigung mit streng kontrollierter Nutzung ermöglichen und so die Schadenabwicklung eher zu einer Art unterstützendem Kauf als zu einem Erstattungsprozess machen.
Im gewerblichen Bereich könnten komplexe Strukturen mit mehreren Parteien, wie Bauprojekte oder Mobilitätsplattformen, durch regelbasierte Abläufe finanziert werden, die auf Meilensteine, Telemetrie oder IoT-Signale reagieren.
In allen Fällen ist der rote Faden derselbe: Das Kapital verhält sich genau so, wie es der Produktdesigner beabsichtigt hat, da die Zahlungslogik direkt in den Ablauf kodiert ist. Das sind die spannenden Gespräche, auf die wir uns im Laufe der Zeit mit unseren Kunden freuen.
Die Fragen hat Binci Heeb gestellt.
Lesen Sie auch: Vom Verständnis zur Umsetzung: Wie Prozessintelligenz die Schadensbearbeitung neu definiert
Suche:
Sponsoren:
