Forsikring
Kravgjennomgang, svindelscreening og regulatorisk rapportering er avhengig av å kunne vise, i etterkant, nøyaktig hva som ble sjekket, av hvem og på hvilket grunnlag et krav ble eskalert eller avgjort. Denne siden viser hvordan en slik arbeidsflyt planlegges og kjøres på inTheEU Assist, ikke en oversikt over en fullført distribusjon.
Hvordan arbeidsflyten vil være strukturert
En påstandsfil vil bli innlemmet i en saksomfanget kunnskapspakke, med en agent konfigurert til å trekke ut relevante fakta, kryssreferanser policyvilkår og foreslå et risiko- eller svindelflagg der mønsteret garanterer det. Hvert foreslåtte flagg legges inn med statusen foreslått, knyttet til det spesifikke kravet og dokumentene det ble trukket fra, og brukes aldri automatisk på kravets status.
En foreslått eskalering, avslag eller henvisning til etterforskning vil bli planlagt som en sekvens av stadier, hashkryptert før utførelse, så resonnementet som en juster eller anmelder godkjenner, er nøyaktig hva journalen viser ble utført.
Der menneskelig godkjenning sitter
Et flagget krav vil gå fra foreslått til gjennomgått til godkjent eller avvist. Ingenting når en kundevendt avgjørelse, et forlik eller en regulatorisk innlevering før den ansvarlige justeringen eller compliance officeren har meldt seg på det. Denne sign-off, og de spesifikke kravdataene det ble sjekket mot, ville være uavhengig verifiserbare etterpå.
Hva dette trekker på i dag, og hva det ikke gjør
Saksomfattende dokumentinntak, livssyklusen foreslått-til-godkjent gjennomgang, og den signerte revisjonskjeden som knytter et flagg eller en beslutning tilbake til kildekravet og dens gransker er fungerende deler av plattformen. Hva er ikke en del av dette: enhver forhåndsbygd modell for svindeloppdagelse eller aktuarmessig vurdering. Forsikringsselskapets egne justeringer og etterlevelsesteam forblir autoriteten for hva som utgjør et gyldig flagg; plattformen gjør anmeldelsen bevisbar og sporbar til kravfilen den var basert på.
Noe av arkitekturen som ligger til grunn for dette kapasitetssettet er dokumentert i arkiveringer som fortsatt pågår. Denne siden beskriver hva plattformen er designet for å gjøre, på et nivå som er passende for planlegging av en pilot, ikke en implementeringsspesifikasjon.
Plattformfunksjoner og grensesnitt er gjenstand for kontinuerlig forbedring. Beskrivelsene i denne veiledningen gjenspeiler kanskje ikke den nøyaktige utformingen eller ordlyden til den siste utgitte versjonen.