Clearinghuis Regres Functioneel Ontwerp v4.3

Clearinghuis Regres Functioneel Ontwerp v4.3

Classificatie: beschermd

Inhoudsopgave

HOOFDSTUK 1 1.1 1.2 1.3

INLEIDING................................................................................................................. 4

DOELSTELLING ............................................................................................................................ 4 GERELATEERDE DOCUMENTEN .................................................................................................... 4 VERSIEBEHEER ........................................................................................................................... 5

HOOFDSTUK 2

SCOPE ...................................................................................................................... 7

2.1 UITGANGSPUNTEN ....................................................................................................................... 7 2.2 PARTICIPANTEN ........................................................................................................................... 7 2.2.1 Rollen ............................................................................................................................................. 8 2.3 KORTE BESCHRIJVING CR ........................................................................................................... 9 2.4 BASISWERKING ......................................................................................................................... 10 2.4.1 Beperking te Behandelen Regresschades ............................................................................. 10 2.4.2 Melden.......................................................................................................................................... 12 2.4.3 Matchen ....................................................................................................................................... 12 2.4.4 Betaling (Clearing) ...................................................................................................................... 13 2.5 KOPPELINGEN EXTERNE SYSTEMEN (INTERFACES) ..................................................................... 13 HOOFDSTUK 3

GEDETAILLEERDE PROCESBESCHRIJVING .................................................... 15

3.1 FLOW DIAGRAM ......................................................................................................................... 15 3.2 USE CASES ............................................................................................................................... 17 3.2.1 Eenvoudige Regresvoering ....................................................................................................... 18 3.2.2 Verkeerde Tegenpartij ............................................................................................................... 19 3.2.3 Bod met Tegenbod ..................................................................................................................... 20 3.2.4 Termijn Verloopt ......................................................................................................................... 21 3.2.5 Termijn Schadebedrag Verloopt............................................................................................... 22 3.2.6 Geen Overeenkomst .................................................................................................................. 23 3.2.7 Driepartijenregres ....................................................................................................................... 24 3.2.8 Nagekomen bedragen ............................................................................................................... 26 3.3 PROCESCOMPONENTEN ALGEMEEN ........................................................................................... 26 3.3.1 Basiscontroles ............................................................................................................................. 27 3.3.2 Identificatie Tegenpartij uit WAM-volmachtcode .................................................................... 27 3.3.3 Mogelijke Statussen van een Regres ...................................................................................... 27 3.3.4 Volgorde van Controles ............................................................................................................. 27 3.4 INDIVIDUELE PROCESCOMPONENTEN.......................................................................................... 28 3.4.1 Regres Melden ............................................................................................................................ 28 3.4.2 Regres Afvoeren ......................................................................................................................... 29 3.4.3 Matchen ....................................................................................................................................... 30 3.4.4 Schadebedragen Melden .......................................................................................................... 32 3.4.5 Rappel Aansprakelijkheid .......................................................................................................... 34 3.4.5.1 Extra rappel t.b.v. Buiten Gerechtelijke Kosten “laag tarief” ............................................ 34 3.4.6 Rappel Schadebedragen ........................................................................................................... 35 3.4.7 Stille Schade Inactiveren ........................................................................................................... 35 3.4.8 Besturing Tunen ......................................................................................................................... 35 3.4.9 Meldingtypen ............................................................................................................................... 36 3.5 UITZONDERINGSSITUATIES ......................................................................................................... 38 3.6 BERICHTVOLGORDE ................................................................................................................... 38 3.7 MANAGEMENTINFORMATIE ......................................................................................................... 38 3.7.1 Percentage Matches .................................................................................................................. 39 3.7.2 Doorlooptijd ................................................................................................................................. 39 3.7.3 Gebruik van Helpdesk................................................................................................................ 40 3.7.4 Diversen ....................................................................................................................................... 41 3.8 FACTUURTICKETS ...................................................................................................................... 43 3.9 MARGE SCHADEDATUM ............................................................................................................. 43 3.10 SPECIFIEKE FUNCTIONALITEIT T.B.V. RECHTSBIJSTANDVERZEKERAARS..................................... 44 3.10.1 Algemeen ..................................................................................................................................... 44

© 2015 ABZ / SEPS Clearinghuis Regres Functioneel Ontwerp v4.2

2/70

3.10.2 Berekening BGK ......................................................................................................................... 46 3.10.2.1 Filterfunctie als bewaking tegen de overschrijding van de termijn “laag tarief” ......... 46 3.10.3 Automatische berekening Wettelijke Rente ............................................................................ 47 HOOFDSTUK 4

INFORMATIEUITWISSELING ................................................................................ 49

4.1 BERICHTFORMATEN ................................................................................................................... 49 4.1.1 Regresmelding (CR)87001 ................................................................................................... 49 4.1.2 Regresdoormelding (CR)87002............................................................................................ 50 4.1.3 Aansprakelijkheidsmelding (CR)87003 ............................................................................... 50 4.1.4 Aansprakelijkheidsdoormelding (CR)87004 ....................................................................... 50 4.1.5 Rappel Aansprakelijkheid (CR)87005 ................................................................................. 51 4.1.6 Matchbericht (CR)87006 ....................................................................................................... 51 4.1.7 Melding Schadebedragen (CR) 87007 ................................................................................ 52 4.1.8 Afhandelbericht (CR) 87008 ................................................................................................. 54 4.1.9 Rappel Schadebedragen (CR) 87009 ................................................................................. 56 4.1.10 Afmelding (CR) 87010 ........................................................................................................... 56 4.1.11 Systeemmelding (CR) 87011 ................................................................................................ 56 4.2 PROTOCOL................................................................................................................................ 58 4.3 BERICHTSTRUCTUUR ................................................................................................................. 59 4.4 COMMUNICATIEPROTOCOL ......................................................................................................... 59 HOOFDSTUK 5

ENTITEITENMODEL ............................................................................................... 60

HOOFDSTUK 6

USER INTERFACE ................................................................................................. 62

6.1 ARCHITECTUUR ......................................................................................................................... 62 6.2 PRESENTATIECOMPONENTEN ..................................................................................................... 62 6.2.1 Overzichtsscherm ....................................................................................................................... 63 6.2.1.1 Sortering................................................................................................................................... 63 6.2.1.2 Indicatie Actiehouder.............................................................................................................. 63 6.2.1.3 Rappels .................................................................................................................................... 64 6.2.1.4 Reeds Geopend (Rood/Blauw)............................................................................................. 64 6.2.1.5 Scroll Bar ................................................................................................................................. 64 6.2.2 Nieuw Regres .............................................................................................................................. 65 6.2.3 Detailscherm ............................................................................................................................... 66 6.2.4 Overzicht Clearing ...................................................................................................................... 67 6.2.4.1 Sortering................................................................................................................................... 68 6.2.4.2 Indicatie Actiehouder.............................................................................................................. 68 6.2.4.3 Reeds Geopend (Rood/Blauw)............................................................................................. 68 6.2.5 Onderhoudschermen ................................................................................................................. 68 6.3 REACTIVITEIT ............................................................................................................................ 68 HOOFDSTUK 7 7.1 7.2

IMPACTANALYSE BETROKKEN PARTIJEN ....................................................... 69

AANSLUITEN VIA BROWSER-INTERFACE ...................................................................................... 69 AANSLUITING VIA XML-INTERFACE ............................................................................................. 70


3/70

Hoofdstuk 1 Inleiding Onder de naam ‘Stichting Efficiënte Processen Schadeverzekeraars’ (hierna te noemen: SEPS) werkt een aantal Nederlandse verzekeraars samen aan een verbetering van de afhandeling van regresschades. De traditionele processen bij verzekeraars voor het aansprakelijk stellen en regresvoering zijn zeer bewerkelijk: per schadegeval wordt er veel gecorrespondeerd en / of getelefoneerd. De doorlooptijden voor het afhandelen van de schade worden daardoor onnodig verlengd. De interne kosten van schadebehandeling zetten het resultaat van verzekeraars onder druk. Naar aanleiding van deze situatie is het idee ontstaan om de afhandeling van regresschades automatisch te ondersteunen met behulp van een clearinghuis applicatie.

1.1

Doelstelling Een van de doelen van SEPS is het sterk vereenvoudigen van het onderling verhalen van schades tussen deelnemende schadeverzekeraars door tussenkomst van het Clearinghuis Regres. Dit zorgt ervoor dat het melden van schades, het komen tot overeenstemming en (eventueel) het onderling betalingsverkeer eenvoudiger, sneller en goedkoper verlopen. SEPS heeft tot doel om over alle daartoe geschikte regresgevallen, de relatief eenvoudige zaken, snel en zonder tussenkomst van personen en zonder correspondentie tot overeenstemming te komen. Gestreefd wordt naar een 50% snellere doorlooptijd en een 50% efficiencywinst bij de afhandeling van regresschades. Voor afwikkeling binnen SEPS komen alleen schades in aanmerking, die voldoen aan onderstaande voorwaarden: 

het betreft alleen materiële en/of persoonlijke materiële schade;



bij de schade zijn twee motorvoertuigen betrokken (niet meer, niet minder);



er is sprake van een cascodekking bij tenminste één van de voertuigen;



het betreft voertuigen met een Nederlands kenteken;



er zijn alleen Nederlandse verzekeraars en/of gevolmachtigde tussenpersonen bij betrokken.

Initieel behandelde het Clearinghuis Regres alleen schades op grond van motorrijtuigenverzekeringen. Sinds enige tijd worden ook verhaalstransacties met rechtsbijstandverzekeraars en claimsservices afgehandeld via het Clearinghuis Regres. Deze transacties worden afgehandeld op basis van het gemene recht.

1.2

Gerelateerde Documenten Dit Functioneel Ontwerp is gebaseerd op reeds eerder opgestelde documenten en die worden dan ook als uitgangspunt gehanteerd. Document Businessplan Clearinghuis Businessplan Clearinghuis Bijlagen Request for Proposal Clearinghuis Regresschades Proposal Clearinghuis regresschades Functioneel Ontwerp Elektronisch Clearinghuis Regres – Voorstel Wijzigingsvoorstellen

Auteur Molenaar & Lok Consultancy ABZ Branche Initiatieven Molenaar & Lok Consultancy ABZ Branche Initiatieven Molenaar & Lok Consultancy

Datum 12 september 2001

ABZ Nederland B.V.

23 mei 2002

ABZ Branche Initiatieven B.V.

19 juli 2002

ABZ

Zie §1.3.


12 september 2001 8 mei 2002

4/70

Document CR requirementspecificaties Berekening BGK en wettelijke rente versie 1.5 Specificaties wijziging wettelijke rente

1.3

Auteur T. Kleijn

Datum 10 mei 2011

F. Kloosterman

2 november 2011

Versiebeheer Versie 1.2 1.3 1.4 1.5 1.6 1.7 1.8 2.0 2.10 3.0

Datum 7 oktober 2002 16 december 2002 16 januari 2003 23 januari 2003 7 maart 2003 10 juni 2003 11 augustus 2003 12 december 2005 17 augustus 2006 16 maart 2007

Auteur ABZ Erik Zuurbier Erik Zuurbier Erik Zuurbier Erik Zuurbier Erik Zuurbier Erik Zuurbier Erik Zuurbier Erik Zuurbier Erik Zuurbier

3.1

17 april 2007

Erik Zuurbier

3.2

3 juli 2007

Erik Zuurbier

Opmerkingen Goedgekeurd Diverse wijzigingen Diverse wijzigingen Diverse wijzigingen Diverse wijzigingen Diverse wijzigingen Correctie actiehouder Diverse wijzigingen Diverse wijzigingen  Diverse hoofdstukken die niet het functionele ontwerp betreffen, zijn verwijderd.  De functionaliteit is geïntegreerd voor driepartijenregres, nagekomen bedragen en extra bedragsoorten.  Details dienaangaande van de grafische user-interface moeten nog in het FO aangepast worden.  Wat voorheen een ‘ongeval’ werd genoemd, is nu ivm driepartijenregres in de meeste gevallen voor de duidelijkheid een ‘regres’ genoemd: er kunnen immers meerdere regressen per ongeval zijn.  Een correctie is aangebracht. In het schema in Hoofdstuk 7 is de rechtstreekse lijn tussen een BO-systeem en CR geschrapt. Die mogelijkheid heeft in werkelijkheid ook nooit bestaan. Het schema is hierheen verplaatst uit het hoofdstuk Architectuur dat is komen te vervallen.  Nagekomen bedragen weigeren als de andere verzekeraar nog niet gemigreerd is.  De volgorde van de controles is niet meer voorgeschreven (§3.4.1 t/m §3.4.4). Schermen van de browser-interface zijn geactualiseerd.


5/70

Versie 4.0

Datum 28 juni 2011

Auteur Teus Kleijn

4.1

28 december 2011

Feiko Kloosterman

Opmerkingen Nieuwe functionaliteit toegevoegd:  Als één van de regrespartijen een rechtsbijstandverzekeraar is, dan wordt automatisch de buitengerechtelijke kosten berekend  Als één van de regrespartijen een rechtsbijstandverzekeraar is, dan wordt automatisch de wettelijke rente berekend  (Eigen) schadenummer is te wijzigen t.b.v. interne routering van schadedossiers Gewijzigde functionaliteit toegevoegd met betrekking tot de berekening van de Wettelijke Rente:  Het wettelijk vastgestelde rentepercentage wordt per periode berekend.  De periode is het tijdsdeel waarover een gelijk wettelijk rentepercentage is vastgesteld.  Vanaf de matchingsdatum worden er twee extra dagen opgeteld bij het aantal dagen van de laatste periode.  Vervolgens worden de bedragen over de verschillende periodes bij elkaar opgeteld.


6/70

Hoofdstuk 2 Scope Het Clearinghuis Regres-systeem (CR-systeem) is een geautomatiseerd systeem voor het uitwisselen van informatie over verhaalschaden tussen verzekeraars en andere betrokken business-partijen en het verrekenen van de onderling te betalen bedragen. In dit hoofdstuk wordt de basisfunctionaliteit beschreven en tevens wordt het systeem duidelijk afgebakend. In Hoofdstuk 3 is een gedetailleerde uitwerking van de processen opgenomen.

2.1

Uitgangspunten De uitgangspunten van het CR-systeem zijn afgeleid van eerder opgestelde documenten en verder aangevuld na gesprekken met de betrokken partijen. Uitgangspunt Het betreft alleen ongevallen met materiële en/of persoonlijke schade.

Er zijn altijd twee motorvoertuigen bij het ongeval betrokken. De backoffice-koppelingen met verzekeraars vallen buiten het bouwtraject. Voor beveiliging wordt het Digitaal Paspoort van ABZ gebruikt. Managementinformatie zal alleen in elektronische vorm worden opgeleverd, in Excel™dan wel Word™-formaat. Elektronische communicatie met de verzekeraars zal via het bestaande berichtennetwerk verlopen, via AIMS. De fysieke betaling vindt plaats door de deelnemers en niet door het CR-systeem Er wordt geen koppeling gerealiseerd met de Stichting Proces Verbaal of de RDW. Er moet zowel een elektronische koppeling met het CR-systeem mogelijk zijn als toegang via een webinterface.

2.2

Toelichting Indien er bijvoorbeeld sprake is van letselschade kan de melding wel geregistreerd worden maar vindt slechts de afhandeling van de materiële schade plaats. Geen kettingbotsingen dus, maar ook geen botsingen met straatmeubilair Wel wordt een interface gedefinieerd.

Hiermee kan SEPS zelf rapportage verzorgen. Het grafisch presenteren van de informatie kan in een later stadium gerealiseerd worden. Alle verzekeraars hebben de beschikking over technologie om met AIMS te communiceren. Het CR-systeem zal alleen afhandelberichten versturen.

Gebruikers kunnen via berichten met het CR-systeem communiceren of via een webinterface.

Participanten Het CR-systeem kent een aantal betrokken partijen (participanten) en tevens een aantal rollen. De participanten zijn hieronder schematisch weergegeven.


7/70

Stichting Efficiënte Processen Schadeverzekeraars

Deelnemer (verzekeraar/ volmacht)

Ÿ Ÿ Ÿ Ÿ Ÿ Ÿ

Schademelding Aansprakelijkheid Meldingen Rappel Matchingsresultaat Afhandeling

Ÿ

Management informatie

Clearinghuis Regres Systeem

Ÿ Ÿ

Dossierinformatie Onderhouden stamtabellen

ABZ

De pijlen geven de stromen aan van de gegevens die het CR-systeem uitwisselt met de participanten. De participanten zijn.:

2.2.1



Deelnemer; dit is een verzekeraar (WA/Casco/Rechtsbijstand) of volmacht. Deze partij kan tevens de initiërende partij zijn van een actie binnen het CR-systeem.



ABZ; exploitant en functioneel beheerder van het CR-systeem.



SEPS; de stichting zal voornamelijk management informatie raadplegen en informatie downloaden om daaruit management informatie samen te stellen.

Rollen Er is bewust een onderscheid gemaakt tussen rollen en participanten(gebruikers) omdat de bovengenoemde participanten meerdere rollen kunnen vervullen. In onderstaande tabel zijn de verschillende rollen gedefinieerd. Welke personen binnen de participanten deze rollen gaan vervullen moet in een later stadium bepaald worden. Rol Melden van een regres Afmelden van een regres Opvoeren aansprakelijkheid Opvoeren schadebedrag Functioneel beheerder

Toelichting Een gebruiker kan een regresvoering starten. Een gebruiker kan een regres afbreken. Een gebruiker kan een aansprakelijkheid aangeven. Een gebruiker een schadebedrag opvoeren. De functioneel beheerder kan middels de browserinterface systeem specifieke onderdelen onderhouden. Management Informatie Een gebruiker kan management informatie opvragen. Wie in het autorisatieschema de rol ‘Melden van een regres’, ‘Afmelden van een regres’, ‘Opvoeren aansprakelijkheid’ en/of ‘Opvoeren schadebedrag’ heeft, mag ook op de ‘Verwerkt’knop drukken (zie §6.2).


8/70

1

De verzekeraars kunnen hun backoffice-systemen koppelen met het CR-systeem. In deze situatie krijgen zij volledige toegang tot het systeem zoals gedefinieerd in het communicatieprotocol (zie §4.2).

2.3

Korte Beschrijving CR Het CR-systeem is een systeem voor het elektronisch afhandelen van regres in het geval van schade waarbij twee motorvoertuigen betrokken zijn. Het systeem is alleen bedoeld voor schades die aan de voorwaarden van tabel 1, §2.1, voldoen. Wanneer de schade niet aan die eisen voldoet, wordt de schade niet door het CR-systeem verwerkt. Tevens zijn er uitzonderingssituaties die niet door het CR-systeem behandeld kunnen worden (deze staan beschreven in §3.5). Uit eerdere onderzoeken is gebleken dat het systeem onder bovengenoemde voorwaarden, minimaal 70% van de regresschades moet kunnen afhandelen. Het CR-systeem kent drie hoofdfuncties: 1. Aanmelden; Het aanmelden is het op de hoogte brengen van een verzekeraar dat er een schade is waarbij zij tegenpartij zijn. Dit betekent dat verzekeraars sneller geïnformeerd zijn en bijvoorbeeld contact kunnen leggen met de desbetreffende verzekerde. 2. Matchen; Het matchen is het op voorhand controleren in welke mate de verzekeraars het eens zijn over de (mate van) aansprakelijkheid. 3. Betalen; De betaling is het melden van de netto verschuldigde schadebedragen. In principe zou het CR-systeem zelf de verrekening tussen de verzekeraars onderling kunnen bijhouden via individuele rekening-courantverhoudingen. Op dit moment wordt met deze functionaliteit nog geen rekening gehouden omdat verschillende verzekeraars hebben aangegeven de betaling per geval zelf te willen initiëren in verband met de eisen die worden gesteld aan hun financiële boekhouding. In het volgende schema zijn de bovenstaande functies, stappen en stromen schematisch weergegeven. Verzekeraar-1

Schademelding

Stap Stap1

Schadebericht

Melden Melden Melden

Schadebericht

Verzekeraar- 1 Verzekeraar- 2

Schades

Verzekeraar-1

Stap Stap2

Verzekeraar-2

Aansprakelijkheid Aansprakelijkheid

Matchen Matchen Matchen

Voorstel

Verzekeraar- 1/2

Gematchte Schades

Stap Stap3

Verzekeraar1 1

Schadebedragen

Verzekeraar2 2

Schadebedragen

Betalen Betalen Betalen

Afhandeling

Verzekeraar- 1/2

1

Steeds waar in dit rapport ‘verzekeraar’ staat, worden daaronder ook gevolmachtigde tussenpersonen begrepen.


9/70

2.4

Basiswerking In §2.3 zijn de drie functies van het systeem gedefinieerd. Hieronder volgt nu een dieper uitwerking van het proces.

2.4.1

Beperking te Behandelen Regresschades De basis van het CR-systeem is een regresschademelding naar aanleiding van een ongeval. Wanneer een ongeval heeft plaatsgevonden zal (in geval van regres) de casco-verzekeraar van partij A de schade gaan verhalen op de WA-Verzekeraar van partij B. Tevens kan de casco-verzekeraar van partij B eventueel de schade verhalen op de WA-Verzekeraar van partij A. Beide verzekeraars zullen hun aansprakelijkheid kenbaar maken via de keuze uit een beperkte lijst 2 percentages . Alleen wanneer het totaal van beide aansprakelijkheden 100% is, spreken we van een match. In alle overige gevallen kan het CR-systeem geen acties ondernemen, en zal het systeem deze niet meer verwerken. Het CR-systeem zal een melding sturen naar beide verzekeraars. We kennen drie situaties die kunnen voorkomen: Soort Verzekering WA Casco

Situatie 1 Partij A Partij B X X

Situatie 2 Partij A Partij B X X X

Situatie 3 Partij A Partij B X X X X

Opmerking: Situatie 2 betekent ook dat Partij B een casco-verzekering kan hebben en Partij A alleen WA

Situatie 1 Beide partijen zijn alleen WA verzekerd. De verzekeraars zullen dan gewoonlijk geen regres voeren, want WA-verzekeraars keren niet aan hun eigen verzekerde uit om dat vervolgens bij 3 een andere verzekeraar terughalen . Situatie 2 Partij A is WA + Casco verzekerd en partij B is WA verzekerd. Dit betekent dat Verzekeraar A de schade kan verhalen op Verzekeraar B, maar niet andersom3. Het regres gaat dus alleen over het schadebedrag (€ 800,-) van partij A. Wanneer verzekeraar B de aansprakelijkheid van bijvoorbeeld 50% of 100% erkent, dan zal deze ook 50% respectievelijk 100% van het schadebedrag aan verzekeraar A uitkeren (dus €400,- of €800,-).

2

Voor de beeldvorming kan men denken aan 0%, 50% en 100%, maar de daadwerkelijke lijst is instelbaar door de systeembeheerder. Zie de toelichting bij entiteit ‘OVS/%’ in Hoofdstuk 5. 3

Het kan echter zijn dat de WA-verzekeraar een verhaal-service heeft of de verzekerde schakelt een rechtsbijstandverzekeraar in om zijn schade te verhalen op de WA-verzekering van de tegenpartij. Daar kan dan alsnog CR voorgebruikt worden.


10/70

WA-Verzekeraar A

WA-Verzekeraar B

Casco-Verzekeraar A

€ 800,- schade

€ 1500,- schade

Situatie 3 Zowel partij A als partij B zijn WA + Casco verzekerd. Beide verzekeraars kunnen nu regres voeren bij de tegenpartij. Belangrijk is dat het om één ongeval gaat met twee casco-verzekeraars. Het regres gaat nu over beide schadebedragen (€ 800,- en € 1500,-). Indien één van beide partijen een aansprakelijkheid van 100% erkent, dan zal deze partij het schadebedrag uitkeren aan de andere partij. Hierbij geldt wel dat het totaal van aansprakelijkheid 100% moet zijn. Wanneer beide partijen een aansprakelijkheid van 50% erkennen, worden beide schadebedragen evenredig verrekend. In onderstaand voorbeeld leidt dit tot de volgende verrekening: 

Verzekeraar A betaalt aan Verzekeraar B 50% van € 1500,- = € 750,-



Verzekeraar B betaalt aan Verzekeraar A 50% van € 800,- = € 400,-

In deze situatie kan het voorkomen dat beide casco-verzekeraars de schade melden. In dat geval moeten de twee meldingen worden samengevoegd door het systeem. De eerste melding wordt behouden en de tweede melding wordt door het CR-systeem gekoppeld aan de eerste. Deze samenvoeging kan op basis van de twee kentekens en de datum van het ongeval geschieden (het is tenslotte zeer onwaarschijnlijk dat twee voertuigen op dezelfde dag twee keer met elkaar in aanraking komen).

WA-Verzekeraar A

WA-Verzekeraar B

Casco-Verzekeraar A

Casco-Verzekeraar B

€ 800,- schade

€ 1500,- schade

Meer dan twee Verzekeraars 

De WA-Verzekeraar en de Casco-Verzekeraar van een partij zijn normaal gesproken gelijk. Indien deze verschillen, zijn er meer dan twee verzekeraars bij een ongeval betrokken. Daar zijn ook andere voorbeelden van: er is een aparte ladingverzekeraar, een inzittendenverzekeraar, een rechtsbijstandverzekeraar etc. Iedere betrokken verzekeraar bij een ongeval kan regres op een ander voeren. Dat men in de praktijk geen regres voert op rechtsbijstandverzekeraars of claim-services, is iets wat verzekeraars zelf moeten bewaken.


11/70

2.4.2

Melden Het begint bij een melding door één van de verzekeraars. Deze melding kan vanuit een back-office systeem van de verzekeraar komen, maar ook middels een browser-interface. De tegenpartij zal een melding krijgen dat regres zal worden gevoerd. De vervolgstap is het matchen. Het kan voorkomen dat de tegenpartij hetzelfde ongeval bij het CR-systeem wil melden. Het systeem moet voorkomen dat er een nieuwe melding wordt aangemaakt. Wel kunnen de gegevens van de tweede melder gebruikt worden om eventueel ontbrekende gegevens aan te vullen. Business Rules De onderstaande business rules gelden voor de functie ‘Melden’:

2.4.3



Voorkoming doublures: bij elke melding wordt door het CR-systeem gecontroleerd of het daadwerkelijk een nieuwe melding betreft.



Ongeval melding: de tegenpartij ontvangt een melding. Het is het informeren van de tegenpartij. Daarmee wordt nog geen uitspraak gedaan over de mate van aansprakelijkheid.

Matchen Nadat het CR-systeem een melding van het regres heeft ontvangen en gevalideerd, kan er gematched worden. Matchen betekent dat de twee betrokken verzekeraars beide hun aansprakelijkheid gaan aangeven. Zodra beide aansprakelijkheden zijn ontvangen, dan kan de matchmodule bepalen of het daadwerkelijk een match is.

Aansprakelijkheid

Aansprakelijkheid

Matchen Voorstel

Voorstel

Wel/geen match Nadat een verzekeraar een aansprakelijkheid aan het CR-systeem doorgeeft, wordt deze informatie middels een voorstel naar de tegenpartij gestuurd. De tegenpartij gebruikt deze informatie om zijn aansprakelijkheid beter te kunnen bepalen. Het mechanisme is dat één van beide partijen een aansprakelijkheid moet opgeven. Wanneer is er een match? Bij het aangeven van de aansprakelijkheid zijn de volgende gegevens belangrijk: 

OVS-code; deze code geeft de toedracht weer. Tevens bepaalt deze code het aansprakelijkheidspercentage.



Aansprakelijkheidspercentage. Dit percentage bepaalt uiteindelijk de aansprakelijkheid.

Er is een match wanneer beide partijen minimaal één aansprakelijkheid hebben ingestuurd en de som van de aansprakelijkheidspercentages 100% is. In alle andere situaties is er geen match. Rappel


12/70

Wanneer een van de partijen niet reageert op een melding (d.m.v. van een aansprakelijkheid) binnen een aangegeven tijd, dan wordt er een rappel naar de verzekeraar gestuurd. Na rappel gaat er een tweede termijn in. Escalatie Wanneer er geen match gevonden kan worden binnen de toegestane doorlooptijd, wordt de melding geannuleerd. Beide verzekeraars krijgen hierover een bericht. Business Rules De onderstaande business rules gelden voor de functie ‘Matchen’:

2.4.4



Termijnen: de periode waarbinnen de tegenpartij moet reageren op de melding is instelbaar. Indien een reactie uitblijft wordt er gerappelleerd. Dit geldt voor beide partijen. Na rappel dient binnen een vervolgtermijn te worden gereageerd. Ook deze laatste waarde is instelbaar.



Matchingvoorschriften: de aansprakelijkheid die een verzekeraar kan aangeven is een per4 centage uit een beperkte lijst . De percentages geven aan de mate waarin de verzekeraar zichzelf aansprakelijk acht.



Mismatch: er is geen sprake van een match wanneer het totaal van de twee aansprakelijkheden ongelijk is aan 100%.



Aansprakelijkheid: hoe vaak een aansprakelijkheid mag worden opgevoerd moet instelbaar zijn.

Betaling (Clearing) Nadat er een juiste match heeft plaatsgevonden en de schadebedragen van beide partijen bekend zijn, kunnen berichten naar de betrokken verzekeraars gestuurd worden met betrekking tot de hoogte van de betaling die moet worden gedaan c.q. kan worden tegemoet gezien. Dit houdt in dat de bedragen vooralsnog niet middels een rekening-courant systeem zullen worden verrekend. Deze functionaliteit kan later eventueel worden toegevoegd. Business Rules De onderstaande business rules gelden voor de functie ‘Betalen’:

2.5



Risico: het clearinghuis neemt bij de betaling geen financiële positie in.



De verzekeringsmaatschappijen krijgen per regres twee afhandelberichten, voor de schade van de eigen verzekerde en voor de schade van de tegenpartij. Daarna gaat er steeds naar beide verzekeraars een afhandelbericht wanneer er van een verzekeraar nagekomen bedragen binnenkomen.



Schadebedragen: voordat een afhandelbericht verstuurd kan worden, moeten de schadebedragen bekend zijn.

Koppelingen Externe Systemen (Interfaces) Het CR-systeem kent een aantal koppelingen met externe systemen. Deze kunnen we verdelen is twee soorten: 1. behorende bij het kernsysteem 2. externe koppelingen ter ondersteuning van service en diensten. De reden dat hier onderscheid gemaakt wordt tussen het kernsysteem en externe diensten heeft voornamelijk te maken met de generieke opzet van het CR-systeem. Door deze interfaces ook als zodanig te benoemen en te onderkennen, kan een betere ‘portability’ gerealiseerd worden.

4

Zie voetnoot 2 op pagina 9.


13/70

In onderstaand schema is te zien dat het CR-systeem diverse koppeling heeft met bestaande ABZ componenten. Dit zijn de externe services en diensten. Daarnaast vindt een berichtenuitwisseling plaats tussen het CR-systeem en de backoffice van de deelnemers. De XML berichten en de afhandeling hiervan valt binnen het CR-systeem. Het bouwen van koppelingen met de backoffices van verzekeraars vallen niet binnen de scope van dit project. Hiervoor zijn interfacebeschrijvingen beschikbaar.

Verzekeraar/ Volmacht

Back-office

Clearinghuis Regres

ABZ NASA componenten

LDAP


Data Warehouse

14/70

Hoofdstuk 3 Gedetailleerde Procesbeschrijving Dit hoofdstuk geeft een uitgebreide beschrijving van alle processen in het systeem. In §3.1 staat een flow-diagram dat in grote lijnen de werking van het CR-systeem verduidelijkt. In §3.2 wordt, uitgaande van de menselijke taken die bij regresvoering betrokken zijn een aantal veel voorkomende gevallen geanalyseerd. De verwerking binnen het CR-systeem daarbij is opgedeeld in procescomponenten die in §3.3 in detail zijn beschreven. De uitzonderingssituaties zijn afzonderlijk geresumeerd (§3.5). Het systeem verschaft managementinformatie, zoals beschreven in §3.7.

3.1

Flow Diagram In het volgende schema is de uitwisseling van berichten geschetst die plaats vindt tussen verzekeraars en het CR-systeem. Dit schema kan worden gebruikt om zich een beeld te vormen van de werking van het CR-systeem. Een aantal aspecten komen pas later aan de orde, zoals rappel-berichten en foutmeldingen. Zie daarvoor de detailbeschrijvingen in §3.2 en verder. We zien linksboven in het schema dat een verzekeraar, hier een casco-verzekeraar, een regres aanmeldt bij het CR-systeem, met ook de mogelijkheid om een voorlopig schadebedrag aan te geven. Berichtenverkeer is aangegeven met stippellijnen. Het CR-systeem meldt dit door aan de tegenpartij (rechts). Die stuurt eenzelfde soort bericht aan het CR-systeem, hetzij als bevestiging op de zojuist ontvangen regresmelding, hetzij naar aanleiding van een schadeaangifte door de eigen verzekerde. Deze tweede regresmelding wordt via het CR-systeem doorgegeven aan de verzekeraar links. Intussen kan de eerste verzekeraar doorgaan met de overige stappen van de regresvoering. De ononderbroken pijlen geven de tijdvolgorde aan. We zien daarbij dat iedere verzekeraar drie parallelle sporen kan volgen (aangegeven door de horizontale dubbele streep): 1. de onderhandeling over de wederzijdse aansprakelijkheidspercentages; 2. het vaststellen van de schadebedragen die men via het CR-systeem wil verhalen op de tegenpartij; 3. en het ontvangen van het afhandelbericht. Onderaan komen de drie sporen weer samen en dan kan de verdere verwerking van het regres in de eigen back-office verder gaan. Het linker van de drie genoemde sporen toont dat de verzekeraar de aansprakelijkheid van de eigen verzekerde kan melden, via een percentage, met daarbij eventueel de OVS-code. In het grijze blok ‘MATCHEN’ zien we dat dit aansprakelijkheidsbericht wordt ontvangen. Het CRsysteem stelt vast of inmiddels een match is bereikt (als beide verzekeraars hun aansprakelijkheid hebben gemeld en de som daarvan is 100%). Als dat nog niet zo is (de linker tak vanuit het wybertje) dan meldt het CR-systeem het ontvangen aansprakelijkheidsbericht door aan de tegenpartij. We komen dan terecht in de grijze kolom van de tegenpartij. Het ontvangen van een aansprakelijkheidsvoorstel is voor de tegenpartij reden om (nogmaals) zelf een aansprakelijkheid vast te stellen. We gaan dus in de rechterkolom via de lus omhoog. De tegenpartij stuurt dus zelf een aansprakelijkheidsvoorstel naar het CR-systeem. Dat wordt ontvangen in het middelste grijze blok ‘MATCHEN’. En weer controleert het CR-systeem of er inmiddels een match is bereikt. Als dat het geval is (som van de percentages is 100%) dan volgt via de onderste pijl uit het wybertje dat de match aan beide partijen wordt doorgemeld. Als er nog geen match bereikt was, zou het tegenvoorstel worden doorgestuurd naar de verzekeraar in de linker kolom, die nu nog een tweede kans zou hebben om een aansprakelijkheidsvoorstel te doen dat tot een match zou leiden. Als dit te lang duurt of de verzekeraars komen ook in tweede instantie niet tot een vergelijk, dan beslist het CR-systeem dat het regres definitief niet via het CR-systeem gevoerd kan worden (rechter pijl vanuit het wybertje in het grijze blok ‘MATCHEN’).


15/70

Maar we gaan er even vanuit dat er een match bereikt wordt. Op ieder moment na het aanmelden van een regres kan een betrokken verzekeraar de schadebedragen van de eigen verzekerde melden en die hij (gedeeltelijk) wil verhalen op de tegenpartij: de middelste verticale sporen in de grijze kolommen. Wanneer het CR-systeem zo’n melding heeft ontvangen én er is al een match bereikt, dan wordt naar beide partijen een afhandelbericht verstuurd. Hieruit volgt ook dat als er nooit een match bereikt wordt, dat ook de definitieve schadebedragen niet worden 5 geopenbaard aan de tegenpartij . We willen benadrukken dat dit schema slechts de hoofdlijnen behandelt. Uitzonderingsgevallen (zie ook §3.5) zouden het schema onleesbaar ingewikkeld maken.

5

Bij het aanmelden is wel het voorlopige schadebedrag uitgewisseld.


16/70

CLEARINGHUIS REGRES

CASCO-VERZEKERAAR

TEGENPARTIJ

Begin

MELDEN

ongevalmelding ontvangen

ongeval melden

ongeval melden

MATCHEN aansprakelijkheid ontvangen

aansprakelijkheid melden

aansprakelijkheid melden

match? nog niet voorstel doormelden naar tegenpartij

ja

ja

match melden aan beide partijen

nogmaals?

definitief niet

definitieve afwijzing melden

ja

nogmaals?

BETALEN schadebedragen melden

schadebedragen ontvangen

schadebedragen melden nee

reeds def. bedragen ontvangen?

afhandelbericht(en) ontvangen

ja

match bereikt?

afhandelberichten versturen

verwerken in backoffice

Einde

3.2



Einde

Use Cases Hier is via zogenaamde use-cases de regresvoering beschreven vanuit de gezichtspunten van de verzekeraars. De schema’s kunnen van boven naar beneden gelezen worden, waarbij de pijlen aangeven in welke richting er berichten gestuurd worden. Voor details over de werking van het CR-systeem wordt in de middelste kolom gerefereerd aan de beschrijvingen van de procescomponenten (§3.3). Voor de software-bouwers bevat dit hoofdstuk geen nieuwe functionele informatie. Dit hoofdstuk moet alleen worden gezien als animatie van §3.3.


17/70

3.2.1

Eenvoudige Regresvoering Verzekeraar A 1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.

CR 

Verzekeraar B

§3.4.1

 §3.4.1

2c) Ontvangt gegevens over het regres.



3) Stuurt voorstel OVS-code/% in.



§3.4.3

5) Stuurt schadebedragen eigen verzekerde in



§3.4.4 §3.4.3

7) Ontvangt matchbericht



8) Ontvangt afhandelbericht

 



4) Ontvangt voorstel OVS-code/%



6) Stuurt eigen voorstel OVS-code/% in, dat overeenkomt met dat van verzekeraar A. 7) Ontvangt matchbericht, mits er sprake is van 50/50 en geen sprake van Rechtsbijstand 8) Ontvangt afhandelbericht 9) Stuurt schadebedragen eigen verzekerde in 10) Ontvangt afhandelbericht, geldt niet bij rechtsbijstandverzekeraars



§3.4.4 10) Ontvangt afhandelbericht, geldt niet bij rechtsbijstandverzekeraars



2a) Ontvangt gegevens over het regres. 2b) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer. Dit bericht is niet verplicht en wordt juist ingestuurd om het eigen schadenummer te koppelen aan dit dossier.

  

We zien dat verzekeraar A begint met gegevens over het regres in te sturen (1). Het CR-systeem stuurt die onmiddellijk door naar de tegenpartij (2a). Deze bevestigt de ontvangst en stuurt eigen gegevens in (2b), die ook worden doorgestuurd aan verzekeraar A (2c). Daarna begint één van de verzekeraars met het insturen van een aansprakelijkheidsvoorstel (OVS-code/%); hier is dat toevallig verzekeraar A (3). Het CR-systeem stuurt dat onmiddellijk door naar de tegenpartij (4). Op een willekeurig moment na het melden van het regres, stuurt verzekeraar A de schadebedragen van de eigen verzekerde in (5). Omdat er nog geen match is worden die nog niet doorgestuurd naar de tegenpartij. Verzekeraar B is aan de beurt om een OVS-code/% voor te stellen. In dit geval komen de interpretaties van de partijen met elkaar overeen (6). Daarom signaleert het CR-systeem naar beide verzekeraars dat er een match is (7) en onmiddellijk gaat ook het afhandelbericht (met schadebedragen van partij A) door naar verzekeraar B (8) en een soortgelijk bericht naar verzekeraar A (8). Op een willekeurig moment na het melden van het regres, stuurt verzekeraar B de schadebedragen van de eigen verzekerde in, hier toevallig na de match (9). Omdat er al een match is, stuurt het CR-systeem het afhandelbericht (met schadebedragen van partij B) door naar verzekeraar A (10) en een soortgelijk bericht naar B (10).


18/70

3.2.2

Verkeerde Tegenpartij Verzekeraar A

CR

4) Ontvangt gegevens over regres. 5) Ontvangt voorstel OVS-code/%

 

6) Meldt het regres af: A meent geen tegenpartij te zijn.



Verzekeraar B

§3.4.1



§3.4.3 §3.4.4

 

1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer. 2) Stuurt voorstel OVS-code/% in. 3) Stuurt schadebedragen eigen verzekerde in

§3.4.2 

7) Ontvangt afmelding inclusief reden afmelding

We zien hier dat verzekeraar B in één keer het regres meldt (1), zelf een voorstel doet voor de aansprakelijkheidsverdeling (2) en meteen ook de schadebedragen van de eigen verzekerde doorgeeft (3). Het CR-systeem stuurt de eerste twee daarvan meteen door naar de tegenpartij (4 en 5). De schadebedragen worden nog niet aan verzekeraar A gemeld omdat er nog geen match is. Na intern onderzoek komt verzekeraar A tot de conclusie dat zijn cliënt geen partij is geweest in het regres. Misschien is er een schrijffout in het kenteken voorgevallen. Verzekeraar A meldt dit aan het CR-systeem (6). Dit wordt doorgestuurd aan verzekeraar B (7). Die kan nu nader onderzoek doen en het regres opnieuw melden met de juiste tegenpartij, of het regres verder buiten het CR-systeem om afhandelen.


19/70

3.2.3

Bod met Tegenbod Verzekeraar A

CR

1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.



§3.4.1




§3.4.3

§3.4.3




7) Stuurt eigen voorstel OVS-code/% in, dat overeenkomt met het laatste voorstel van B. 8) Ontvangt matchbericht



§3.4.4 

11) Stuurt schadebedragen eigen verzekerde in. 12) Ontvangt afhandelbericht geldt niet bij rechtsbijstandverzekeraars

 



2) Ontvangt gegevens over regres.






5) Stuurt eigen voorstel OVS-code/% in, dat niet overeenkomt met dat van verzekeraar A.



8) Ontvangt matchbericht



9) Stuurt schadebedragen eigen verzekerde in 10) Ontvangt afhandelbericht

§3.4.3



10) Ontvangt afhandelbericht

Verzekeraar B

 §3.4.4 

12) Ontvangt afhandelbericht (optioneel) geldt niet bij rechtsbijstandverzekeraars

We zien dat verzekeraar A het regres aanmeldt (1) en het CR-systeem meldt dit door aan de tegenpartij (2). In dit specifieke geval stuurt verzekeraar géén bevestiging - het CR-systeem kan zonder en de tegenpartij moet het dan doen zonder voorlopig schadebedrag en zonder schadenummer van de tegenpartij. De match begint als in §3.2.1. Echter, het eerste tegenvoorstel van partij B komt niet overeen met dat van partij A (5). Dat tegenvoorstel wordt door het CR-systeem doorgestuurd naar verzekeraar A (6). Deze reageert met een tweede voorstel dat nu overeenstemt met het tegenvoorstel van verzekeraar B (7). Daarop meldt het CR-systeem de match naar beide partijen (8). Toevallig sturen de verzekeraars nu pas na de match schadebedragen van de eigen verzekerde in (9 en 11). Het CR-systeem stuurt ze onmiddellijk door als een afhandelbericht naar beide partijen (10 en 12).


20/70

3.2.4

Termijn Verloopt Verzekeraar A 1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.

CR 

Verzekeraar B

§3.4.1

 §3.4.1

2c) Ontvangt gegevens over het regres. 3) Stuurt voorstel OVS-code/% in.

7) Ontvangt bericht dat het regres definitief niet wordt gematcht



2a) Ontvangt gegevens over het regres. 2b) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.

 



§3.4.3 

4) Ontvangt voorstel OVS-code/% van verzekeraar A.

§3.4.5



5) Ontvangt rappel om voorstel OVS-code/% in te sturen

§3.4.5



6)Ontvangt rappel om voorstel OVScode/% in te sturen

§3.4.7



7) Ontvangt bericht dat het regres definitief niet wordt gematcht

Het melden verloopt als in §3.2.1. Daarna begint één van de verzekeraars met het insturen van een aansprakelijkheidsvoorstel (OVS-code/%); hier is dat toevallig verzekeraar A (3). Het CRsysteem stuurt dat onmiddellijk door naar de tegenpartij (4). Er verloopt daarna een instelbare tijd waarbinnen verzekeraar B ook de aansprakelijkheid kan melden. Daarom stuurt het CR-systeem een rappel (5). Weer verloopt een termijn en het CR-systeem stuurt nogmaals een rappel (6). Intussen verloopt ook een instelbare termijn waarbinnen de aansprakelijkheid van verzekeraar B binnen moet zijn - onafhankelijk van rappels. Daarom stuurt het CR-systeem op een gegeven moment een definitieve non-match naar beide verzekeraars (7). Daarop kunnen de betrokken verzekeraars besluiten om het regres buiten het CR-systeem om te voeren, of het regres opnieuw aan te melden.


21/70

3.2.5

Termijn Schadebedrag Verloopt Verzekeraar A 1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.

CR 

Verzekeraar B

§3.4.1

 §3.4.1

2c) Ontvangt gegevens over het regres. 3) Stuurt voorstel OVS-code/% in.

 

§3.4.3




§3.4.4








6) Stuurt eigen voorstel OVS-code/% in, dat overeenkomt met dat van de verzekeraar A. 7) Ontvangt matchbericht, mits er sprake is van 50/50 en geen sprake van Rechtsbijstand 8) Ontvangt afhandelbericht

§0



9) Ontvangt rappel schadebedrag

§0



10) Ontvangt rappel schadebedrag

§3.4.7



11) Ontvangt bericht dat het regres definitief niet geheel afgehandeld wordt.

§3.4.3

7) Ontvangt matchbericht, mits er sprake is van 50/50 en geen sprake van Rechtsbijstand 8) Ontvangt afhandelbericht











Hier loopt de afhandeling in het begin precies zoals in §3.2.1. Echter, nadat beide verzekeraars een matchbericht hebben ontvangen (7) en afhandelberichten omdat verzekeraar A de schadebedragen al had gemeld (8), blijft het stil aan de kant van verzekeraar B. Nadat de termijn verloopt voor het melden van de schadebedragen van de eigen verzekerde, stuurt het CR-systeem een rappel (9). Dat gebeurt zelfs een tweede keer (10). Intussen verloopt een algemene termijn waarbinnen partijen van zich moeten laten horen, en stuurt het CR-systeem een bericht daarover (11). Verzekeraar B heeft voldoende informatie om te betalen; verzekeraar A nog niet. Het is in het belang van verzekeraar B om de bedragen alsnog te melden, maar nu buiten het CRsysteem om.


22/70

3.2.6

Geen Overeenkomst Verzekeraar A 1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer. 3) Stuurt voorstel OVS-code/% in.

CR 

§3.4.1

 

§3.4.3

§3.4.3

6) Ontvangt tegenvoorstel OVScode/% van partij B.



7) Stuurt eigen voorstel OVS-code/% in, dat niet overeenkomt met het laatste voorstel van B. 8) Ontvangt bericht dat het regres definitief niet geheel afgehandeld wordt.

 

Verzekeraar B



2) Ontvangt gegevens over regres.






5) Stuurt eigen voorstel OVS-code/% in, dat niet overeenkomt met dat van verzekeraar A.




§3.4.3

In dit geval loopt het grotendeels als in §3.2.3. Echter, het tweede voorstel van A (7) stemt nog steeds niet overeen met het tegenvoorstel van verzekeraar B. Daarop meldt het CR-systeem aan beide partijen dat het maximum aantal aansprakelijkheidsvoorstellen (zijnde 3) voor het bereiken van een match niet gerespecteerd is (8).


23/70

3.2.7

Driepartijenregres De benaming ‘driepartijenregres’ is gekozen voor gevallen waarbij meer dan twee verzekeraars betrokken zijn. Het is dan wel steeds een tweetal verzekeraars die met elkaar een transactie aangaan, maar bij hetzelfde ongeval kunnen dat meerdere tweetallen zijn, bijvoorbeeld een WA-cascoverzekeraar, een WA-verzekeraar en een rechtsbijstandverzekeraar. Het is mogelijk dat bij een schade meer dan twee verzekeraars betrokken zijn en er ook meerdere regresgevallen worden afgehandeld. Een voorbeeld is dat één van de betrokken automobilisten een rechtsbijstandverzekeraar inschakelt. Hieronder volgt een voorbeeld met de volgende rolverdeling: 

A heeft een WA-verzekering en een rechtsbijstandverzekering (bij een andere maatschappij).



B heeft een WA-casco-verzekering

Er vindt een aanrijding plaats waarbij uiteindelijk beide partijen 50/50 aansprakelijk zijn voor de schade van de tegenpartij. Echter, de WA-verzekeraar van B kent in eerste instantie niet de schade van de eigen verzekerde. Rechtsbijstandverzekeraar van A 1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.

CR 

WA-casco-verzekeraar van B

§3.4.1

 §3.4.1




3) Stuurt voorstel OVS-code/% in, stel dit is 50/50.






§3.4.3

 



4) Ontvangt voorstel OVS-code/% van de rechtsbijstandverzekeraar van A.



6) Stuurt eigen voorstel OVS-code/% in, dat overeenkomt met dat van de rechtsbijstandverzekeraar van A (dus ook 50/50). 7) Ontvangt matchbericht 8) Ontvangt afhandelbericht met de schadebedragen van de Rechtsbijstandverzekeraar van A

§3.4.4 §3.4.3

7) Ontvangt matchbericht 8) Ontvangt afhandelbericht




 


24/70

Rechtsbijstandverzekeraar van A 9) Ontvangt afhandelbericht

CR 

WA-casco-verzekeraar van B 

9) Ontvangt afhandelbericht De WA-Casco verzekeraar hoeft geen schadebedragen te sturen omdat deze bedragen per definitie € 0,00 (op een rechtsbijstandverzekeraar kun je niets verhalen). Evt. ontvangen schadebedragen worden door het CR-systeem genegeerd.

Met uitzondering van stap 9 is het bovenstaande inhoudelijk identiek aan het verloop dat is geschetst in §3.2.1 op pagina 18. Daarna, of misschien wel (deels) gelijktijdig, voert ook de WA-cascoverzekeraar van B het schadegeval in, om de schadebedragen van de eigen verzekerde te verhalen: WA-casco-verzekeraar van B 1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.

CR 

WA-verzekeraar van A

§3.4.1

 §3.4.1










§3.4.3

 



4) Ontvangt voorstel OVS-code/% van de WA-casco-verzekeraar van B.



6) Stuurt eigen voorstel OVS-code/% in, dat overeenkomt met dat van de WA-casco-verzekeraar van B. 7) Ontvangt matchbericht, mits er sprake is van 50/50 en geen sprake van Rechtsbijstand 8) Ontvangt afhandelbericht 9) Stuurt schadebedragen in: € 0.(schade van de eigen verzekerde is al afgehandeld via de rechtsbijstandverzekeraar). 10) Ontvangt afhandelbericht geldt niet bij rechtsbijstandverzekeraars



§3.4.4

10) Ontvangt afhandelbericht geldt niet bij rechtsbijstandverzekeraars



§3.4.4 §3.4.3





 



Inhoudelijk is het bovenstaande identiek aan het verloop dat is geschetst in §3.2.1 op pagina 18.


25/70

3.2.8

Nagekomen bedragen Verzekeraar A 1) Back-office stuurt gegevens over regres in: datum, kentekens, polisnummers, WAM-code tegenpartij en eventueel voorlopig schadebedrag en schadenummer.

CR 

Verzekeraar B

§3.4.1

 §3.4.1










§3.4.3

  





6) Stuurt eigen voorstel OVS-code/% in, dat overeenkomt met dat van verzekeraar A. 7) Ontvangt matchbericht, mits er sprake is van 50/50 en geen sprake van Rechtsbijstand 8) Ontvangt afhandelbericht 9) Stuurt schadebedragen eigen verzekerde in 10) Ontvangt afhandelbericht geldt niet bij rechtsbijstandverzekeraars 11) Stuurt nog meer schadebedragen eigen verzekerde in 12) Ontvangt afhandelbericht (optioneel)

  

§3.4.4 12) Ontvangt afhandelbericht (optioneel)

4) Ontvangt voorstel OVS-code/% van verzekeraar A.



§3.4.4 10) Ontvangt afhandelbericht geldt niet bij rechtsbijstandverzekeraars

 §3.4.4 §3.4.3





 

Inhoudelijk zijn in het bovenstaande de eerste 10 stappen identiek aan die geschetst in §3.2.1 op pagina 18. Het verschil zit hem in de stappen 11 en 12 die er nu nog achteraan komen. In dit geval ontdekt verzekeraar B na verloop van tijd dat zijn eigen verzekerde nog meer schade heeft geleden dan eerder was gebleken. Bijvoorbeeld een nagekomen factuur van een autoverhuurbedrijf (vervangend vervoer). In stap 12 is te zien dat nu extra afhandelberichten, ter grote van het extra bedrag, worden verstuurd naar beide verzekeraars. Er zijn meer mogelijkheden en beperkingen. Die worden uitgelegd in §3.4.4 op pagina 32.

3.3

Procescomponenten Algemeen De procescomponenten zijn zogenaamde event handlers. Een event handler is (de beschrijving van) een stuk software dat de complete afhandeling van een event doet. De term compleet betekent hier dat er binnen een event-handler geen momenten zijn dat er nog gewacht wordt, bijvoorbeeld op input. Een event is doorgaans de binnenkomst bij het CR-systeem van een bericht van een verzekeraar, maar ook het verlopen van een termijn kan een event zijn. Bij iedere event-handler wordt beschreven wat de event is, en wat de actie van het CR-systeem is als de event optreedt. De verschillende event-handlers werken samen om zo het gewenste systeemgedrag vorm te geven. Die samenhang is geïllustreerd in §3.2.


26/70

Let op: De in 3.4 beschreven procescomponenten geven de algemene werking van het CR-systeem weer. Wanneer één van de regrespartijen een Rechtsbijstandverzekeraar is, gelden een aantal uitzonderingen. Deze uitzonderingen zijn beschreven in Error! Reference source not found. 3.3.1

Basiscontroles Algemeen punt: Steeds wanneer een inkomend bericht van een verzekeraar behandeld wordt, voert het CR-systeem basiscontroles uit. Als daaruit fouten blijken, gaat er een foutmelding naar de afzender, met nauwkeurige informatie over wat het probleem is (meldingtype 11, zie §3.4.9) en wordt het bericht verder niet behandeld binnen het CR-systeem.

3.3.2

Identificatie Tegenpartij uit WAM-volmachtcode Bij ieder binnenkomend bericht wordt de identificatie van de tegenpartij als volgt omgevormd om volmachten en afdelingen binnen verzekeraars goed te kunnen verwerken. Als Dan Anders

3.3.3

de WAM-code gevolgd door de volmachtcode samen de identificatie van een bekende partij binnen het CR-systeem vormt blijft deze WAM-volmacht-code ongewijzigd. Als de 0000 gevolgd door de volmachtcode (dus bij het negeren van de opgegeven WAM-code) de indentificatie van een bekende partij binnen het CR-systeem vormt Dan wordt de tegenpartij in de verdere verwerking geïdentificeerd door 0000 gevolgd door de opgegeven volmachtcode Anders (zie meldingtype 11, zie §3.4.9, vervolgens §4.1.11, V3)

Mogelijke Statussen van een Regres In de beschrijvingen hierna kan een regres in het CR-systeem in de volgende statussen verkeren. Status Open

Gematcht

Inactief Afrekenen

Afgehandeld 3.3.4

Omschrijving Er zijn eventueel aansprakelijkheidsvoorstellen uitgewisseld, maar dat heeft nog niet geleid tot de constatering dat er een match is, en ook niet dat er definitief geen match komt. Er is vastgesteld dat de betrokken verzekeraars het eens zijn over de verdeling van de aansprakelijkheden, maar er zijn nog geen schadebedragen uitgewisseld via afhandelberichten. Er is vastgesteld dat er definitief geen verdere afhandeling komt via het CRsysteem. Mogelijk is al wel een match bereikt. Er is vastgesteld dat de betrokken verzekeraars het eens zijn over de verdeling van de aansprakelijkheden, en minstens één stel schadebedragen is uitgewisseld via een afhandelbericht. De regresvoering is volledig afgehandeld.

Volgorde van Controles Procescomponenten/event-handlers die een binnenkomend bericht afhandelen (§3.4.1, §3.4.2, §3.4.3, §3.4.4) beginnen met een aantal controles op dat bericht. Bij een geconstateerde fout wordt een foutboodschap gerapporteerd en is de verwerking klaar. De controles staan in een bepaalde volgorde beschreven maar dat is niet noodzakelijk de volgorde waarin de controles daadwerkelijk worden uitgevoerd. Als dus in een binnenkomend bericht meerdere fouten zitten, wordt daar slechts één van geconstateerd. Maar welke dat dan is, wordt in dit document niet gespecificeerd. Dit schept enige vrijheid om de architectuur van de software te optimaliseren.


27/70

3.4

Individuele Procescomponenten

3.4.1

Regres Melden Event

Actie

Er komt een schademelding (bijvoorbeeld een SAF) binnen bij een verzekeraar en deze verzekeraar heeft vastgesteld dat mogelijk regres gevoerd gaat worden op de verzekeraar van de tegenpartij. De eerste verzekeraar stuurt een regresmelding naar het CR-systeem (meldingtype 1, zie §3.4.9). Controles in willekeurige volgorde (verwerking stopt na het vinden van één fout):  Voor elke van de twee betrokken verzekeraars (partij, tegenpartij) geldt: als de verzekeraar backoffice-koppelaar is en nog niet gemigreerd (§3.4.8) dan mag er nog geen regres bestaan met een status anders dan ‘inactief’ met deze combi6 natie van kentekens en schadedatum waar deze verzekeraar partij in is en dat hij al gemeld/bevestigd had (entiteitenmodel ‘Bevestigd’ = ja) . Als hieraan niet voldaan is, wordt dat teruggemeld aan de melder (meldingtype 24).  Als er al een regres bestaat met een status anders dan ‘inactief’ met deze combinatie van kentekens en schadedatum6 waar beide verzekeraars (partij, tegenpartij) partij in zijn en dat de nu meldende verzekeraar al gemeld/bevestigd had (entiteitenmodel ‘Bevestigd’ = ja), wordt dat teruggemeld aan de melder (meldingtype 25).  Als de WAM-code van de tegenpartij onbekend is in het CR-systeem, dan wordt dit teruggemeld aan de aanmelder (meldingtype 12). Als geen fouten worden gevonden:  Als het regres al bekend is met status ‘inactief’, dan wordt dit (oude) regres in zijn geheel uit het CR-systeem verwijderd, dus met de gerelateerde vóórkomens van ‘Voertuigschade’ en ‘Standpunt’ (zie Hoofdstuk 5).  Als er nu nog steeds een bekend regres in het systeem zit (dus niet met de status ‘inactief’, en dus ook met ‘Bevestigd’ = nee voor de nu meldende verzekeraar), dan wordt het bestaande regres bijgewerkt voor de betreffende verzekeraar: ‘Bevestigd’ := ja.  Anders wordt het (nieuwe) regres geregistreerd in het CR-systeem. De status = open.  Als een geheel nieuw regres gemeld is, wordt voor beide verzekeraars Actiehouder=Ja (met actuele Datum/tijd Actiehouder), anders (bij de bevestiging van een reeds eerder gemeld regres) blijft Actiehouder voor beide verzekeraars ongewijzigd.  Als en geheel nieuw regres gemeld is, wordt voor de meldende verzekeraar Reeds geopend = Ja, anders Nee.  Voor de tegenpartij (de niet meldende verzekeraar) wordt Reeds geopend = Nee.  Het (nieuwe) regres wordt doorgemeld aan de tegenpartij (meldingtype 2).  Als een geheel nieuw regres gemeld is, wordt een aanmeldticket gegenereerd. Zie §3.8. Zie ook §3.6 Berichtvolgorde op pagina 38.

6

Opgegeven schadedatum binnen ingestelde datum-marge (zie §3.9) van reeds bekende Ongevaldatum in entiteit Regres.


28/70

3.4.2

Regres Afvoeren Event

Actie

Een verzekeraar ziet ervan af om dit regres via het CR af te wikkelen. Dit kan alleen 7 onder opgave van een vooraf gedefinieerde reden. Redenen kunnen bijvoorbeeld zijn dat de aangesproken ‘tegenpartij’ beweert niet daadwerkelijk partij te zijn in het regres, of er blijkt dat men niet tot een match kan komen (meldingtype 10). Controles in willekeurige volgorde (verwerking stopt na het vinden van één fout):  Als de inzendende verzekeraar backoffice-koppelaar is en nog niet gemigreerd (§3.4.8), dan mag het veld ‘WAM-code tegenpartij’ (zie §4.1.10 op pagina 56) niet aanwezig zijn. Als dat toch het geval is wordt dat gemeld aan de indiener (meldingtype 27).  Als de inzendende verzekeraar backoffice-koppelaar is en al wel gemigreerd (§3.4.8), dan moet het veld ‘WAM-code tegenpartij’ (zie §4.1.10 op pagina 56) aanwezig zijn. Als dat niet het geval is wordt dat gemeld aan de indiener (meldingtype 27).  Als het betreffende regres onbekend is in het CR, of status ‘inactief’ of ‘afrekenen’ heeft dan wordt de melding geweigerd, en dat wordt gemeld aan de indiener (meldingtype 13).  Als de indienende verzekeraar in het CR niet staat genoteerd als partij bij het regres, dan wordt de melding geweigerd, en dit wordt terug gemeld aan de indiener (meldingtype 14). Als geen fouten worden gevonden:  Het regres krijgt de status ‘inactief’ en dat wordt gemeld aan de tegenpartij (meldingtype 21). De verzekeraar die het regres afvoert, krijgt Actiehouder = 8 Nee . De tegenpartij krijgt Actiehouder = Ja (Datum/tijd Actiehouder wordt ook geactualiseerd) en Reeds geopend = Nee. Hierna kunnen de verzekeraars nader onderzoek doen en de schade eventueel opnieuw melden, dan wel het regres buiten het CR-systeem afhandelen.

7

‘Vooraf gedefinieerd’ = voordat het systeem in productie gaat. De precieze waarden zijn bij de bouw van het systeem echter niet van belang. Technisch: ze kunnen bijvoorbeeld in een database-tabel of een INI-file staan die door de systeembeheerder kan worden bijgewerkt. 8

De motivatie is dat de daad van het afvoeren van het regres te beschouwen is als onderdeel van het verwerken in de eigen backoffice. Het is waarschijnlijk teveel van het goede om de ‘afvoerende verzekeraar’ te vragen dan ook nog eens op de ‘Verwerkt’-knop te drukken.


29/70

3.4.3

Matchen Event

Actie

9

Een betrokken verzekeraar stelt intern een OVS-toedrachtscode, een voorgestelde aansprakelijkheidsverdeling en eventueel een toelichting/commentaar vast, op basis van intern onderzoek en eventueel een eerder voorstel van de tegenpartij. De verzekeraar meldt het eigen voorstel aan het CR (meldingtype 3). Controles in willekeurige volgorde (verwerking stopt na het vinden van één fout):  Als de inzendende verzekeraar backoffice-koppelaar is en nog niet gemigreerd (§3.4.8), dan mag het veld ‘WAM-code tegenpartij’ (zie §4.1.3 op pagina 50) niet aanwezig zijn. Als dat toch het geval is wordt dat gemeld aan de indiener (meldingtype 27).  Als de inzendende verzekeraar backoffice-koppelaar is en al wel gemigreerd (§3.4.8), dan moet het veld ‘WAM-code tegenpartij’ (zie §4.1.3 op pagina 50) aanwezig zijn. Als dat niet het geval is wordt dat gemeld aan de indiener (meldingtype 27). 9  Als het betreffende regres niet bekend is in het CR-systeem , of een status anders dan ‘open’ heeft, dan wordt het nieuwe voorstel geweigerd en dat wordt gemeld aan de indiener (meldingtype 17).  Als de betreffende verzekeraar geen partij is bij dit regres, dan wordt het nieuwe voorstel geweigerd, waarvan melding gemaakt wordt aan de indiener (meldingtype 15).  Als er al eerder één of meer aansprakelijkheidsvoorstellen over dit regres zijn binnengekomen bij het CR en de laatste in die rij is van deze zelfde verzekeraar afkomstig, dan wordt het nieuwe voorstel geweigerd, waarvan melding gemaakt wordt aan de indiener (meldingtype 16).  Als de tegenpartij een rechtsbijstandverzekeraar is en deze heeft nog geen aansprakelijkheidsvoorstel ingediend, dan wordt het ingediende aansprakelijkheidsvoorstel van de casco-verzekeraar geweigerd, omdat in deze situatie de Rechtsbijstandverzekeraar moet starten in het matching proces i.v.m. de termijnbepaling BuitenGerechtigde Kosten (BGK). Er wordt in dat geval een melding (meldingtype 16) gestuurd naar de indiener (=casco verzekeraar)

Zie §3.6 Berichtvolgorde op pagina 34.


30/70

Als geen fouten worden gevonden:  Als het nieuwe voorstel het allereerste is voor dit regres, wordt het doorgestuurd naar de tegenpartij (meldingtype 4). De verzekeraar die het voorstel doet, krijgt Actiehouder = Nee. De tegenpartij krijgt Actiehouder = Ja (Datum/tijd Actiehouder wordt ook geactualiseerd) en Reeds geopend = Nee.  Anders, als dit nieuwste voorstel samen met het laatst binnengekomen voorstel van de tegenpartij een match vormt (aansprakelijkheden samen 100%), wordt naar beide partijen de match gemeld (meldingtype 6) en krijgt het regres de status ‘gematcht’. Elk stel reeds ontvangen schadebedragen (meldingtype 7) wordt bovendien doorgemeld aan beide partijen in een afhandelbericht (meldingtype 8). Ook: als een verzekeraar zichzelf bij de match 100% aansprakelijk achte en nog geen schadebedragen had ingediend, worden die geacht € 0,- te zijn (hij zal immers geen regres voeren) en dat wordt dan ook gemeld (meldingtype 8). Als hiermee van beide partijen de schadebedragen zijn doorgemeld, krijgt het regres de status ‘afgehandeld’, anders (slechts van één partij de schadebedragen doorgemeld) gebeuren er twee dingen: de status wordt ‘afrekenen’ en voor het regres wordt een afhandelticket gegenereerd. Zie §3.8. Voor elke betrokken 10 verzekeraar wordt Actiehouder = Ja en (Datum/tijd Actiehouder wordt ook geactualiseerd) en Reeds geopend = Nee.  Anders, als met dit nieuwste voorstel het maximum aantal aansprakelijkheidsvoorstellen voor dit regres wordt bereikt, dan krijgt het regres de status ‘inactief’ en dit wordt aan beide partijen gemeld (meldingtype 23). Beide verzekeraars krijgen Actiehouder = Ja (Datum/tijd Actiehouder wordt ook geactualiseerd) en Reeds geopend = Nee.  Anders wordt het nieuwe voorstel doorgestuurd naar de tegenpartij (meldingtype 4). Daarmee krijgt de verzekeraar zelf Actiehouder = Nee en de tegenpartij krijgt Actiehouder = Ja (Datum/tijd Actiehouder wordt ook geactualiseerd) en Reeds geopend = Nee.

10

De motivatie is als volgt. Misschien moet de verzekeraar nog schadebedragen melden (als hij minder dan 100% aansprakelijk is en nog geen bedragen gemeld heeft). Maar in ieder geval staat voor de verzekeraar de actie nog open om de verwerking in de eigen backoffice te completeren (‘Verwerkt’-knop).


31/70

3.4.4

Schadebedragen Melden Event

Een betrokken verzekeraar stelt op basis van eigen onderzoek de schadebedragen van de eigen verzekerde vast en meldt dit aan het CR-systeem (meldingtype 7).


32/70

Actie

11

Controles in willekeurige volgorde (verwerking stopt na het vinden van één fout):  Als de inzendende verzekeraar backoffice-koppelaar is en nog niet gemigreerd (§3.4.8), dan mogen de velden ‘WAM-code tegenpartij’, ‘Nagekomen bedragen (ja/nee)’, ‘buitengerechtelijke kosten’, ‘expertisekosten’, ‘bedrag 9’, ‘bedrag 10’ en ‘bedrag 11’ (zie §4.1.7 op pagina 52) niet aanwezig zijn. Als dat toch het geval is wordt dat gemeld aan de indiener (meldingtype 27).  Als de inzendende verzekeraar browser-gebruiker is danwel gemigreerde backoffice-koppelaar (§3.4.8), dan moeten de velden ‘WAM-code tegenpartij’, Nagekomen bedragen (ja/nee)’, ‘buitengerechtelijke kosten’ en ‘expertisekosten’ (zie §4.1.7 op pagina 52) aanwezig zijn. Bovendien moet de aanwezigheid van de velden ‘bedrag 9’, ‘bedrag 10’ en ‘bedrag 11’ in overeenstemming zijn met de migratiestatus van die velden (§3.4.8). Als dat niet het geval is wordt dat gemeld aan de indiener (meldingtype 27).  Als de inzendende verzekeraar browser-gebruiker is danwel gemigreerde backoffice-koppelaar (§3.4.8) en het betreffende regres is niet bekend in het CR11 systeem , of een andere status heeft dan ‘open’, ‘gematcht’, ‘afrekenen’ of ‘afgehandeld’, dan wordt het bericht geweigerd en dat wordt gemeld aan de indiener (meldingtype 18).  Als de inzendende verzekeraar backoffice-koppelaar is en nog niet gemigreerd (§3.4.8) en het betreffende regres is niet bekend in het CR-systeem, of een andere status heeft dan ‘open’, ‘gematcht’ of ‘afrekenen’, dan wordt het bericht geweigerd en dat wordt gemeld aan de indiener (meldingtype 18).  Als de betreffende verzekeraar geen partij is bij dit regres, dan wordt het bericht geweigerd, waarvan melding gemaakt wordt aan de indiener (meldingtype 20).  Als de termijn voor het melden van schadebedragen sinds de matchdatum (§3.4.8 op pagina 35) reeds is verstreken, dan wordt het bericht geweigerd en dat wordt gemeld aan de indiener (meldingtype 19).  Als voor enige bedragsoort het totaal dat door deze verzekeraar aan schadebedragen gemeld is hiermee kleiner dan nul of groter dan het gestelde maximum voor de betreffende bedragsoort (§3.4.8 op pagina 35) zou worden, dan wordt het bericht geweigerd en dat wordt gemeld aan de indiener (meldingtype 26).  Als de inzendende verzekeraar browsergebruiker of gemigreerde backofficekoppelaar (§3.4.8) is, dan moet veld ‘Nagekomen bedragen (ja/nee)’ in overeenstemming zijn met de eerste verzonden afhandelberichten: vóór het verzenden = nee; na het verzenden = ja. Als dat niet klopt wordt dat gemeld aan de indiener (meldingtype 28).  Als de inzendende verzekeraar browsergebruiker of gemigreerde backofficekoppelaar (§3.4.8) is, en veld ‘Nagekomen bedragen (ja/nee)’ = ja en de tegenverzekeraar is backoffice-koppelaar en is nog niet gemigreerd (§3.4.8), dan is dat fout en dat wordt gemeld aan de indiener (meldingtype 29).  Omdat de zogenaamde BuitenGerechtelijke Kosten (BGK) ten behoeve van Rechtsbijstandverzekeraars door het CR-systeem worden berekend, worden eventueel door een regrespartij in het schademeldingsbericht (bericht CR87007) ingediende bedragen voor BGK (kostensoort 016) genegeerd. NB. hiervan wordt geen melding gemaakt naar de indiener.  Omdat de Wettelijke Rente ten behoeve van Rechtsbijstandverzekeraars door het CR-systeem worden berekend, is het bedragveld Bedrag9 (kostensoort 018) gedefinieerd als ‘drager’ van deze in rekening te brengen kosten. De eventuele in het schademeldingsbericht (bericht CR87007) ingediende bedragen door een regrespartij op deze kostensoort worden door het CR-systeem genegeerd. NB. hiervan wordt geen melding gemaakt naar de indiener.  Als de tegenpartij van de inzendende verzekeraar een Rechtsbijstandverzekeraar is, dan worden alle ingezonden bedragen genegeerd (op € 0,00 gezet), omdat op een Rechtsbijstandverzekeraar niets verhaald kan worden. NB. hiervan wordt geen melding gemaakt naar de indiener.

Zie §3.6 Berichtvolgorde op pagina 35.


33/70

Als geen fouten worden gevonden:  (Merk op dat het systeem niet eist dat de bedragen nul zijn als de andere verzekeraar een rechtsbijstandverzekeraar of een claim service is – dat moet de meldende partij zelf in de gaten houden.)  De schadebedragen worden vastgelegd in de CR-database.  Als er al een match is bereikt voor dit regres:  De schadebedragen worden in een afhandelbericht doorgestuurd naar de tegenpartij en naar de indiener van de schadebedragen (meldingtype 8).  Als dit het eerste paar afhandelberichten is voor dit regres, dan krijgt het regres de status ‘afrekenen’ en wordt voor het regres een afhandelticket gegenereerd (zie §3.8), anders wordt de status ‘afgehandeld’.  Beide verzekeraars krijgen Actiehouder = Ja (Datum/tijd Actiehouder wordt ook geactualiseerd) en Reeds geopend = Nee. 3.4.5

Rappel Aansprakelijkheid Event Het CR-systeem ontdekt in de database een regres met status ‘open’ waarover al 12 langer dan 15 dagen geen berichten meer zijn binnengekomen of uitgegaan. Actie  Als er nog helemaal geen aansprakelijkheidsvoorstel is binnengekomen, gaat naar beide partijen een rappel (meldingtype 5).  Anders gaat er een rappel naar de verzekeraar die ‘aan zet’ is: de verzekeraar die niet het laatste aansprakelijkheidsvoorstel heeft ingediend (meldingtype 5). In de beschrijving van de event gaat het over binnenkomende en uitgaande berichten. Door het zo te formuleren, begint de teller opnieuw te lopen juist door het verzenden van de rappelberichten.

3.4.5.1

Extra rappel t.b.v. Buiten Gerechtelijke Kosten “laag tarief” Event Het CR-systeem ontdekt in de database een regres waarvan de tegenpartij een 13 Rechtsbijstandverzekeraar is met status ‘open’ waarover al langer dan 18 dagen geen berichten meer zijn binnengekomen of uitgegaan en waarbij de casco verzekeraar aan de beurt is m.b.t. het aansprakelijkheid melden. Actie Er gaat naar de casco verzekeraar een rappel (meldingtype 5)

12

Dit getal is illustratief. Het is instelbaar, zodat de systeembeheerder het kan aanpassen. Zie §3.4.8. 13

Dit getal is gebaseerd op de standaard termijn voor BuitenGerechtelijke Kosten “laag tarief” (= 21 dagen) min 3 dagen. Het “laag tarief” BGK bedraagt € 30. Door op deze extra rappel snel wordt gereageerd, kan worden voorkomen dat voor regresdossiers de BGK “hoog tarief” (= € 275) in rekening wordt gebracht door de Rechtsbijstand verzekeraar. De rappeltermijn kan door de systeembeheerder van het CR-systeem worden aangepast indien de standaard termijn BGK wijzigt. Ook de bedragen “laag tarief” en “hoog tarief” zijn instelbaar binnen het CRsysteem.


34/70

3.4.6

Rappel Schadebedragen Event

Actie

3.4.7

Het CR-systeem ontdekt in de database een combinatie van een regres en een betrokken verzekeraar waarvoor geldt:  de status is ‘gematcht’ of ‘afrekenen’, en  de verzekeraar heeft nog geen schadebedragen gemeld (meldingtype 7), en  de verzekeraar heeft in de match een eigen aansprakelijkheid opgegeven minder dan 100%, en 12  de match is minstens 25 dagen oud, en  een eventueel eerder rappel voor schadebedragen (meldingtype 9) is ook min12 stens 25 dagen oud.  Er gaat er een rappel voor schadebedragen naar de betreffende verzekeraar (meldingtype 9).

Stille Schade Inactiveren Event

Actie

Het CR-systeem ontdekt in de database een regres met een andere status dan ‘inactief’ of ‘afgehandeld’ waarover al langer dan 60 dagen12 geen berichten meer zijn binnengekomen.  Het regres krijgt de status ‘inactief’ en dit wordt aan beide partijen gemeld (meldingtype 22). Beide verzekeraars krijgen Actiehouder = Ja (Datum/tijd Actiehouder wordt ook geactualiseerd) en Reeds geopend = Nee. In de beschrijving van de event gaat het alleen over binnenkomende berichten. Door het zo te formuleren, begint de teller niet opnieuw te lopen door het verzenden van rappelberichten (zie opmerking bij §3.4.5).

3.4.8

Besturing Tunen Er zijn diverse instellingen die gewijzigd kunnen worden: 1. Het aantal dagen na het laatste bericht van/naar het CR-systeem dat een verzekeraar een rappel krijgt om een aansprakelijkheid te melden (gebruik volgens §3.4.5). 2. Het maximum aantal aansprakelijkheidsmeldingen per regres (gebruik volgens §3.4.3). 3. Het aantal dagen na het laatste bericht naar het CR-systeem dat een regres automatisch uit het CR-systeem verwijderd wordt (gebruik volgens §3.4.7). 4. Het aantal dagen na het bereiken van een match dat een verzekeraar een rappel krijgt om het schadebedrag in te voeren (gebruik volgens §0). 5. Het maximum aantal dagen na het bereiken van een match dat een regres nog beschikbaar blijft voor het melden van schadebedragen. 6. Voor elk schadebedrag (zie §4.1.7) een maximum. (gebruik volgens §4.1.8). 7. Een verzekeraar kan regres voortijdig afbreken en daarbij de code voor een reden opgeven (zie §3.4.2 en 4.1.10). De lijst met geldige redenen is instelbaar. 8. De toegestane aansprakelijkheidsverdelingen (zie de toelichting bij §4.1.3) zijn instelbaar, evenals de toegestane OVS-codes. Ook de afhankelijkheden tussen percentages en OVScodes is instelbaar. Zie de toelichting bij entiteit OVS/% in Hoofdstuk 5. 9. De toegestane marge op de ongevaldatum, in dagen. Zie §3.9. 10. De tarieven voor BuitenGerechtelijke Kosten (BGK): “laag tarief” en “hoog tarief” (nu resp. €31 en €289). 11. Standaard termijn BGK “laag tarief” (nu 21 dagen) 12. Standaard invoertermijn voor schadebedragen door een Rechtsbijstandverzekeraar: nu 0 dagen; zie §Error! Reference source not found. 13. Rappeltijd m.b.t. het overschrijden van de standaardtermijn BGK “laag tarief” (nu 18 dagen) 14. Rente percentage m.b.t. de berekening van de Wettelijke Rente (nu 4%): wettelijke rente voor consumententransacties (www.wettelijkerente.net). Stichting EPS geeft wijzigingen in de wettelijke rente door aan ABZ. Het CR-systeem heeft een scherm waarop de systeembeheerder de waarden van deze getallen kan zien en aanpassen. Na de aanpassingen zijn ze onmiddellijk van toepassing.


35/70

Diverse instellingen grijpen op elkaar in. De systeembeheerder moet erop toezien dat het aantal dagen bij punt 1 kleiner is dan dat bij punt 3, anders komt er nooit een rappel. Hetzelfde geldt voor het aantal dagen bij punt 4. Ten behoeve van de migratie naar driepartijenregres, exta bedragsoorten en nagekomen bedragen – waarop de verschillende verzekeraars zich onafhankelijk van elkaar kunnen voorbereiden – is er een tabel met de volgende kolommen, waarin per verzekeraar met een backoffice-koppeling gegevens worden bijgehouden: Kolomnaam WAM-code Gemigreerd (ja/nee)

Bedrag-9 (ja/nee)

Bedrag-10 (ja/nee) Bedrag-11 (ja/nee)

Toelichting Identificatiecode van de verzekeraar Geeft aan of het backoffice-systeem van de verzekeraar al geschikt is voor driepartijenregres, nagekomen bedragen en de eerste twee extra bedragsoorten. Geeft aan of het backoffice-systeem van de verzekeraar al geschikt is voor de bedragsoort Wettelijke Rente. Ongeacht deze instelling (ja of nee) zal de inhoud van bedrag-9 in een meldingsbericht van schadebedragen (zie §4.1.7) worden genegeerd omdat het bedrag Wettelijke Rente door het CR-systeem wordt berekend. Het CR-systeem zal dit veld alleen gebruiken in de zogenaamde Afhandelberichten. Geeft aan of het backoffice-systeem van de verzekeraar al geschikt is voor de tiende extra bedragsoort. Geeft aan of het backoffice-systeem van de verzekeraar al geschikt is voor de elfde extra bedragsoort.

Deze tabel moet als volgt gebruikt worden tijdens en na de migratie.

3.4.9



Initieel wordt de tabel gevuld met alle backoffice-koppelaars en voor die partijen staan alle vinkjes op nee.



Zodra een verzekeraar gemigreerd is, wordt het eerste vinkje voor die partij op ja gezet.



Er kan door SEPS beslist worden over de invulling van de bedragsoorten 10 en 11. Er wordt bijvoorbeeld beslist dat via bedragsoort 10 de kostensoort x gemeld kan worden. Vanaf dat moment kan voor een verzekeraar het vinkje bedrag 9 op ja worden gezet, maar alleen als de betreffende verzekeraar al gemigreerd is. Zo geldt dat ook voor de overige bedragsoorten.



De systeembeheerder moet er voor zorgen dat er geen vinkjes voor bedragsoorten worden gezet waarover nog geen besluit is genomen door SEPS.

Meldingtypen Hieronder staan de meldingtypen/berichtsoorten beschreven die door het CR-systeem worden verstuurd en ontvangen, zoals beschreven in §3.3. In de rechter kolom is aangegeven of een bericht kan worden beschouwd als een uitzonderingssituatie. Omschrijving 1. Melding van een regres, nog zonder toedracht en aansprakelijkheid, maar eventueel met voorlopig schadebedrag en schadenummer.

Richting VerzCR

Details §4.1.1

2. Doormelding van het regres aan de tegenpartij, nog zonder toedracht en aansprakelijkheid, maar eventueel met voorlopig schadebedrag en schadenummer.

VerzCR

§4.1.2

3. Melding door een verzekeraar van een aansprakelijkheidsvoorstel.

VerzCR

§4.1.3


Uitzond.

36/70

Omschrijving 4. Doormelding aan de andere verzekeraar van een aansprakelijkheidsvoorstel.

Richting VerzCR

Details §4.1.4

Uitzond.

5. Rappel: aansporing door het CR om een (tegen)voorstel voor de aansprakelijkheid te doen.

VerzCR

§4.1.5

ja

6. Melding door het CR aan verzekeraar dat een match bereikt is.

VerzCR

§4.1.6

7. Melding van de schadebedragen van de eigen cliënt.

VerzCR

§4.1.7

8. Doormelding van de schadebedragen aan beide partijen. Dit is het afhandelbericht.

VerzCR

§4.1.8

9. Rappel waarin de verzekeraar wordt aangespoord om voor een gematcht regres schadebedragen van de eigen cliënt te melden.

VerzCR

§4.1.9

ja

10. Afmelding door verzekeraar: het regres moet niet (langer) via het CR afgehandeld worden, met opgave van een reden.

VerzCR

§4.1.10

ja

11. Validatiefoutboodschap met details over de fout in een eerder ontvangen bericht van de verzekeraar.

VerzCR

§4.1.11 (V1 - 15)

ja

12. Melding aan de oorspronkelijke aanmelder van een regres dat de tegenpartij niet kon worden vastgesteld (niet bestaande WAM-code? verzekeraar tegenpartij geen deelnemer CR?)

VerzCR

§4.1.11 (S2)

ja

13. Melding aan de indiener van een afmelding (zie meldingtype 10) dat de afmelding niet aan een geregistreerd openstaand regres te koppelen is.

VerzCR

§4.1.11 (Af1)

ja

14. Melding aan de indiener van een afmelding (zie meldingtype 10) dat de indiener geen partij is bij het regres.

VerzCR

§4.1.11 (Af2)

ja

15. Melding dat een aansprakelijkheidsvoorstel is geweigerd omdat de verzekeraar geen partij is bij het regres.

VerzCR

§4.1.11 (Aa1)

ja

16. Melding dat een aansprakelijkheidsvoorstel is geweigerd omdat de verzekeraar niet aan de beurt is om een voorstel in te dienen.

VerzCR

§4.1.11 (Aa2)

ja

17. Melding dat een aansprakelijkheidsvoorstel is geweigerd omdat het geen openstaand regres betreft.

VerzCR

§4.1.11 (Aa3)

ja

18. Melding dat de schadebedragen zijn geweigerd omdat het regres onbekend of inactief is.

VerzCR

§4.1.11 (Sb1)

ja

19. Melding dat al schadebedragen zijn doorgemeld aan de tegenpartij (via een afhandelbericht). Daarom zijn de nieuwe schadebedragen geweigerd.

VerzCR

§4.1.11 (Sb2)

ja

20. Melding dat de schadebedragen geweigerd zijn omdat de verzekeraar geen partij is bij dit regres.

VerzCR

§4.1.11 (Sb3)

ja

21. Melding aan verzekeraar dat het regres de status ‘inactief’ heeft gekregen door een afmelding (zie §3.4.2). De boodschap bevat de reden, overgenomen uit de afmelding (meldingtype 10).

VerzCR

§4.1.11 (M1)

ja


37/70

3.5

Omschrijving 22. Melding dat een regres de status ‘inactief’ heeft gekregen omdat er te lang geen (tegen)voorstellen voor aansprakelijkheidsverdeling en/of schadebedragen zijn binnengekomen, ondanks rappels.

Richting VerzCR

Details §4.1.11 (M2)

Uitzond. ja

23. Melding dat het maximum aantal aansprakelijkheidsvoorstellen vóór een match overschreden is. Daarom is het regres op ‘inactief’ gezet.

VerzCR

§4.1.11 (M3)

ja

24. Melding dat de schademelding geweigerd is omdat één van de betrokken verzekeraars nog niet voorbereid is op driepartijenregres, terwijl die verzekeraar partij is in een bestaand regres met deze kentekens en schadedatum.

VerzCR

§4.1.11 (S4)

ja

25. Melding dat de schademelding geweigerd is omdat de betrokken verzekeraars al partij zijn in een bestaand regres met deze kentekens en schadedatum.

VerzCR

§4.1.11 (S5)

ja

26. Melding dat de som van de bedragen op een kostensoort lager dan nul is geworden of boven het gestelde maximum uitkomt.

VerzCR

§4.1.11 (Sb4)

ja

27. Melding dat de aanwezige velden in het bericht niet overeenstemmen met de bij CR geregistreerde capaciteiten van het backoffice-systeem van de verzekeraar

VerzCR

§4.1.11 (V16)

ja

28. Melding dat vóór de match alleen correcties en na de match alleen nagekomen bedragen kunnen worden gemeld.

VerzCR

§4.1.11 (Sb5)

ja

29. Melding dat voor de tegenpartij nagekomen bedragen nog niet acceptabel zijn.

VerzCR

§4.1.11 (Sb6)

ja

Uitzonderingssituaties Naast de verwerking zoals die is beschreven in §3.2.1 en §3.2.3, waarbij het melden en het matchen normaal verloopt, kunnen er allerlei uitzonderingssituaties ontstaan. Die zijn al beschreven, in §3.2.2, 3.2.4, 3.2.5, 3.2.6 en verweven in §3.2. Een afzonderlijk overzicht van deze uitzonderingssituaties is af te leiden uit de rechterkolom in §3.4.9.

3.6

Berichtvolgorde Het gebruikte berichtenmedium garandeert niet dat de volgorde van de berichten gehandhaafd blijft. Dus als een partij een aantal berichten naar de CR-applicatie verzendt, dan kunnen ze bij de CR-applicatie in een andere volgorde aankomen. Daarom is in de CR-applicatie een buffer ingebouwd. Binnenkomende aansprakelijkheidsmeldingen (§4.1.3) en schadebedragmeldingen (§4.1.7) worden in zulke gevallen nog een instelbare tijd bewaard (in de orde van enkele minuten). Zulke berichten die na dat tijdverloop nog in de buffer staan, worden alsnog als fout afgehandeld. Intussen wordt ook na iedere verwerking van een regresmelding (§4.1.1) in deze buffer gekeken of er nog berichten in staan die na de betreffende regresmelding alsnog verwerkt kunnen worden.

3.7

Managementinformatie Voor het bestuur van de SEPS en voor de functioneel beheerder van het CR-systeem zijn er overzichten. Deze kunnen worden gebruikt om de individuele deelnemers aan te spreken op hun verantwoordelijkheden krachtens het SEPS-deelnemersreglement of om aan de geldschieters van de SEPS verantwoording af te leggen over de bereikte resultaten. De volgende overzichten worden in concreto geproduceerd.


38/70

3.7.1

Percentage Matches Gevraagde statistiek aantal aangemelde schades per maand

percentage gematchte schades per maand

Toelichting Het aantal regressen dat binnen de betreffende kalendermaand bij het CR-systeem succesvol is aangemeld - opgeslagen in de database. Hierin worden dus ook de regressen geteld waarop de aangesproken tegenpartij reageert met de mededeling dat die niet daadwerkelijk tegenpartij is. M / (M + F) M = Het aantal regressen waarvoor binnen de betreffende kalendermaand de matchberichten zijn verstuurd (zie §4.1.6). F = Het aantal regressen waarvoor binnen de betreffende kalendermaand een foutboodschap M1, M2 of M3 is verstuurd (zie 14 §4.1.11), en waarvoor nooit eerder een matchbericht is verstuurd (zie §4.1.6). Stel er is een regres dat matcht op 25 augustus maar op 3 september alsnog wordt afgemeld of waarvoor de termijn voor het indienen van schadebedragen verloopt. Door de gespecificeerde rekenwijze draagt dit regres alleen bij aan de statistiek over augustus en wel positief. Het regres draagt geheel niet bij aan de statistiek over september. Merk op dat in een kalendermaand best meer regressen gematcht dan aangemeld kunnen worden. Er kunnen immers openstaande regressen van vorige maanden zijn. Men kan dan ook niet met deze twee statistieken het aantal gematchte schades in deze maand uitrekenen.

percentage gematchte schades per aangesloten instelling per maand 3.7.2

Als M + F voor een kalendermaand op nul uitkomt, wordt de statistiek niet berekend. De berekening verloopt zoals bij ‘percentage gematchte schades per maand’ hierboven, echter in M en F worden alleen regressen geteld waarin de betreffende verzekeraar partij is.

Doorlooptijd Gevraagde statistiek gemiddelde reactietijd na eerste schademelding in de maand

Toelichting De reactie kan zijn een aansprakelijkheidsmelding (§4.1.3) of het afmelden van het regres (§4.1.10). Het kan ook zijn dat de tegenpartij nooit reageert. Daarom worden alleen regressen meegerekend waarop wél is gereageerd - en wel voor het eerst in de betreffende kalendermaand.

Als in de betreffende maand in het geheel geen eerste reacties zijn opgetreden, wordt de statistiek niet uitgerekend. gemiddelde reactietijd De berekening verloopt als bij ‘gemiddelde reactietijd na eerste per aangesloten instel- schademelding in de maand’ hierboven. Echter, er worden alleen ling na eerste schade- regressen meegerekend waarbij de betreffende aangesloten inmelding in de maand stelling de reagerende tegenpartij is.

14

In de betreffende kalendermaand of eerder.


39/70

Gevraagde statistiek aantal schademeldingen waarbij partijen te laat hebben gereageerd, uitgesplitst naar maatschappij

Toelichting Er zijn diverse vormen van te laat:  De partij ontvangt twee of meer rappels voor het aansprakelijkheidspercentage alvorens te reageren.  De partij ontvangt twee of meer rappels voor de schadebedragen alvorens te reageren. De aanname is dat ook regressen moeten worden meegerekend waarbij een partij helemaal niet reageert. Per maatschappij rapporteert het CR-systeem daarom twee getallen: 1. Het aantal tweede rappels voor het aansprakelijkheidspercentage (zie §4.1.5). 2. Het aantal tweede rappels voor de schadebedragen (zie §4.1.9).

3.7.3

Gebruik van Helpdesk Gevraagde statistiek aantal vragen aan de helpdesk per maatschappij

Toelichting Deze gegevens zijn niet beschikbaar in de kern van het CR-systeem. Echter, in de voorziene implementatie wordt gebruik gemaakt van de helpdesk van ABZ. De ondersteunende systemen van de ABZ-helpdesk kunnen worden geconfigureerd om deze statistieken te produceren. Er kan onderscheid gemaakt worden tussen incidentmeldingen en commerciële contacten.


40/70

3.7.4

Diversen Gevraagde statistiek verhouding OVS niet OVS schades

Toelichting De minimale interpretatie hiervan is dat slechts één percentage wordt opgegeven, namelijk het percentage van de bereikte matches (zie §4.1.6) waarbij wél een OVS-code wordt gerapporteerd.

Het is nauwelijks ingewikkelder om van iedere OVS-code in matchberichten (inclusief blanco OVS-code) het percentage uit te rekenen. resultaat eerste versus Het gemiddelde aantal aansprakelijkheidsmeldingen (§4.1.3) per tweede match regres waarvoor in de betreffende kalendermaand een matchbericht (§4.1.6) wordt verstuurd. matchingspercentage Zie bij ‘percentage gematchte schades per aangesloten instelling per maatschappij uitper maand’ (§3.7.1), nu afzonderlijk gerapporteerd voor de gevalgesplitst naar rol aan- len waarbij de betreffende verzekeraar de originele aanmelder was meldende partij versus en de overige gevallen, waarbij de verzekeraar tegenpartij was. tegenpartij verhouding persoonAlle afhandelberichten (§4.1.8) die aan de volgende voorwaarden lijke versus casco voldoen spelen in de berekening een rol . schade  Ze moeten in de betreffende kalendermaand verstuurd zijn, en  Als het bericht een ‘WAM-code tegenpartij’ bevat (de geadresseerde was toen gemigreerd - §3.4.8) dan moet eigen bedragen (ja/nee) = nee; anders (dus toen niet gemigreerd) moeten de schadebedragen niet negatief zijn. Merk op dat het dus gaat om berichten waarbij de ontvanger netto betaalt. Merk ook op dat nagekomen bedragen in deze statistiek wél meetellen, mogelijk in een volgende maand. De berekening is P / A. P = de som van alle cascoschade-bedragen (§4.1.8). A = de som van alle bedragen (§4.1.8). Merk op dat het hier om het aandeel van de bedragen gaat waarvoor daadwerkelijk regres wordt gevoerd. Gevallen waarbij (de verzekeraar van) de eigen verzekerde 100% zelf aansprakelijk is, hebben geen invloed op deze statistiek.

gemiddelde doorlooptijd

gemiddelde doorlooptijd per aangesloten instelling

Als het getal A op nul uit komt, wordt deze statistiek niet gerapporteerd. Van alle regressen waarvoor in de betreffende maand het tweede afhandelbericht voor niet nagekomen bedragen werd verstuurd: de gemiddelde tijd die verlopen is tussen het eerste aanmeldbericht van het betreffende regres tot het genoemde tweede afhandelbericht voor niet nagekomen bedragen. De berekening verloopt zoals bij ‘Gemiddelde doorlooptijd’ hierboven, echter er worden alleen regressen geteld waarin de betreffende verzekeraar partij is.


41/70

Gevraagde statistiek gemiddeld bedrag per bedragsoort

Toelichting Voor iedere bedragsoort (cascoschade etc.) wordt berekend: Alle bedragen in afhandelberichten die voldoen aan de volgende voorwaarden, worden in de berekening betrokken:  Als de geadresseerde van het afhandelbericht gemigreerd is (afhandelbericht bevat een ‘WAM-code tegenpartij’), moet 15 volgnummer = 1 zijn (dus geen nagekomen bedragen tellen ), en  Het bedrag is groter dan nul, en  Het bedrag is van de betreffende bedragsoort, en  Het betreffende afhandelbericht is verstuurd in de betreffende maand.

De berekening is T / N, waarbij T = het totaal van de geselecteerde bedragen N = het aantal geselecteerde bedragen gemiddeld bedrag per De berekening verloopt zoals bij ‘Gemiddeld bedrag per bedragbedragsoort per aansoort’ hierboven, echter er worden alleen regressen geteld waarin gesloten instelling de betreffende verzekeraar partij is. aantal afmeldingen per Het aantal afmeldberichten met de betreffende reden dat van de reden per aangesloten betreffende verzekeraar is ontvangen in de betreffende maand. instelling totaal: verzekeraar is Per verzekeraar worden geteld de afmeldberichten die van de beafmelder treffende verzekeraar zijn ontvangen in de betreffende maand. totaal: verzekeraar is Per verzekeraar worden geteld de afmeldberichten die in de betegenpartij treffende maand zijn ontvangen van de tegenpartij van de betreffende verzekeraar. aantal voorkomens Per OVS-code (inclusief de OVS-code blanco) is de berekening als van ovs-code in volgt: C / T uitgedrukt als percentage, afgerond op hele procenten, matchberichten waarbij C = het aantal matchberichten met de betreffende OVS-code dat in de betreffende maand is verstuurd T = het aantal matchberichten dat in de betreffende maand is verstuurd gemiddeld aantal aan- Hierbij worden alleen de regressen bekeken waarvoor in de besprakelijkheidsmeldin- treffende maand matchberichten zijn verstuurd. gen per gematcht regres

15

Er is bewust voor gekozen de nagekomen bedragen niet mee te tellen, vanwege de complicaties die dat zou geven. Zo kunnen bedragen van één regres in meerdere maanden vallen. Ook zou het dan misschien nodig zijn onderscheid te maken tussen échte nagekomen bedragen en correcties op eerder gemelde bedragen.


42/70

3.8

Factuurtickets Er zijn twee momenten tijdens het verwerken van een regres waarop het systeem zogenaamde tickets genereert ten behoeve van facturatie. Het eerste is op het moment dat een nieuw regres voor het eerst wordt aangemeld bij het CR-systeem (§3.4.1). Dit ticket wordt de basis voor een factuur aan de aanmeldende verzekeraar. Het tweede moment is wanneer voor de eerste keer afhandelberichten worden verstuurd over dit regres (§3.4.3 en §3.4.4). Dit tweede ticket wordt de basis voor een factuur aan de andere partij, dus de partij die niet het regres als eerste heeft aangemeld. ABZ biedt de klanten de mogelijkheid om via een web-site details te bekijken van de facturen die ABZ stuurt. Daar staan dan de individuele tickets gespecificeerd. Het systeem wordt zó ingericht dat van ieder ticket zoals hierboven beschreven, de volgende details op de web-site te zien zijn: 

Het feit of het een aanmeld- of een afhandelticket is;



De schadedatum;



De beide betrokken kentekens;



De WAM-code van de tegenpartij.

Een verzekeraar krijgt van ieder afgehandeld regres waarbij hij betrokken was slechts één ticket te zien, ófwel een aanmeldticket, ófwel een afhandelticket.

3.9

Marge Schadedatum De verzekeraars die bij een regres zijn betrokken, kunnen in hun administraties verschillende ongevalsdata hanteren. Het systeem ondersteunt dit door een marge toe te staan: een aantal dagen dat de ongevalsdata mogen verschillen bij het aanmelden/bevestigen van een regres. De regel is dat een verzekeraar in een bevestigingsbericht een iets afwijkende schadedatum mag opgeven. Vanaf dat moment gebruikt die verzekeraar in berichten naar het CR-systeem uitsluitend die afwijkende datum. De implementatie bestaat uit de volgende onderdelen (zie daarbij Hoofdstuk 5): 

De systeembeheerder kan de genoemde marge instellen (zie §3.4.8)



Bij een regresmelding (zie §3.4.1) wordt de opgegeven ongevaldatum vastgelegd in de velden ‘Ongevaldatum’ in het gecreëerde ‘Regres’-record en in de twee gecreëerde ‘Voertuigschade’-records.



Bij de bevestiging door de tegenpartij van een regresmelding (zie §3.4.1) wordt de eventuele afwijkende ongevaldatum alleen in het veld ‘Ongevaldatum’ in het eerder gecreëerde ‘Voerttuigschade’-record van de bevestigende partij gezet (die daarmee de oude waarde overschrijft).



Wanneer het CR-systeem een bericht verstuurt naar een verzekeraar, wordt daarin de ongevaldatum gehanteerd zoals die in het ‘Voertuigschade’-record van de betreffende verzekeraar staat.



In de Management-informatie, bij het zoeken in de web-browser en in tickets wordt uitsluitend de (originele) ongevaldatum gehanteerd zoals die in het ‘Regres’-record staat.


43/70

3.10 Specifieke functionaliteit t.b.v. Rechtsbijstandverzekeraars In deze paragraaf wordt het specifieke gedrag van het CR-systeem beschreven in het geval één van de regrespartijen een Rechtsbijstandverzekeraar is. De Rechtsbijstandverzekeraar zal dan regres voeren namens een WA-verzekerde. De tegenpartij zal een WA-casco verzekeraar zijn. 3.10.1 Algemeen Een Rechtsbijstandverzekeraar mag naast de kosten m.b.t. het schade-incident ook zogenaamde BuitenGerechtelijke Kosten (BGK) en Wettelijke Rente in rekening brengen bij de tegenpartij. Het bedrag BGK (“laag tarief” of “hoog tarief”) en het bedrag voor Wettelijke Rente worden automatisch door het CR-systeem berekend. Hieronder is het proces weergegeven waarbij één van de regrespartijen een Rechtsbijstandverzekeraar is:


44/70

CLEARINGHUIS REGRES

Rechtsbijstand Verzekeraar

Tegenpartij

Begin

MELDEN

ongevalmelding ontvangen

ongeval melden

ongeval melden

MATCHEN aansprakelijkheid ontvangen aansprakelijkheid melden (1)

aansprakelijkheid melden (2)

match? nog niet voorstel doormelden naar tegenpartij

ja

ja

match melden aan beide partijen

nogmaals?

definitief niet

definitieve afwijzing melden

ja

nogmaals?

BETALEN schadebedragen melden (1)

schadebedragen ontvangen

schadebedragen melden (2) nee

reeds def. bedragen ontvangen?


ja

match bereikt?

afhandelberichten versturen


Einde



Einde

Bij een regresproces waarbij één van de regrespartijen een Rechtsbijstandverzekeraar is gelden de onderstaande uitgangspunten: 

Een Rechtsbijstandverzekeraar moet binnen het CR-systeem als zodanig worden gekenmerkt



Wanneer een regresdossier wordt geopend in CR en één van de regrespartijen is een e Rechtsbijstandverzekeraar, dan kan de 1 aansprakelijkheidsmelding alleen door de Rechtsbijstandverzekeraar worden gedaan. De tegenpartij van de Rechtsbijstande verzekeraar wordt pas actiehouder als de 1 aansprakelijkheidsmelding door de Rechtsbijstandverzekeraar is gedaan.


45/70

3.10.2 Berekening BGK Wanneer een Rechtsbijstandverzekeraar één van de regrespartijen is, dan zaal het CRsysteem automatisch het bedrag BGK berekenen. Hiervoor gelden de onderstaande afspraken: 

Wanneer een Rechtsbijstandverzekeraar een regresdossier opent in CR en er wordt een match bereikt met de tegenpartij, dan zal CR, voorafgaand aan het versturen van de sets afhandelberichten het BGK-tarief bepalen op basis van de werkelijke doorlooptijd tussen Aansprakelijkheid melden (1) en Aansprakelijkheid melden (2) (zie processchema in §3.10.1)



De gebruiker kan niet zelf BGK opvoeren als kosten. Op het invoerscherm staat achter “Buitengerechtelijk” de tekst: “wordt automatisch berekend (indien van toepassing)”



Wanneer CR een bericht ontvangt met schadebedragen vanuit de backoffice van de Rechtsbijstandverzekeraar en hierin zijn BGK opgenomen, dan wordt deze input genegeerd en worden de door het CR-systeem berekende BGK opgevoerd naar de tegenpartij



Wanneer de tegenpartij van een Rechtsbijstandverzekeraar een melding schadebedragen instuurt, dan worden alle bedragen genegeerd (op € 0,00 gezet), omdat op een Rechtsbijstandverzekeraar geen schade verhaald kan worden.



De door het systeem berekende bedrag voor BGK zijn door de gebruiker niet te wijzigen



Wanneer de ‘wachttijd’ tussen Aansprakelijkheid melden (1) en Aansprakelijkheid melden (2) (zie processchema) kleiner of gelijk is dan de standaard termijn laag tarief (nu 21 dagen), dan zal het CRsysteem automatisch BGK laag tarief in rekening brengen (nu € 30,-), wanneer de standaard termijn laag tarief wordt overschreden, dan wordt het BGK hoog tarief in rekening brengen (nu € 275,-)



Als de standaard invoertermijn schadebedragen (nu 0 dagen vanaf Aansprakelijkheid melden (1)) door de Rechtsbijstandverzekeraar wordt overschreden, dan wordt de standaard termijn laag tarief 16 (nu 21 dagen) verlengd met deze overschrijding



Wanneer er een match is met betrekking tot de aansprakelijkheidsverdeling en de schadebedragen zijn door de Rechtsbijstandverzekeraar opgevoerd in CR, dan stuurt het CR-systeem twee sets afhandelberichten: 1.

Eerste set met de schadebedragen van de Rechtsbijstandverzekeraar

2.

Tweede set met schadebedragen van de tegenpartij N.B. deze zijn per definitie € 0,-



Wanneer er sprake is van schulddeling (aansprakelijkheidsverdeling is 50%-50%), dan zal CR bij het opstellen van de afhandelberichten de berekende BGK van de Rechtsbijstandverzekeraar volledig (ongedeeld) doorbelasten aan de tegenpartij



Wanneer de standaard termijn laag tarief (nu 21 dagen) dreigt te worden overschreden en er is nog geen bericht aansprakelijkheid melden (2) (zie processchema), dan zal CR na x dagen (nu bv. 18 dagen) een extra rappelbericht worden gestuurd naar de tegenpartij

3.10.2.1 Filterfunctie als bewaking tegen de overschrijding van de termijn “laag tarief” Op het overzichtsscherm “Overzicht ongevallen” is een filterfunctie ontwikkeld ten behoeve van de bewaking van de dossier waarbij de tegenpartij een Rechtsbijstandverzekeraar is. Wanneer de gebruiker kiest voor dit filter, worden de dossier getoond waarbij:    

Een Rechtsbijstandverzekeraar betrokken is De dossierstatus “open” is Een actie wordt verwacht e 1 rappel is ontvangen

16

Effectief betekent deze instelling dat de 21-dagen termijn (BGK laag tarief) die de tegenpartij van de Rechtbijstandverzekeraar heeft om te reageren op de aansprakelijkheidsmelding, start op het moment dat de Rechtsbijstandverzekeraar schadebedragen heeft ingevoerd.


46/70

3.10.3 Automatische berekening Wettelijke Rente Wanneer een Rechtsbijstandverzekeraar één van de regrespartijen is, dan zal het CR-systeem automatisch het bedrag Wettelijke Rente berekenen. Hiervoor gelden de onderstaande afspraken: 

Wanneer een Rechtsbijstand Verzekeraar een regresdossier opent in CR, dan zal het CRsysteem standaard wettelijke rente berekenen en als zodanige kosten opvoeren bij de tegenpartij



De gebruiker kan niet zelf wettelijke rente opvoeren als kosten. De wettelijke rente is geen invoer veld op het scherm “Ongeval details”, maar worden pas getoond op het overzichtscherm



Voor wettelijke rente wordt bedrag-9 uit de berichtdefinitie gebruikt (Afhandelbericht: CR87008). Als deze bedragsoort als onderdeel van een CR-bericht (Melding Schadebedragen: CR87007) uit de backoffice van een verzekeraar wordt ontvangen, dan zal de inhoud van dit bedragveld worden genegeerd.



De wettelijke rente wordt berekend over de periode (gemeten in dagen) die start op de schadedatum zoals opgegeven door de Rechtsbijstand Verzekeraar en die loopt tot en met de datum waarop een match wordt bereikt plus twee dagen



-

Het wettelijk vastgestelde rentepercentage wordt per periode berekend.

-

De periode is het tijdsdeel waarover een gelijk wettelijk rentepercentage is vastgesteld.

-

Vanaf de matchingsdatum worden er twee extra dagen opgeteld bij het aantal dagen van de laatste periode.

-

Vervolgens worden de bedragen over de verschillende periodes bij elkaar opgeteld.

De wettelijke rente wordt berekend over het totaal van de onderstaande schadebedragen op het moment dat de afhandelberichten worden verstuurd: 1. 2. 3.

Casco schade Eigen risico Waardevermindering



Wanneer er nagekomen bedragen worden opgevoerd door de Rechtsbijstand Verzekeraar, dan zal hierover eveneens wettelijke rente worden berekend



De wettelijke rente wordt in geval van nagekomen bedragen berekend over de periode (gemeten in dagen) die start op de schadedatum zoals opgegeven door de Rechtsbijstand Verzekeraar en die loopt tot en met de datum waarop de nagekomen bedragen zijn ingevoerd plus twee dagen



-

Het wettelijk vastgestelde rentepercentage wordt per periode berekend.

-

De periode is het tijdsdeel waarover een gelijk wettelijk rentepercentage is vastgesteld.

-

Vanaf de invoerdatum van de nagekomen bedragen worden er twee extra dagen opgeteld bij het aantal dagen van de laatste periode.

-

Vervolgens worden de bedragen over de verschillende periodes bij elkaar opgeteld.

Als een CR-deelnemer nog met de oude berichtdefinitie werkt, of wanneer de CR17 deelnemer (nog) geen bedrag-9 wenst te ontvangen (zie systeeminstellingen in §3.4.8), dan zal de inhoud van bedrag-9 worden geteld in het bedragveld “Overige kosten”

17

Het backofficesysteem is bv. nog niet voorbereid op het ontvangen van wettelijke rente in het veld bedrag-9


47/70


48/70

Hoofdstuk 4 Informatieuitw isseling Hier worden de berichten gespecificeerd (§4.1) die worden uitgewisseld tussen het CR-systeem en de deelnemende verzekeraars, zoals beschreven in §3.3. De volgorde waarin de berichten moeten worden uitgewisseld (het protocol) is beschreven in §4.2.

4.1

Berichtformaten Bij alle berichtformaten moet de ontvanger in staat zijn het type melding te achterhalen. Het kan dus zijn dat er in ieder bericht een code moet staan die dit type aangeeft (§4.1.1 t/m 4.1.11). De hieronder beschreven berichtformaten zijn detailleringen van wat beschreven is in §3.4.9. Iedere formaatbeschrijving bevat de veldnamen van de individuele gegevens die ermee uitgewisseld worden. Bovendien is aangegeven of een gegeven verplicht in het bericht is opgenomen of niet. Tijdens de standaardisatiefase worden deze berichten vertaald naar een XML-structuur. Het uitgangspunt bij de beschrijvingen hieronder is dat de berichtinfrastructuur zo is ingericht dat van ieder bericht de afzender (verzekeraar) is te achterhalen door de ontvanger. Mocht dat in de technische implementatie niet automatisch het geval zijn, dan moet aan de berichtformaten de afzender worden toegevoegd: de WAM-code.

4.1.1

Regresmelding (CR)87001 Beide betrokken verzekeraars sturen dit bericht in, hetzij onafhankelijk van elkaar, hetzij de tweede als bevestiging van een ontvangen doormelding (§4.1.2) van de eerste. De aanduiding ‘eigen’ duidt op de afzender van het bericht. Veldnaam ongevaldatum kenteken eigen verzekerde polis eigen verzekerde WAM-code tegenpartij kenteken tegenpartij polis tegenpartij intern schadenummer

voorlopig schadebedrag

Verplicht ja ja ja ja ja

Toelichting

Dit is een referentienummer dat de tegenpartij kan gebruiken bij overleg. Het veld is niet verplicht, maar het systeem biedt geen latere gelegenheid om het alsnog door te geven. Dit is 100% van de geschatte schade die de eigen verzekerde heeft geleden. Hierin is dus niet het aansprakelijkheidspercentage verdisconteerd. Het betreft (de schatting van) de som van alle bedragen die zijn genoemd in §4.1.7. Het veld is niet verplicht, maar het systeem biedt geen latere gelegenheid om het alsnog door te geven.


49/70

4.1.2

Regresdoormelding (CR)87002 De aanduiding ‘eigen’ in de veldnaam duidt op de ontvanger van het bericht. Veldnaam ongevaldatum

4.1.3

Verplicht ja

kenteken eigen verzekerde polis eigen verzekerde WAM-code tegenpartij

ja ja ja

kenteken tegenpartij polis tegenpartij schadenummer voorlopig schadebedrag

ja

Aansprakelijkheidsmelding (CR)87003 De aanduiding ‘eigen’ duidt op de afzender van het bericht. Veldnaam ongevaldatum kenteken eigen verzekerde WAM-code tegenpartij

kenteken tegenpartij OVS-code volgens eigen inzicht eigen aansprakelijkheidspercentage

Verplicht ja ja

Toelichting

Dit veld wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht. ja ja ja

commentaar

4.1.4

Toelichting Waarde is ‘ongevaldatum’ uit het eigen ‘Voertuigschade’-record. Waarde is ‘kenteken tegenpartij’ uit §4.1.1. Waarde is ‘polis tegenpartij’ uit §4.1.1. Waarde leidt het CR-systeem af uit de fysieke afzender van §4.1.1. Waarde is ‘kenteken eigen verzekerde’ uit §4.1.1 Waarde is ‘polis eigen verzekerde’ uit §4.1.1. Waarde is ‘intern schadenummer’ uit §4.1.1. Waarde is ‘voorlopig schadebedrag’ uit §4.1.1.

Het ingevulde percentage moet te rijmen zijn met het percentage dat uit de OVS-code volgt. Zie de toelichting bij entiteit ‘OVS/%’ in Hoofdstuk 5. Bij de eerste aansprakelijkheidsmelding voor een regres wordt dit veld niet ingevuld. Het is alleen bedoeld als reactie op een eerdere melding door de tegenpartij.

Aansprakelijkheidsdoormelding (CR)87004 De aanduiding ‘eigen’ duidt op de ontvanger van het bericht. Veldnaam ongevaldatum

Verplicht ja

kenteken eigen verzekerde WAM-code tegenpartij

ja

kenteken tegenpartij OVS-code volgens tegenpartij aansprakelijkheidspercentage tegenpartij commentaar

ja ja

Toelichting Waarde is ‘ongevaldatum’ uit het eigen ‘Voertuigschade’-record. Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35).

ja

Waarde is ‘OVS-code volgens eigen inzicht’ uit §4.1.3. Waarde is ‘eigen aansprakelijkheidspercentage’ uit §4.1.3. Waarde is ‘commentaar’ uit §4.1.3.


50/70

4.1.5

Rappel Aansprakelijkheid (CR)87005 De aanduiding ‘eigen’ duidt op de ontvanger van het bericht. Veldnaam ongevaldatum

4.1.6

Verplicht ja


ja

kenteken tegenpartij einddatum match

ja ja

Toelichting Waarde is ‘ongevaldatum’ uit het eigen ‘Voertuigschade’-record. Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). Hierin staat de datum van het versturen van het rappelbericht vermeerderd met de rappeltermijn, zoals vermeld in §3.4.8 punt 1. Aan dit veld kan de ontvanger zien vóór welke datum zijn aansprakelijkheidsmelding binnen moet zijn. N.B. Voor de extra rappel (zie 3.4.5.1) geldt dat hierin de datum wordt vermeld waarop BGK hoog tarief ingaat.

Matchbericht (CR)87006 De aanduiding ‘eigen’ duidt op de ontvanger van het bericht. Veldnaam ongevaldatum

Verplicht ja


ja

kenteken tegenpartij OVS-code

ja ja

eigen aansprakelijkheidspercentage

ja

Toelichting Waarde is ‘ongevaldatum’ uit het eigen ‘Voertuigschade’-record. Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). Dit is ingevuld als de partijen het ook eens geworden waren over de OVS-code.


51/70

4.1.7

Melding Schadebedragen (CR) 87007 Dit bericht hoeft alleen verstuurd te worden als de betreffende verzekeraar zichzelf minder dan 100% aansprakelijk acht en dus iets te claimen heeft - dan nog kan hij bedragen € 0,- opgeven overigens. De aanduiding ‘eigen’ duidt op de afzender van het bericht. Veldnaam ongevaldatum kenteken eigen verzekerde WAM-code tegenpartij

Verplicht Toelichting ja ja Dit veld wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht. Geeft aan of de afzender deze bedragen beschouwt als nagekomen bedragen, dan wel als de originele bedragen (of correcties daarop). Dit veld wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht.

Nagekomen bedragen (ja/nee)

kenteken tegenpartij bedrag cascoschade

ja

bedrag eigen risico verzekerde bedrag autohuurkosten bedrag waardevermindering bedrag bedrijfsregelingen bedrag overige buitengerechtelijke kosten

ja

Dit is 100% van de vastgestelde schade die de eigen verzekerde heeft geleden. Hierin is dus niet het aansprakelijkheidspercentage verdisconteerd. Zie toelichting bij ‘bedrag cascoschade’.

ja

Zie toelichting bij ‘bedrag cascoschade’.

ja


ja


ja

Zie toelichting bij ‘bedrag cascoschade’. Zie toelichting bij ‘bedrag cascoschade’. Dit bedrag wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht. Zie toelichting bij ‘bedrag cascoschade’. Dit bedrag wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht. Dit bedragveld is gedefinieerd als het veld waarin de Wettelijke Rente wordt doorgegeven aan de CR-deelnemers. Omdat Wettelijke Rente door het CR-systeem berekend wordt, mag dit veld niet worden gevuld in dit bericht (melden schadebedragen). Indien dit bedragveld toch wordt gevuld, zal de eventuele inhoud door het CR-systeem worden genegeerd. Zie toelichting bij ‘bedrag cascoschade’. Dit bedrag wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gebruik maken van bedrag 10 (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht.

expertisekosten

bedrag 9

bedrag 10

ja


52/70

Veldnaam bedrag 11

Verplicht Toelichting Zie toelichting bij ‘bedrag cascoschade’. Dit bedrag wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gebruik maken van bedrag 11 (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht.


53/70

4.1.8

Afhandelbericht (CR) 87008 De aanduidingen ‘eigen’ en ‘zelf’ duiden op de ontvanger van het bericht. Veldnaam ongevaldatum kenteken eigen verzekerde WAM-code tegenpartij kenteken tegenpartij volgnummer

Verplicht Toelichting ja Waarde is ‘ongevaldatum’ uit het eigen ‘Voertuigschade’record. ja Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). ja

bedrag/vink cascoschade

ja

bedrag/vink eigen risico verzekerde bedrag/vink autohuurkosten bedrag/vink waardevermindering bedrag/vink bedrijfsregelingen bedrag/vink overige

ja

Afhandelberichten worden paarsgewijze verstuurd: naar elke verzekeraar één. Binnen een regres krijgt het eerste paar nummer 1. Ieder volgende paar krijgt een één hoger volgnummer. Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). Dit geeft aan of dit afhandelbericht het gevolg is van bedragen die de ontvangende verzekeraar zelf gemeld heeft (§4.1.7 op pagina 52 ). Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). Dit veld bestaat uit een bedrag (in €), te betalen aan de tegenpartij en een bijbehorend vinkje dat aangeeft of het bedrag de gestelde limiet overschrijdt (zie §3.4.8). Voor ontvangende verzekeraars die nog niet gemigreerd zijn (§3.4.8 op pagina 35) is de betekenis als volgt:  Als het bedrag positief is, is dit het bedrag dat de tegenpartij geclaimd heeft  het eigen aansprakelijkheidspercentage.  Als het bedrag negatief is, is dit het zelf geclaimde bedrag  het aansprakelijkheidspercentage van de tegenpartij. Het vinkje is een signalering voor de web-site en voor de ontvangende back-office dat het bedrag niet zonder persoonlijk overleg betaald moet worden. Sinds versie 1.7 van het FO staat het vinkje altijd uit. Voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35) is de betekenis als volgt:  Als het afhandelbericht het gevolg is van schadebedragen die de tegenpartij gemeld heeft (§4.1.7 op pagina 52 ), dan staat hier dat bedrag  het eigen aansprakelijkheidspercentage.  Als het afhandelbericht het gevolg is van schadebedragen die de ontvangende verzekeraar zelf gemeld heeft (§4.1.7 op pagina 52 ), dan staat hier dat bedrag  het aansprakelijkheidspercentage van de tegenpartij  -/- 1. Zie toelichting bij ‘bedrag/vink cascoschade’.

ja

Zie toelichting bij ‘bedrag/vink cascoschade’.

ja


ja


ja

Zie toelichting bij ‘bedrag/vink cascoschade’. Bovendien, zie de berekening bij de bedragen hierna.

eigen bedragen ja/nee


54/70

Veldnaam bedrag/vink buitengerechtelijke kosten

Verplicht Toelichting Zie toelichting bij ‘bedrag/vink cascoschade’. Deze velden worden alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). Anders wordt een eventueel te melden bedrag buitengerechtelijke kosten opgeteld bij het bedrag overige hierboven. Zie toelichting bij ‘bedrag/vink cascoschade’. Deze velden worden alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). Anders wordt een eventueel te melden bedrag expertisekosten opgeteld bij het bedrag overige hierboven. Dit bedragveld is gedefinieerd als het veld waarin de Wettelijke Rente wordt doorgegeven aan de CR-deelnemers. Het CR-systeem zal op basis van de termijnen en de bedragen de Wettelijke Rente berekenen en na het bereiken van de match doorgeven aan de CR-deelnemers via deze afhandelberichten. Als de CR-deelnemer heeft aangegeven het veld bedrag-9 separaat te kunnen ontvangen zal dit veld worden gebruikt. Als het veld bedrag-9 niet kan worden ontvangen, zal de berekende Wettelijke Rente bij de inhoud van het bedragveld Overige worden geteld. Zie toelichting bij ‘bedrag/vink cascoschade’. Deze velden worden alleen tussengevoegd voor ontvangende verzekeraars die al gebruik maken van bedrag 10 (§3.4.8 op pagina 35). Anders wordt een eventueel te melden bedrag 10 opgeteld bij het bedrag overige hierboven. Zie toelichting bij ‘bedrag/vink cascoschade’. Deze velden worden alleen tussengevoegd voor ontvangende verzekeraars die al gebruik maken van bedrag 11 (§3.4.8 op pagina 35). Anders wordt een eventueel te melden bedrag 11 opgeteld bij het bedrag overige hierboven.

bedrag/vink expertisekosten

bedrag/vink bedrag 9



Het volgende verduidelijkt dit. Stel we hebben het volgende gematchte schadegeval: Partij A B

Verantwoordelijk v% 100% - v%

Oorspronkelijk schadebedrag eigen verzekerde (hier alleen cascoschade) €a €b

Dan worden voor de oorspronkelijke schadebedagen de volgende vier afhandelingsberichten gestuurd. Voor de nagekomen bedragen is het iets anders (in dit voorbeeld niet uitgewerkt). Betreffende de schade van partij A A B B

Bericht Bedrag (€) aan B A A B

€ a  (100% - v%) -/- € a  (100% - v%) € b  v% -/- € b  v%

Toelichting

positief, dus berichtontvanger (B) betaalt negatief, dus berichtontvanger (A) ontvangt positief, dus berichtontvanger (A) betaalt negatief, dus berichtontvanger (B) ontvangt


55/70

4.1.9

Rappel Schadebedragen (CR) 87009 De aanduiding ‘eigen’ duidt op de ontvanger van het bericht. Veldnaam ongevaldatum

Verplicht ja


ja

kenteken tegenpartij einddatum schadebedragen

ja ja

Toelichting Waarde is ‘ongevaldatum’ uit het eigen ‘Voertuigschade’-record. Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35).

4.1.10 Afmelding (CR) 87010 De aanduiding ‘eigen’ duidt op de afzender van het bericht. Veldnaam ongevaldatum kenteken eigen verzekerde WAM-code tegenpartij

kenteken tegenpartij code van reden

Verplicht ja ja

Toelichting

Dit veld wordt alleen tussengevoegd door (en geaccepteerd van) verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35), maar voor die verzekeraars is het ook verplicht. ja ja

Hiermee geeft de afzender aan waarom hij het regres niet verder via het CR wil afhandelen. Er is een lijst geldige codes (zie 3.4.8).

4.1.11 Systeemmelding (CR) 87011 De aanduiding ‘eigen’ duidt op de ontvanger van het bericht. Veldnaam ongevaldatum

Verplicht ja


ja

kenteken tegenpartij code

ja ja

Toelichting Waarde is ‘ongevaldatum’ uit het eigen ‘Voertuigschade’-record. Dit veld wordt alleen tussengevoegd voor ontvangende verzekeraars die al gemigreerd zijn (§3.4.8 op pagina 35). Zie hierna.


56/70

In de onderstaande teksten zijn de gedeelten tussen variabelen die door het CR-systeem worden overgenomen uit eerder binnengekomen berichten. Code V1 V2 V3 V4 V6 V11 V12 V14 V15 V16 S2 S4 S5 Af1 Af2 Aa1 Aa2 Aa3 Sb1 Sb2 Sb3 Sb4 Sb5 Sb6 M1 M2 M3

Betekenis Ongevaldatum is een ongeldige datum DDMMJJJJ. Ongevaldatum kan niet in de toekomst liggen. Tegenpartij (WAM-code+volmacht-code) komt niet overeen met deelnemer CR. 18 Kenteken eigen verzekerde ongeldig . 18 Kenteken tegenpartij ongeldig . 19 OVS-code ongeldig . Eén of meer schadebedragen ongeldig. 19 OVS-code strookt niet met het percentage . 19 Aansprakelijkheidspercentage ongeldig . Aanwezige velden in het bericht stemmen niet overeen met geregistreerde capaciteiten van het backoffice-systeem. Tegenpartij kon niet worden vastgesteld. Oorzaak: . 20 Schademelding geweigerd: een partij accepteert nog geen driepartijenregres . Schademelding geweigerd: partijen kennen dit regres al. Afmelding kon niet aan een openstaand regres gekoppeld worden. Afmelder geen partij in genoemd regres. Aansprakelijkheidsmelding geweigerd: indiener geen partij bij dit regres. Aansprakelijkheidsmelding geweigerd: indiener niet aan de beurt. Aansprakelijkheidsmelding geweigerd: geen openstaand regres. Schadebedragen geweigerd: geen openstaand regres. Schadebedragen geweigerd: reeds doorgemeld aan tegenpartij. Schadebedragen geweigerd: geen partij bij dit regres. Schadebedragen geweigerd: som van onder nul of boven maximum. Schadebedragen geweigerd: vóór match alleen correcties, na match alleen nagekomen bedragen. Nagekomen bedragen geweigerd: systeem tegenpartij kan deze nog niet verwerken. Definitief geen complete afhandeling: regres afgemeld door tegenpartij. Reden: . Definitief geen complete afhandeling: te lang geen aansprakelijkheidsmeldingen en/of meldingen van schadebedragen binnengekomen. Definitief geen match: maximum aantal aansprakelijkheidsvoorstellen overschreden.

18

Een kenteken is (hier) een reeks tekens die uitsluitend uit hoofdletters en/of cijfers bestaat. Geen streepjes dus. 19

Zie toelichting bij entiteit ‘OVS/% op pagina 51.

20

Deze boodschap geeft de fout verkort weer. Hij wil niet zeggen dat alle regressen geweigerd worden als een partij nog niet gemigreerd is. Zie §3.4.1.


57/70

Formatted Table

4.2

Protocol De diverse verwerkingsstappen zoals die beschreven zijn in §3.2 moeten in een bepaalde volgorde door de samenwerkende verzekeraars worden aangestuurd om een optimale werking te garanderen. Hieronder is een zogenaamd state transition-diagram opgenomen waarin voor één regres is weergegeven welke stappen doorlopen kunnen worden. Bij de meeste status-overgangen worden berichten gestuurd, òf door een verzekeraar òf door het CR-systeem. Omdat dit schema alle mogelijke volgorden vastlegt waarin de berichten verzonden kunnen worden, noemt men dit een beschrijving van het protocol. Merk op dat dit schema is toegevoegd ter verduidelijking. Het bevat voor de softwarebouwer geen nieuwe informatie boven Hoofdstuk 3 en §4.1.

Start

A of B meldt regres

Nieuw aangemeld regres

A meldt aansprakelijkheid

B meldt aansprakelijkheid

B meldt aansprakelijkheid zonder match

Regres met laatste aansprakelijk heid partij A

A meldt aansprakelijkheid zonder match

B meldt aansprakelijkheid met match

Klaar voor nagekomen bedragen

A of B meldt nagekomen bedragen

Eventuele achtergehouden afhandelberichten naar A en B

Afhandelberichten naar A en B

Nagekomen bedragen ontvangen

Regres met laatste aansprakelijk heid partij B

A meldt aansprakelijkheid met match

Gematcht regres

In alle 4 tussenstadia kan een verzekeraar schadebedragen melden. In alle 4 tussenstadia kan het regresgeval zonder match beëindigd worden, door overschrijding van termijn, maximum aantal aansprakelijkheidsmeldingen of door expliciete afmelding door een betrokken verzekeraar.

Termijn voor nagekomen bedragen verloopt

In alle tussenstadia kan een verzekeraar foutieve berichten insturen die een foutboodschap tot gevolg hebben maar geen statuswijziging. Stop


58/70

4.3

Berichtstructuur De berichten zoals beschreven in §4.1 worden afgeleid van het ABZ Claimsmodel (dit model is gebaseerd op het internationale claimsmodel). Dit resulteert is een XML berichtenstructuur. Deze standaardisatiefase levert de volgende eindproducten:

4.4



Basisview beschrijving; dient als basis voor de interface-beschrijvingen. Dit document bevat een beschrijving van alle berichttypen en alle attributen. Het optimale aantal interface-beschrijvingen wordt tijdens de standaardisatiefase vastgesteld.



XML-Schema’s bij deze basisview.



Voorbeeld XML documenten.

Communicatieprotocol In de variant waarbij het CR-systeem communiceert met het backoffice-systeem van de verzekeraar, zal dit gebeuren via het SOAP / ebXML-protocol.


59/70

Hoofdstuk 5 Entitei tenmodel Hieronder staat het Entiteit Relatie Diagram van het CR-systeem weergegeven. We kunnen hier zien dat alle individuele aansprakelijkheidsmeldingen worden bewaard, in het entiteit-type ‘Standpunt’. Standpunt

OVS/%

Standpuntdatum/tijd OVS-code Percentage Commentaar

OVS-code Percentage

over

Bedragen

Voertuigschade Kenteken Polisnummer Bevestigd (ja/nee) Voorlopig schadebedrag Intern schadenummer Actiehouder (ja/nee) Reeds geopend (ja/nee) Datum/tijd Actiehouder Ongevalsdatum

van

Datum/tijd toevoegen Schadebedrag casco Eigen risico Kosten autohuur Waardevermindering Bedrag bedrijfsregelingen Bedrag overig Buitengerechtelijke kosten Expertisekosten Bedrag 9 Bedrag 10 Bedrag 11

verz. bij betrokken bij

Verzekeraar

Regres

WAM-code IT-adres Naam Actief lid j/n

Ongevaldatum Matchdatum Status

Merk als eerste op dat een ERD niet hetzelfde is als een database-ontwerp. Het ERD specificeert welke gegevens beschikbaar moeten zijn, maar niet of ze in generieke systemen (SAP, IBIS, KIS etc.) of in een specifieke CR-database worden gesitueerd. In het entiteittype ‘Verzekeraar’ is opgenomen het veld ‘Actief lid j/n’. Een uitgeschreven verzekeraar kan immers niet meteen verwijderd worden, omdat er nog informatie over regressen, schades etc. in het systeem kan zitten die naar de betreffende verzekeraar verwijst. Een voorbeeld van de verwerking: wanneer een regres voor het eerst wordt gemeld, voegt het CR-systeem een rij toe aan entiteittype ‘Regres’. Bovendien komen er twee rijen in entiteittype ‘Voertuigschade’ en – als er bedragen gemeld worden – in entiteittype ‘Bedragen’, voor elk betrokken voertuig één stel – het voertuig van de eigen verzekerde krijgt ‘Bevestigd’ = ja, het andere voertuig krijgt ‘Bevestigd’ = nee. En vanuit elk van de Voertuigschade-rijen wordt een koppeling gelegd naar de betreffende rij in entiteittype ‘Verzekeraar’. Wanneer de melding van de tegenpartij komt worden de bestaande records bijgewerkt, waarna

beide voertuigen ‘Bevestigd’ = ja hebben. In het schema zijn de verbindingen ‘informatiedragend’. Dat wil zeggen dat een verbinding van bijvoorbeeld ‘Voertuigschade’ naar ‘Regres’ impliceert dat in de technische implementatie van entiteittype ‘Voertuigschade’ voldoende informatie staat (de zogenaamde foreign key) om de betreffende rij in entiteittype ‘Regres’ te lokaliseren. Een ‘Standpunt’ heeft eigenlijk betrekking op een ‘Regres’ als geheel. Waarom is het dan toch gekoppeld aan een ‘Voertuigschade’? Stel dat we een ‘Standpunt’ direct aan een ‘Regres’ hadden gerelateerd. Dan zou aan een ‘Standpunt’ ook een link naar de betreffende ‘Verzekeraar’ toegevoegd moeten worden. En er zouden checks moeten worden uitgevoerd dat niet zomaar iedere ‘Verzekeraar’ een ‘Standpunt’ kan indienen over een ‘Regres’, maar alleen ‘Verzekeraar’s wier cliënten erbij betrokken zijn. In theorie kan het zijn dat beide betrokken voertuigen via dezelfde ‘Verzekeraar’ verzekerd zijn. In theorie omdat de verzekeraar dan normaal gesproken niet via het CR-systeem zal werken. Gebeurt het toch, dan zijn er twee ‘Standpunt’en van dezelfde ‘Verzekeraar’ van belang die uit elkaar gehouden moeten worden. Al deze problemen worden opgelost door in het entiteitenmodel een ‘Standpunt’ niet rechtstreeks aan een ‘Regres’ te koppelen, maar via de ‘Voertuigschade’.


60/70

We zien dat het veld Ongevaldatum zowel voorkomt in entiteit-type Voertuigschade als in entiteit-type Regres. Dat is sinds versie 2.0 het geval om te kunnen omgaan met gevallen waarbij de betrokken verzekeraars bij een regres iets verschillende versies van de datum van het ongeval hanteren in hun administraties. Bij het aanmelden van een regres wordt de opgegeven datum geschreven in het ‘Regres’-record en in de beide ‘Voertuigschade’-records. Bij de bevestiging door de tegenpartij kan één van de twee ‘Voertuigschade’-records een iets afwijkende waarde krijgen. Voor de implementatie van een database: een WAM-code is vier posities numeriek, gevolgd door vier posities volmachtcode en kan gebruikt worden om de betrokken verzekeraars uniek te identificeren. Het veld Actiehouder Ja/Nee geeft aan of de betreffende verzekeraar op dat moment iets mag/moet doen voor het betreffende regres, gezien de mogelijke (re)acties van de tegenpartij. Datum/tijd Actiehouder bevat het moment waarop de betreffende verzekeraar actiehouder is geworden - van belang voor de sortering in de GUI. Het veld Reeds Geopend Ja/Nee geeft aan of een employee van de betreffende verzekeraar het betreffende regres in de actuele stand van zaken al heeft geopend in de GUI. Het entiteit-type ‘OVS/%’ bevat een rij voor iedere toegestane combinatie van OVS-code en aansprakelijkheidspercentage, met dien verstande dat geen verdubbelingen nodig zijn bij symmetrieën. Bovendien zijn de percentages vastgelegd die toegestaan zijn als géén OVS-code wordt opgegeven. Hieronder wordt een en ander met fictieve voorbeelden verduidelijkt. Beoogde toegestane combinaties OVS-code percentages 3 0% of 100%. 6 50%. 12 20%, 50% of 80%. geen

0%, 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 80% of 100%.

Inhoud entiteittype OVS/% OVS percentage 3 0 6 50 12 20 12 50 0 10 30 40 50

De software wordt zó ingesteld dat als in de tabel bijvoorbeeld 20% voorkomt, dat automatisch bij de betreffende OVS-code ook 100% - 20% = 80% wordt toegestaan, etc. Het veld IT-adres is tamelijk abstract. Hieronder kan zowel het postbus-nummer van de verzekeraar vallen als een e-mail-adres waar notificaties heen moeten. Heeft de verzekeraar behoefte aan notificaties die naar diverse personen parallel worden gestuurd, dan kan hij zelf intern aan dit e-mail-adres een adreslijst koppelen.


61/70

Hoofdstuk 6 User Interface In dit hoofdstuk worden de verschillende schermen beschreven. Als eerste zal de architectuur worden toegelicht.

6.1

Architectuur Het CR-systeem is een systeem dat op twee manieren kan worden gevoed: 1. middels XML-berichten; dit is uitvoerig in de Hoofdstuk 3 en Hoofdstuk 4 beschreven en bevat geen user-interface. 2. middels een browser-interface. Omdat zowel het XML-berichtenverkeer als de browser-interface met het zelfde kernsysteem communiceren, kan te allen tijde de browser-interface gebruikt worden om de huidige status in het CR-systeem te bekijken, ook al heeft de aanmelding plaatsgevonden middels XML-berichten.

Output queue

Communicatie

XML

CR kernsysteem Opslag

Input queue

Web-interface laag

Digitaal paspoort Voor toegang tot de browser-interface wordt gebruik gemaakt van een digitaal paspoort.

6.2

Presentatiecomponenten Hierna zijn de schermen gedefinieerd voor de web-browser-interface. Algemene punten: 

Steeds als men een datum invoert, is het mogelijk slechts de laatste twee cijfers van het jaartal in te voeren. Het systeem vult dit dan aan tot een jaartal van vier cijfers, zodanig dat het jaartal komt te liggen in het interval van [huidige jaar minus 80 jaar] tot [huidige jaar plus 20 jaar]. Voorbeeld: in 2005 wordt een tweecijferig jaartal aangevuld tot een jaartal gelijk aan of groter dan 1925 en kleiner dan 2025.



Bij het kiezen van de tegenpartij (via een drop down list) kan men een letter intypen, waarna de selectielijst automatisch doorrolt naar het betreffende punt in de lijst.


62/70

6.2.1

Overzichtsscherm

Dit scherm geeft een compleet overzicht van alle regressen binnen CR behalve die met de status ‘Afgehandeld’ - die staan op het tabblad Clearing. Alleen die regressen worden getoond waarbij de gebruiker als verzekeraar of als tegenpartij optreedt. Een filter biedt de mogelijkheid om diverse selecties te maken. Wanneer men filtert op schadenummer en het invulveld voor Schadenummer leeg laat, verschijnen uitsluitend de regressen in beeld die nog geen Schadenummer hebben. Vanuit een regres dat men in beeld heeft, kan een gebruiker detailgegevens opvragen. Met het filter bewaking rechtsbijstand dossiers kunnen cascoverzekeraars een overzicht opvragen van dossiers waarvoor geldt:    

De tegenpartij is een Rechtsbijstandverzekeraar De dossierstatus is “open” Er wordt een actie verwacht e De 1 rappel is ontvangen

Met dis overzicht kan worden voorkomen dat voor dossiers onopgemerkt de standaardtermijn voor “laag tarief” voor BuitenGerechtelijke Kosten verstrijkt (= 21 dagen) 6.2.1.1 Sortering De sortering van de regressen op het overzichtsscherm is als volgt: 

Bovenaan de nog niet geopende regressen van oude naar nieuwe ongevaldatum.



Daaronder de reeds geopende regressen, ook van oude naar nieuwe ongevaldatum.

6.2.1.2 Indicatie Actiehouder Er staat een extra kolom in het overzicht van regressen waarin een sterretje staat als de betreffende verzekeraar actiehouder is; als die géén actiehouder is, staat er niets in deze kolom.


63/70

6.2.1.3 Rappels Er staat een extra kolom in het overzicht van regressen waarin het aantal uitstaande rappels staat. Er staat slechts één aantal rappels: óf die voor de aansprakelijkheidsmeldingen óf die voor de schadebedragen. Er kunnen alleen rappels uitstaan als de verzekeraar actiehouder is. Als het aantal uitstaande rappels nul is, wordt het veld in deze kolom leeg gelaten. Aansprakelijkheidsmelding Als de status niet ‘Gematcht’ is: het aantal uitgevaardigde rappels voor aansprakelijkheidsmeldingen aan deze verzekeraar sinds de laatste actie op het regres (aanmelden, aansprakelijkheidsmelding). Schadebedragen Als de status ‘Gematcht’ is: het aantal uitgevaardigde rappels voor schadebedragen. 6.2.1.4  

Reeds Geopend (Rood/Blauw) Iedere regel in het overzichtsscherm wordt rood en vet zodra de verzekeraar actiehouder wordt; Zodra de verzekeraar een regresgeval opent, krijgt die regel de kleur van de overige tekst (blauw en niet vet).

Dit gegeven wordt geregistreerd in de database, zie gegevenselement ‘Reeds geopend (ja/nee)’ in Hoofdstuk 5. Het verschieten van kleur/dikte loopt over de browsersessies heen, en ook over de verschillende medewerkers van de verzekeraar. Dus stel dat medewerker 1 van verzekeraar A een regresgeval vandaag even opent zonder er verder iets aan te doen. Dan zien alle medewerkers van verzekeraar A vanaf dat moment - ook dagen later - het regresgeval in de kleur van de overige tekst (blauw en niet vet). Merk op dat een verzekeraar in principe door elkaar via de GUI en via de backoffice-koppeling kan werken. Binnenkomende XML-berichten hebben wél invloed op of de verzekeraar actiehouder is, maar via de backoffice-koppeling kunnen regresgevallen niet alleen maar worden geopend. Een verzekeraar die uitsluitend via de backoffice-koppeling werkt, merkt uiteraard niets van de kleur- en diktewisseling, want hij gebruikt geen browser. 6.2.1.5 Scroll Bar Er komt een afzonderlijke verticale scroll bar in het overzicht van regresgevallen, zodat de kolomkoppen in beeld blijven wanneer men naar beneden scrollt. Dit gebeurt alleen als de ingestelde paginagrootte voor de paginering groter is dan het beschikbare scherm.


64/70

6.2.2

Nieuw Regres In dit scherm kan de gebruiker (verzekeraar) een nieuw regres melden.


65/70

6.2.3

Detailscherm Hieronder volgt een ingevulde versie van het detailscherm waarbij een minderheid van het aantal bedragsoorten is ingevuld. We zien dan dat rechts alleen de kopjes verschijnen van de bedragen die ongelijk nul zijn.

Hierna volgt een ingevulde versie van hetzelfde scherm waarbij alle bedragsoorten zijn ingevuld – wat in de praktijk zelden vóórkomt. We zien nu dat rechts ook alle bedragkopjes verschijnen, waardoor het nodig is om horizontaal te scrollen.


66/70

Het detailscherm biedt de mogelijk om de alle gegevens van een regres te bekijken, inclusief de deelbedragen van de tegenpartij (in het voorbeeld zijn die nog niet ingegeven), en om eventueel een (nieuwe) aansprakelijkheid in te voeren middels een OVS-code (optioneel) en een percentage. Indien de gebruiker een OVS-code selecteert, kan de gebruiker alleen nog maar een percentage invoeren dat gerelateerd is aan deze OVS-code. In het bovenstaande voorbeeld heeft de gebruiker OVS-code 0 en aansprakelijkheidspercentage 50% ingevoerd. Tevens kan de gebruiker commentaar bij een aansprakelijkheid opgegeven. Al deze informatie zal aan de tegenpartij kenbaar gemaakt worden. 6.2.4

Overzicht Clearing

Dit scherm geeft een overzicht van alle afhandelberichten. De gebruiker kan middels een filter selecties maken. Onder kolom ‘Te ontvangen’ staat het totaalbedrag van de schadebedragen (casco, eigen risico, autohuurkosten, waardevermindering, bedrijfsregelingen, overige) van de eigen verzekerde, maal het aansprakelijkheidspercentage van de tegenpartij (het web-equivalent van §4.1.8 waarbij de bedragen negatief zijn). Op het web-scherm wordt dit bedrag echter als positief genoteerd. Het minteken valt dus weg. Onder kolom ‘Te betalen’ staat het totaalbedrag van de schadebedragen (casco, eigen risico, autohuurkosten, waardevermindering, bedrijfsregelingen, overige) van de tegenpartij, maal het eigen aansprakelijkheidspercentage (het web-equivalent van §4.1.8 waarbij de bedragen positief zijn). Het kan zijn dat slechts één van de bedragen (‘Te ontvangen’ of ‘Te betalen’) beschikbaar is, als voor de schade aan het ene voertuig reeds afhandelberichten zijn verstuurd, maar voor het andere (nog) niet. Als een bedrag (nog) niet beschikbaar is, wordt de ruimte op het web-scherm blanco gelaten. In dit scherm is een knop getiteld ‘Verwerk’ actief bij een regres als de status van het regres gelijk is aan ‘Afgehandeld’, ‘Afrekenen’ of ‘Inactief’ en de betreffende verzekeraar is actiehouder (Hoofdstuk 5). Als men op deze knop drukt, wordt Actiehouder = Nee. Bovendien: zodra op de knop ‘Verwerk’ is gedrukt, veranderen de bedragen ook niet meer mee met de nagekomen bedragen, want op dat moment worden de bedragen vastgezet, en mochten er daarna nog bedragen nakomen, dan verschijnen die in een nieuwe regel en die kunnen dan ook afzonderlijk ‘verwerkt’ worden. © 2015 ABZ / SEPS Clearinghuis Regres Functioneel Ontwerp v4.2

67/70

6.2.4.1 Sortering De sortering van de regressen op het Clearingscherm is als beschreven in §6.2.1.1 op pagina 63. 6.2.4.2 Indicatie Actiehouder Zie §6.2.1.2 op pagina 63. 6.2.4.3 Reeds Geopend (Rood/Blauw) Dit werkt als in §6.2.1.4 op pagina 64. 6.2.5

6.3

Onderhoudschermen Deze schermen voor de systeembeheerder worden tijdens de bouw ontworpen en gerealiseerd. Hiervoor is geen afzonderlijk ontwerp opgenomen.

Reactiviteit Stel dat verschillende mensen tegelijkertijd via de GUI aan een regres werken, hetzij medewerkers van dezelfde verzekeraar, hetzij van verschillende betrokken verzekeraars. Dan kan het zijn dat bepaalde gegevens omtrent het regres (bijvoorbeeld de status of het veld Actiehouder) veranderen door toedoen van één medewerker. Moeten zulke wijzigingen nu à la seconde in beeld gebracht worden bij alle andere betrokken medewerkers? Dat zou mooi zijn, maar dat is niet realistisch. Het kan immers zijn dat iemand een bepaalde regel aanklikt en een tiende seconde daarvóór verspringt het beeld door toedoen van iemand anders. Dan zou door het klikken het verkeerde regres worden geopend. In het algemeen willen we dat het beeld alleen verspringt na een actie door de medewerker die zelf aan het betreffende beeldscherm zit. Dat kan wel tot gevolg hebben dat een actie die wél mag op grond van de gegevens die in beeld zijn, plotseling niet mag op grond van de actuele gegevens in de database. Bijvoorbeeld, een medewerker wil als eerste voor een regres een aansprakelijkheid melden, maar een collega van de tegenpartij is hem een fractie van een seconde voor met het afmelden van het regres. De eerste medewerker zag dus dat zijn maatschappij actiehouder was, maar niettemin wordt zijn aansprakelijkheidsmelding geweigerd. Dat kan even vreemd overkomen, maar dat is een kwestie van wennen. Technisch houdt het wél in dat een actie via de GUI gecontroleerd moet worden tegen de actuele stand in de database (en eventueel het logbestand).


68/70

Hoofdstuk 7 Impactanalyse Betrokk en Partijen De betrokken partijen (verzekeraars/volmachten) kunnen op twee manieren gebruik maken van het CR-systeem: 1. via de webbrowser-interface 2. via de XML-interface In het schema hieronder is dat geïllustreerd.

Verzekeraar

https/html Regresvoerder

SOAP/ebXML Clearinghuis Regres

AIMS postbussensysteem

SOAP/ebXML

Backoffice-systeem

De de webbrowser-interface wordt vertegenwoordigd door de bovenste pijlen. De genoemde XML-koppeling werkt via het AIMS postbussensysteem van ABZ: Het backoffice-systeem van de verzekeraar zet er berichten voor het CR-systeem in en moet zelf ook regelmatig kijken of er nieuwe berichten voor hem zijn. In de volgende paragrafen wordt per aansluitvariant beschreven wat de impact zal zijn.

7.1

Aansluiten via Browser-Interface Het CR-systeem heeft een browser-interface waarmee het volledige traject van regresvoering, zoals beschreven in de eerdere hoofdstukken, kan worden uitgevoerd. De gebruiker zal gegevens vanuit het bij de gebruiker aanwezige schadesysteem overnemen en invoeren middels de browser-interface. Echter de hoeveelheid gegevens is zeer beperkt. De gebruiker krijgt e-mailnotificaties, waardoor hij direct op de hoogte is wanneer hij binnen het CR-systeem actie moet ondernemen. Deze e-mailnotificaties bevatten een link welke direct verwijst naar de betreffende regresvoering in de browser-interface. Eisen aan de infrastructuur De gebruiker moet beschikken over een web-browser, toegang tot het internet en een digitaal certificaat. Eisen aan de ingebruikname De gebruiker kan zich het CR-systeem eigen maken in hooguit een dag training.


69/70

7.2

Aansluiting via XML-Interface Het CR-systeem beschikt over een XML-interface waarmee een deelnemer (verzekeraar) met het CR-systeem kan communiceren. Dit betekent dat een deelnemer via gestandaardiseerde XML-berichten input geeft aan en output ontvangt van het CR-systeem. Deze berichten moeten aansluiten op de bestaande back-office systemen van de deelnemer. Dit heeft tot gevolg dat er aanpassingen gedaan moeten worden aan deze backoffice-systemen. Eisen aan de infrastructuur De deelnemer moet toegang hebben tot internet en het gebruik van digitale certificaten ondersteunen.


70/70

Clearinghuis Regres Functioneel Ontwerp v4.3

Recommend Documents