Försäkring
Skadegranskning, bedrägerikontroll och regulatorisk rapportering beror alla på att man i efterhand kan visa exakt vad som kontrollerades, av vem och på vilken grund ett krav eskalerades eller reglerades. Den här sidan anger hur ett sådant arbetsflöde skulle planeras och köras på inTheEU Assist, inte en registrering av en slutförd implementering.
Hur arbetsflödet skulle vara uppbyggt
En anspråksfil skulle tas in i ett kunskapspaket med fallomfattning, med en agent konfigurerad att extrahera relevanta fakta, korsreferens policyvillkor och föreslå en risk- eller bedrägeriflagga där mönstret motiverar det. Varje föreslagen flagga anges med statusen föreslagen, knuten till det specifika anspråket och de dokument som det hämtades från, och tillämpas aldrig automatiskt på anspråkets status.
En föreslagen eskalering, avslag eller remiss för utredning skulle planeras som en sekvens av etapper, hashade före verkställighet, så resonemanget som en justerare eller granskare godkänner är exakt vad protokollet visar att utfördes.
Där mänskligt godkännande sitter
Ett flaggat anspråk skulle gå från föreslaget till granskat till godkänt eller avvisat. Ingenting når ett kundinriktat beslut, en förlikning eller en regulatorisk ansökan förrän den ansvariga justeraren eller efterlevnadsombudet har skrivit under på det. Denna sign-off, och de specifika anspråksdata som den kontrollerades mot, skulle kunna verifieras oberoende efteråt.
Vad detta bygger på idag och vad det inte gör
Fallomfattade dokumentintag, den föreslagna till godkända granskningens livscykel och den undertecknade granskningskedjan som knyter en flagga eller ett beslut tillbaka till dess källpåstående och dess granskare är fungerande delar av plattformen. Vad är inte en del av detta: någon förbyggd modell för upptäckt av bedrägerier eller försäkringsteknisk bedömning. Försäkringsgivarens egna justerare och efterlevnadsteam förblir auktoriteten om vad som utgör en giltig flagga; plattformen gör sin granskning bevisbar och spårbar till anspråksfilen den baserades på.
En del av arkitekturen som ligger till grund för denna kapacitetsuppsättning är dokumenterad i ansökningar som fortfarande pågår. Den här sidan beskriver vad plattformen är designad för att göra, på en nivå som är lämplig för att planera en pilot, inte en implementeringsspecifikation.
Plattformsfunktioner och gränssnitt är föremål för ständiga förbättringar. Beskrivningarna i den här guiden kanske inte återspeglar den exakta layouten eller ordalydelsen för den senaste versionen.