Ja, derzeit arbeitet die BiPRO Service GmbH mit zwei Subunternehmen zusammen. Das sind derzeit die Firmen apinity und Fincon Reply.
apinity stellt den Marktplatz als IT-Infrastrukturelle (Bodenplatte) und Fincon Reply die Konverter-Servicefunktion in dem Stack Bestand bereit.

Ja, zu Beginn hat man durch eine Anbindung an den Hub einen Parallelbetrieb. Daher müssen schnell und konsequent die bilaterale Verbindungen abgeschaltet werden.  Anfangs ist dies natürlich eine zusätzliches Investment, aber später wird ein hoher Nutzen generiert durch die Anbindung vieler Teilnehmer an den Hub. Die bisherigen bilateralen Anbindungen werden dann obsolet.

Die Testprotokolle können auf Anfrage zur Verfügung gestellt werden.

Anbieter (Provider) und Partnerunternehmen der Anbieter (Consumer) müssen weiterhin „BiPRO sprechen“. Der Hub ist nicht als Ersatz der BiPRO-Normen gedacht. Wir halten es nach wie vor für äußerst wichtig, dass sich Provider und Consumer mit den BiPRO-Normen auseinandersetzen, um Prozessoptimierungspotenziale zu nutzen. Der Hub dient lediglich als Datendrehscheibe. Die Entwicklung der Normen sowie der Schnittstellen innerhalb der Unternehmen bleibt davon unberührt. Dies haben wir in unseren Leitsätzen festgeschrieben.

Nein. Im Bereich der 430.x (Stack Bestand) werden ausschließlich BiPRO-Standards geliefert. Es werden derzeit seitens der Provider die Normreleases 2.6 ff. auf 2.8 als Konvertierung hin zu den Consumern angeboten.

Ja alle Requests/Responses zum abonnierten Service laufen über den Hub. Da der Hub inklusive des Konverters in der Azure Cloud läuft, kann sehr gut skaliert werden.

Nein, der Hub ist nicht dafür gedacht proprietäre Schnittstellen in BiPRO-Services umzuwandeln. Versicherungen müssen sich mit BiPRO-konformen Schnittstellen anbinden und die Partnerunternehmen müssen diese Service über eine eigene BiPRO-Schnittstelle konsumieren. Der Hub soll die Umsetzung von BiPRO-Normen im Markt fördern und nicht den eigenen proprietären Schnittstellen der Teilnehmer eine längere „Daseinsberechtigung“ geben.

Die Provider haben alle unterschiedliche Voraussetzungen, und jeder Provider muss für sich entscheiden, ob sich eine Teilnahme für ihn rechnet. Die Vorteile des Hubs sind oben dargestellt. Der Hub lebt vom „Mitmachen“ und je mehr Provider/ Consumer mitmachen, desto positiver wird die wirtschaftliche Betrachtung ausfallen.

Die Provider müssen einen RClassic Service in Release 2.6 oder höher anbieten, um sich an den Hub anschließen zu können.

Zu den bereits angebotenen Services gehört seit Dezember 2023 die Norm 430.x (RClassic). Damit werden die Sparten Sach/Komposit/KfZ sowie die Leben-Sparten LV/KV umgesetzt. Im Bereich Bestand werden insbesondere die in der DIOPLUS BDÜ definierten Netto-Daten übertragen. Darüber hinaus können über den Hub unter anderem die Maklerpost, die Vermittlerabrechnung, Störfälle und Schadendaten übertragen werden. Weitere Normen wie 490.x (Maklermandat) sind in Umsetzung. Zudem befindet sich RNext Schaden in Planung und das Themenfeld TAA (Tarifierung Angebot Anfrage) in Diskussion.

Alle Consumer senden ihre Anfragen in der aktuellen Version, aktuell 2.8.6. Diese Requests werden anschließend in die Version umgewandelt, die in den API Einstellungen des jeweiligen Providers definiert ist. Die Antwort des Providers, wie beispielsweise der getShipment-Response, wird auf dem gleichen Weg zurück in die Version 2.8.6 konvertiert. Grundsätzlich bedeutet das, dass sowohl der gesamte Request als auch der gesamte Response konvertiert werden. Wichtig ist hierbei, zwischen den fachlichen Daten, die konvertiert werden, und beispielsweise einem Feld wie den Autorisierungs-Token, welches nicht konvertiert werden muss, zu unterscheiden.

Es ist mit den Teilnehmern abgestimmt das Authentifizierungsverfahren der easy-Login GmbH zu nutzen. Übergangsweise kann ein providerspezifischer STS genutzt werden.

Hierbei wird ein API-Key zur Authentifizierung des Consumers beim Hub verwendet. Zwischen Hub und Provider können verschiedene aktuelle Verfahren vereinbart werden, mit denen sich der Consumer beim Provider authentifizieren kann. Davon unabhängig kommt immer das Token des Consumers im Security Header

Alle 430-Normen-Umsetzungen der Teilnehmer im Hub wurden „gescreent“ und damit unnötige Individualitäten (VU-Spezifika) eliminiert sowie unnötige Daten, die Consumern gar nicht nutzen gekennzeichnet. Damit gibt es für die Consumer ein einheitliches „fachliches Bild“ und eine einheitliche Anbindung. Wenn anfänglich ein VU noch nicht alle Daten liefern kann dies sukzessive nachgeholt werden. Der Consumer muss aber durch dieses „Nachreichen bzw. komplettieren der Daten“ keine Änderungen mehr an seiner Schnittstelle vornehmen. Überdies wird der Konverter erzwingen, dass eine normkonforme Anbindung an den Hub durch eine Schema-Validierung erfolgt.

In unserer engen Zusammenarbeit mit Consumern und Providern hat sich gezeigt, dass spezifische Individualitäten auf Consumer-Seite bisher nicht verwertet werden.

In der Zeit der Digitalisierung sind Fehler leider nicht immer vollständig zu vermeiden. Unser Anspruch ist es, uns dieser Realität bewusst zu sein und Fehler schnell zu erkennen und zu beheben. Durch ein leistungsfähiges Monitoring-System identifizieren wir Unregelmäßigkeiten frühzeitig und ergreifen proaktiv geeignete Maßnahmen. Unser umfassendes Incident-Management-System ermöglicht es uns, Anfragen und Anliegen unserer Teilnehmer rasch und effizient zu bearbeiten. Darüber hinaus stellen wir eine Vielzahl hilfreicher Artikel in unserem Hilfecenter zur Verfügung, um Unterstützung zu bieten und die Selbsthilfe zu fördern.

Hierfür wird eine von den Providern zur Verfügung gestellte Base-URL verwendet, die im Hub hinterlegt werden muss. Über diese können die Daten dann von den Consumern, nach Vereinbarung zwischen Consumer und Provider, abgerufen werden. Der Hub speichert keinerlei Daten, sondern die Daten werden nur durchgeroutet.

Der Hub hat, die verschiedenen „Dialekte“, die Provider und Consumer im Rahmen von BiPRO sprechen, standardisiert. Insbesondere im Bereich der Norm 430.x gibt es keine individuellen Anpassungen mehr. Der Hub kommuniziert einheitlich über eine wsdl-Datei mit den Consumern.

Der Hub speichert über die Durchleitungsdauer hinaus keine personenbezogenen Daten. Über vertragliche Vereinbarungen wird der Datenschutz sichergestellt. Die Azure Cloud ist so eingestellt, dass die Daten in der EU verbleiben.

Wir selbst greifen nicht aktiv in den Prozess ein und die Authentifizierungsdaten werden eins-zu-eins weitergeleitet. Die Übergabe erfolgt ausschließlich über den Request-Token bzw. Security-Token, der die Authentifizierung und Autorisierung sicherstellt.