BRPI0819729A2 - sistema automatizado de processamento de requisição de sinistro - Google Patents

Abstract

sistema automatizado de processamento de requisição de sinistro a presente invenção se refere um sistema de verificação automático de sinistro baseado em um sistema de computador para avaliar a validade das requisições apresentadas nos termos de uma apólice de seguro ou um contrato de proteção de dívida. em vez de exigir que o solicitante entre em contato com a companhia de seguros oucom o credor para apresentar a requisição e fornecer uma enorme quantidade de provas documentais que justifiquem osinistro requerido, o sistema pré-seleciona o risco relativo da requisição usando uma ferramenta de avaliação de riscobaseada em modelagem predi tiva e uma série de fatores de risco potenciais. a ferramenta de verificação automática desinistro associada, usa esse risco de resultados e outrasinformações relacionadas com a pretensão de atribuir um nível de confiança em relação à prova de perda da validade que devem ser satisfeitas antes que a requisição possa ser aprovada através do processo de adjudicação, e atribui uma fonte fornecida a um terceiro ou a uma combinação de fontes de prova que possa ser acessada automaticamente pelo sistema para validar a requisição.

Description

SISTEMA AUTOMATIZADO DE PROCESSAMENTO DE REQUISIÇÃO DE SINISTRO

REFERÊNCIA CRUZADA RELACIONADA AO PEDIDO

Este pedido reivindica prioridade para os pedidos de patente americanos provisórios 61/004,587, depositado em 28 de novembro de 2007 e 12/313,740, incorporados aqui por referência, em sua totalidade.

CAMPO DA INVENÇÃO

Esta invenção se refere de modo geral ao processameno de requisições de apólice de seguro apresentadas pelos clientes da apólice e, mais especificamente a um sistema para processar automaticamente estas requisições pela companhia de seguros através de um processo de validação que dependa de dados fornecidos por terceiros para a credibilidade da requisição.

ANTECEDENTES DA INVENÇÃO

Seguro representa um meio para fornecer proteção contra perdas financeiras de uma variedade de situações. Por exemplo, seguro de vida ajuda a substituir a renda perdida por uma família quando um chefe de família falece. O seguro de saúde ajuda a pagar contas médicas, se um membro da família fica doente. Seguro contra incêndio paga tudo ou parte do prejuízo se é uma casa ou prédio assegurado é destruído pelo fogo. Seguro de automóveis ou embarcações ajuda a cobrir os custos dos danos resultantes de um acidente de carro ou barco.

Seguros trabalha com o principio da partilha de perdas entre as pessoas. As pessoas que desejam ser segurado contra determinados tipos de perdas de concordar em fazer o pagamento do prêmio regular para uma companhia de seguros, que dará retorno em um contrato chamado A política. Em essência, a empresa se compromete a pagar ao tomador uma certa quantia em dinheiro para os tipos de perdas identificados na política. A companhia de seguros irá utilizar os prêmios para comprar ações, obrigações, hipotecas, títulos públicos e outros investimentos de renda à produção para gerar mais dinheiro para pagar, em combinação com os prêmios recebidos de todos os tomadores de seguros, todos os benefícios coletivos ou créditos que são devidos nos termos das políticas.

Os seguros funcionam porque os segurados estão dispostos a negociar uma pequena perda, mas certos, sob a forma do pagamento do prêmio para a garantia contratual de que eles serão indenizados (isto é, paga) no caso de uma perda maior, mas imprevisível. Apesar de o tomador não poderá receber quaisquer benefícios de uma companhia de seguros no âmbito da política, os prêmios não foram desperdiçados, pois a apólice de seguro prevê o tomador de um sentimento de segurança. Portanto, o segurado pode possuir imóvel, dirigir um carro, operar um negócio, e se envolver em muitas outras atividades, mesmo as mais potencialmente arriscadas sem se preocupar com as perdas financeiras que podem ocorrer. Um importante benefício tradicionalmente prestado por muitos empregadores aos seus empregados um seguro de invalidez. Essa apólice de seguro de deficiência é uma forma de seguro patrocinado ou seguro em grupo, e isso faz com que a companhia de seguro subjacente a pagar ao trabalhador uma parte de sua renda perdida enquanto ele está desativado e, portanto, incapaz para o trabalho no trabalho, ou trabalham menos horas do que o normal. Deficiência normalmente constitui uma limitação para o trabalhador de exercer o material e deveres substancial da sua actividade profissional regular devido a doença ou acidente, juntamente com uma perda de limite no salário mensal, devido à mesma doença ou ferimento. A política da inabilidade do grupo também pode cobrir o trabalhador, após um periodo inicial de benefícios, por perda de renda de sua ocupação regular, se ele é, então, incapacitado de trabalhar em qualquer ocupação remunerada para a qual está adaptada pela formação, educação e/ou experiência. A política pode cobrir a deficiência do trabalhador por um curto período de tempo inicial (incapacidade a curto prazo), ou por um período de tempo maior após a invalidez do trabalhador tem continuado por um período de eliminação especifiçados como dias (incapacidade de longo prazo). Decorrido o prazo de eliminação já passou e que o trabalhador ainda está desativada, ele vai receber normalmente o pagamento correspondente a uma percentagem (por exemplo, 60%) de seu salário mensal que ele ganhou antes do inicio da deficiência até um montante limite máximo para a duração da sua deficiência. No entanto, as políticas de seguro de invalidez pode também tampar a duração de pagamentos de benefícios para atenuar o risco.

Além da vida, fogo, e seguro de invalidez e outras formas de cobertura de proteção de risco procurados por clientes incluem o seguro de desemprego e da protecção da dívida. Uma política de seguro-desemprego paga o indivíduo e seu beneficiário em caso de desemprego involuntário. Em termos simplistas, a protecção da dívida é semelhante à vida de crédito, invalidez e seguro-desemprego involuntário, mas em vez de ser uma apólice de seguro, é uma alteração ao contrato de crédito em que, para uma taxa, o credor irá adiar ou cancelar a totalidade ou parte de uma dívida com a morte, invalidez ou desemprego involuntário de um mutuário. Há também deixar ausência de cobertura, onde se tem que tirar uma licença devido ao nascimento de um filho, a dívida é adiado ou cancelado, em parte.

As companhias de seguro e mutuantes são geralmente preparadas e dispostas, nas circunstâncias previstas no seu seguro ou contratos-programa de proteção, para fornecer o segurado e seus beneficiários, com os benefícios especificados pela política ou termos e condições do programa. No entanto, antes de honrar esses compromissos, as seguradoras e os emprestadores igualmente devem validar que as circunstâncias do caso relatado pelo segurado ou beneficiário realmente ocorreu, e se encaixam dentro dos termos da apólice ou contrato. Isso ocorre porque o prêmio cobrado pela companhia de seguros ou credor para a política ou o contrato foi originalmente calibrados para refletir o risco da ocorrência de evento coberto, com base nas leis da probabilidade e da experiência concreta com o tomador.

Combinado com o provável benefício montante que terá de ser pagos aos segurados, tais que são susceptíveis de morrer, tornam-se deficientes, torna-se situação de desemprego involuntário, etc, dentro dos limites da cobertura política, a companhia de seguros ou credor pode fixar o preço da política para cobrir tais perdas, cobrir os custos da companhia de seguros de gerir o seu negócio, e proporcionar um lucro razoável para os acionistas (ou segurados por uma companhia de seguros mútuos). No entanto, se os pagamentos são feitos em cima de reclamações fraudulentas ou errôneas da cobertura política, a solvência dos programas de seguros podem ser colocados em risco com a consequente necessidade de aumento das tarifas cobradas aos consumidores .

Portanto, tanto as seguradoras e os credores têm desenvolvido para validar as reivindicações apresentadas pelo tomador. Essa perda de validação de processos da indústria consiste tipicamente de coleta de dados vários etapas realizados para determinar a natureza do evento e para validar a real ocorrência do evento. Prestadores de apólice de seguro exigem tipicamente o requerente para chamar um número de telefone para fornecer informações de endereçamento para receber um formulário de sinistro. Em seguida, o requerente deve responder a uma variedade de questões enunciadas no formulário de sinistro. Eles também exigem o requerente fornecer prova de que o evento coberto realmente ocorreu. Por exemplo, no caso de morte por uma apólice de seguro de vida, o requerente pode ser obrigado a fornecer um atestado de óbito ou de uma cópia do relatório de autópsia. Em caso de incapacidade, o requerente pode ser convidado a apresentar um formulário de um médico informando que a pessoa abrangida é portadora de deficiência ou incapacitadas para o trabalho. Para o desemprego, a pessoas abrangidas pode ser necessária a prova de que entrou com uma ação com o escritório de seu estado de desemprego.

Estes requisitos para a apresentação da prova do evento coberto geralmente são feitas para todos os clientes sem levar em conta os riscos reais de fraude ou erro do cliente. A companhia de seguros ou lider simplesmente tenta provar que todos os requerentes são elegiveis para todos os benefícios que eles alegam. Naturalmente, este processo de validação é muito trabalho e requer acompanhamento de inquérito pelos empregados da companhia de seguros antes de uma decisão pode ser feita se a pagar ao requerente. Também é onerosa do ponto de vista administrativo, contribuindo assim para a saúde e custos de seguros que já estão enfrentando pressões para a subida persistente de aumento dos custos médicos e farmacêuticos. Enquanto o setor de seguros se esforça para pagar créditos dentro de dez dias da sua aprovação, não é incomum para a instrução da requisição e do processo de validação para tomar de trinta dias. Dado o fato de que o requerente pode ter esperado 3060 dias após o evento de perda para relatar o pedido, a percepção do requerente pode ser que ela tomou 7-10 dias para o pagamento a ser feito pela companhia de seguros, o que pode parecer muito tempo, certamente. Além disso, a intensidade requisitos de prova imposta pela companhia de seguros dos beneficiários pela perda de um segurado falecido pode parecer insensível e desnecessária.

Vários esforços foram feitos dentro da indústria de seguros para agilizar este processo administrativo para analisar e julgar os pedidos de pagamento, ou em nome dos beneficiários segurados. Por exemplo, no setor de saúde, prestadores de serviços de saúde pedido de pagamento da empresa de seguros do paciente para serviços e suprimentos médicos prestados ao paciente. A administração da companhia de seguros dos pedidos de pagamento tornou-se cada vez mais automatizados segundo o qual os técnicos no escritório do prestador de serviços de saúde por via electrónica criar e apresentar um pedido de seguro médico a um sistema central de processamento. Informações sobre o médico, o paciente, serviço médico, seguradoras, etc, geralmente é incluído como parte da requisição de seguro médico. 0 sistema central de processamento, em seguida, verifica que o médico, paciente e seguradora é, na verdade, os participantes do sistema de processamento de pedidos. Após essa etapa de verificação de um sistema automatizado, o sistema central de processamento, converte o pedido de seguro médico para o formato apropriado para a companhia de seguro particular, e encaminha esse pedido à seguradora. Após a adjudicação manual e aprovação da requisição de seguro por um empregado da companhia de seguros, a seguradora dará inicio a uma transferência eletrônica de fundos para conta do prestador de serviços de saúde do banco. Veja, por exemplo, Pedido publicado americano 2003/0187695 depositado por Drennan.

No entanto, uma grande quantidade de tempo e de gastos ainda é necessária para a seguradora para rever e aprovar o pedido de seguro-saúde após a recepção do sistema de processamento central. Porque revisão manual e julgamento é caro, a seguradora pode optar, em vez de simplesmente pagar um grande número de pedidos com um minimo de qualquer revisão, mas esta opção é subótima, uma vez que pode ser vitima de fraude ou erro no pedido.

Pedido de patente americano 2005/0075912 depositado por Bealke et al. revela um sistema eletrônico seguro dos sinistros que fornece as partes (isto é, a seguradora eo requerente) o acesso eletrônico às reivindicações processo para que eles possam acompanhar a sua evolução. O pagamento pode ser imediatamente conectado ao requerente após a aprovação do crédito, mas, novamente, este processo de avaliação que conduziram a esta decisão de aprovação é de natureza manual. A patente americana No. 6343271 concedida à Peterson et al. fornece um sistema eletrônico que pré-julga reivindicar um antes de ser apresentado pelo médico para indicar o provedor se o pedido será sumariamente revistos manualmente ou pago pela seguradora. Desta forma, o médico pode adaptar a sua reivindicação de seguro médico para melhorar a sua chance de obter o pagamento de síntese por parte da seguradora, agilizando o recebimento do pagamento. Veja também Pedido publicado americano 2002/0019754 apresentado pela Peterson et al.

Outros sistemas eletrônicos são conhecidos dentro da indústria de seguros para parcialmente automatizar alguns aspectos do processo de revisão de créditos. Por exemplo, Pedido publicado americano 2007/0050219 depositado por Sohr et al. ensina um sistema para controlar uma reivindicação de seguro contra sinistros pagos anteriormente para o requerente, para evitar duplicação de pagamentos. Pedido de patente americano 2006/0149784 depositado por Tholl et al. especifica um sistema que pré-analisa uma reivindicação de seguro antes da adjudicação manual para determinar se afirma uma reivindicação que é coberto pela apólice de seguros associados. Enquanto isso, Pedido publicado americano 2004/0078247 depositado por Rowe et al III. revela um sistema de processamento eletrônico de reclamações que o pré-examina um pedido antes de seu julgamento manual para a completude e consistência. Qualquer requisição ou incompleto internamente inconsistente podem ser retornados pelo sistema para o requerente de revisão para poupar o tempo do árbitro alega manual, e reduzir o número de pedidos rejeitados. Veja também Pedido publicado americano 2007/0038484 depositado por Hoffner et al.

Outros sistemas eletrônicos existem para ajudar as companhias de seguros para melhorar a eficiência da relação seguradora-recorrente. Por exemplo, Pedido de patente americano 2007/0005402 apresentado por Kennedy et al. ensina um sistema utilizado por um médico para determinar se a seguradora ou o paciente vai pagar a conta, nos termos da apólice de seguro médico. 0 médico pode usar esta informação para corretamente enviar a factura, e obter o pagamento em tempo real a partir do paciente, médico conta poupança, se disponível. No entanto, o pedido deve ainda ser julgado pela seguradora. Por isso as empresas de seguros têm implementado soluções tecnológicas para auxiliar nesta etapa de adjudicação. Pedido de patente americano 2005/0038682 depositado por Gandee et al. revela um áudio de duas vias de comunicação/video que permite a uma companhia de seguros para analisar a perda acidente requerida remotamente sem ter que enviar um regulador para realizar um exame na pessoa. Pedido de patente americano 2002/0002475 depositado por Freedman et al. fornece um sistema usado por uma companhia de seguros de automóveis para a captura de pedidos de informações e imagens de vídeo necessário para o ajustador para detectar fraudes. Pedido de patente americano 2004/0117329 depositado por Crain divulga um sistema semelhante usado pelos Correios para julgar pedidos de pacotes danificados. Pedido de patente americano 2004/0093242 depositado por Cadigan et al. especifica um sistema eletrônico que realiza uma série de funções relacionadas ao processamento de créditos de seguros, incluindo um módulo que controla os dados necessários para o regulador para julgar o pedido. Todos esses sistemas de arte prévia, no entanto, exigem julgamento manual do sinistro, e simplesmente capturar e gerenciar as informações necessárias para uma maior eficiência no processo de adjudicação manual. A patente americana No. 7203654 emitido a Menendez tenta ir mais longe, fornecendo um sistema eletrônico que compara as reclamações contra pesquisas por palavras-chave, afirma os dados da história, eo montante do crédito para determinar qual subconjunto desses créditos são caracterizados pelo maior risco de erro ou fraude, especialmente a mandado de controlo manual e julgamento. Todos os outros pedidos são automaticamente pago pela seguradora, sem escrutínio e julgamento. Veja também Pedido publicado americano 2007/0150319 depositado por Menendez.

A realidade é que nem todos os requerentes representam o mesmo nível de exposição da companhia de seguros em erro ou actividade fraudulenta. Portanto, nem todos os requerentes devem logicamente exigem o mesmo nível de verificação. As circunstâncias de um caso particular pode indicar uma maior ou menor risco relativo de fraude ou erro associado a uma reivindicação. Por exemplo, uma reivindicação perda arquivada sob uma apólice de seguro de vida para a morte de um segurado que pagaram o seguro por

mais	de 20 anos, que no	momento	da morte	é	relatado	como
tendo	sido 80	anos de	idade,	e cu j o	total potencial
benef	leio totaliza US $	500, não	representa	o mesmo n	í vel
de risco, faz	um pedido	para a morte de	um	segurado	que
pagou	prêmios	para apenas um mês	, e que	é	relatado	como
tendo	sido 25	- anos de	idade no	momento	da	morte, com a

potencial benefício, totalizando US$ 100.000. A probabilidade de morte para um de 80 anos de idade é maior que 25 anos. A probabilidade de que o requerente seria capaz de cometer fraude para beneficiar de um pagamento $ 500 é menor do que para um benefício de US$ 100.000 quando outros fatores são considerados. Além disso, a longevidade do relacionamento com o cliente impactos do risco de fraude.

o crédito será pago ou outro benefício previsto, com base na verificação e as regras estabelecidas no contrato cobertura de benefício. O sistema de processamento de crédito, em seguida, define-se um resumo detalhado do crédito com base nas informações prestadas pelo requerente sobre o evento coberto. Uma ferramenta de avaliação de risco é então aplicada a atribuir uma pontuação para o requerente ea pretensão de definir o risco de um crédito fraudulento ou errôneo. O sistema em seguida aplica-se uma ferramenta de verificação automática da perda de atribuir um nível de confiança em relação exigida para o pagamento ou aprovação de outros benefícios com base na natureza do crédito, bem como uma ou mais fontes independentes de validação de dados que devem ser consultados antes da adjudicação do crédito pode ocorrer. Um único ou a combinação de tais fontes de dados independentes podem constituir a base para a validação do crédito, levando a um pagamento afirmativa decisão de aprovação ou de outros benefícios pelo sistema, sem a necessidade de verificação manual pelo requerente e beneficiário da cobertura do contrato de pessoal da empresa seguradora. No contexto do presente pedido contrato de cobertura de beneficio, qualquer direito contratual por um indivíduo para receber um pagamento ou outro benefício, como resultado da ocorrência de um evento coberto contratualmente, tais como morte, invalidez, incêndio ou desemprego. Exemplos de tal contrato cobertura um efeito benéfico incluem, sem limitação, uma apólice de seguro ou produto de proteção da dívida.

Para efeitos da presente invenção, seguro significa qualquer acordo contratual por uma companhia de seguros ou empresas de prestação mútua de um indivíduo ou grupo de indivíduos de proteção contra perdas financeiras resultantes da ocorrência de um evento coberto, incluindo mas não limitado a morte, deficiência, doença ou acidente, incêndio ou danos à propriedade real ou pessoal. Assim, o seguro inclui, sem limitação, seguro de invalidez de curto prazo ou a longo prazo, seguro saúde, seguro de doença grave, o seguro odontológico, seguro de vida, seguro de vida universal, ou variável de seguros de vida, anuidades, seguro contra incêndio, seguro residencial, tornado ou seguro do furacão, o seguro de inundação, seguro automóvel, seguro marítimo, e outras formas de propriedade e seguro contra acidentes.

Para efeitos da presente invenção , produto de proteção de dívida: um acordo contratual entre o mutuário ea instituição financeira, concessão de crédito para o mutuário qual, em troca de uma taxa, a instituição financeira compromete a suspender pagamentos mensais exigido principal ou os pagamentos de juros sobre uma operação de crédito, ou mesmo perdoar a totalidade ou uma parte das obrigações de reembolso de capital no caso de o mutuário sustenta um evento de vida, como morte, invalidez ou desemprego, o que tornaria difícil para que o devedor honrar sua obrigação de reembolsar a dívida. Para efeitos do presente pedido, instituição financeira, qualquer comercial, sem fins lucrativos, governo ou outra entidade no negócio de fornecer os fundos necessários para um cliente de varejo de bens/serviços de operação, de modo que tal cliente não precisa pagar em dinheiro para que transação. Exemplos de tais instituições financeiras incluem, sem limitação de bancos, instituições de poupança e empréstimo, cooperativas de crédito, e os braços de crédito dos comerciantes de varejo.

Conforme utilizado no presente pedido, deficiência significa qualquer limitação por um indivíduo na realização do material e dos direitos substanciais da sua actividade profissional regular devido a doença ou lesão que causa uma perda percentual mínimo pré-determinado que o salário mensal da pessoa devido a essa doença ou lesão.

Para efeitos da presente invenção, um underwriter é a pessoa dentro de uma empresa de seguros, instituições financeiras, ou de terceiros administrador, que deve determinar as taxas de prêmio para vários tipos de contratos de cobertura de benefícios, ea quantidade e grau de risco para ser assumidas pela companhia de seguros ou instituição financeira para cada tal política. Conforme utilizado no presente pedido, o beneficiário é a pessoa designada no âmbito de um contrato de cobertura de benefício para receber quaisquer pagamentos ou outras prestações devidas nos termos desse contrato. O beneficiário poderá ser um tomador pessoa física ou titular do contrato que os contratos de seguro ou cobertura de proteção de dívida sob a forma de, por exemplo, seguro de vida, seguro de invalidez complementar, seguro de proprietário, ou o seguro de automóvel, ou um grupo de indivíduos que estejam abrangidos por um tomador entidade patronal grupo de cobertura de seguro na forma de, por exemplo, o seguro de invalidez, seguro saúde, seguro dental, ou seguro de vida.

No contexto da presente invenção, requerente significa a pessoa que deposita o seguro de crédito ou produto de proteção de pagamento pela empresa de seguros ou de modificação de prazo de empréstimo pela instituição financeira. Na maioria dos casos, o requerente é beneficiário da cobertura do contrato benéfico. O sistema automatizado de processamento de requisição de crédito 10 da presente invenção é mostrado na figura 1. Um centro de comunicação com o cliente 12 é operado por uma companhia de seguros ou instituição financeira, 14 para fins de interagir com um beneficiário requerente 16 no que diz respeito a um pedido apresentado pelo requerente no âmbito de uma apólice de seguro. O centro de comunicação com o cliente 12 tem uma interface de 18 para interagir com os 16 do requerente, que pode incluir um representante para sinistros disponível por telefone, fax ou e-mail.

Alternativamente, essa interface 18 de maio permitir que o beneficiário originários ou acompanhar um pedido através do auto-serviço através de um site Internet ou um sistema de resposta de IVR. Independentemente de quem inicia a requisição, o sistema de processamento de pedido opera da mesma maneira.

Referindo-se à incorporação exemplo da figura 2, o sistema de tratamento automatizado de pedidos 10 dispõe de um computador programável geral 22 com uma unidade de processamento central (CPU) 24, que controla uma unidade de memória 26, uma unidade de armazenamento de 28, uma entrada/saida (I/O) unidade de controle 30, e pelo menos um monitor de 32. Computador 22 operatório conecta ao banco de dados 40, contendo, por exemplo, registros de contratos de cobertura de benefícios, os dados do requerente, e os dados pedidos. Ele também conecta-operatório para a ferramenta de avaliação de risco de 36 e ferramenta de verificação automática a perda de 38, que serão descritos mais detalhadamente aqui. O computador 22 de maio também incluem um circuito de relógio, uma interface de dados, um controlador de rede, e um barramento interno. Um hábil na arte reconhecem que outros componentes periféricos como impressoras, drives, teclados, mousses e similares também podem ser usados em conjunto com o computador programável 22. Além disso, um técnico no assunto vai reconhecer que o computador programável 22 pode utilizar conhecido hardware, software e configurações como de vários componentes do computador para otimizar o armazenamento e manipulação dos dados e outras informações contidas no sistema de processamento de pedidos automatizado 10.

O programa 34 pode ser concebida para ser uma expressão de um conjunto organizado de instruções em linguagem codificada. Estas instruções estão programados para facilitar a ingestão de avaliação dos pedidos de informação, do risco associado a esse pedido, e validação da requisição contra a fraude ou erro.

O sistema de computador no qual reside o sistema pode ser um PC, laptop, mainframe, dispositivo sem fio, ou qualquer equipamento para processamento automático de dados capaz de executar software para monitorar o progresso do material para transplante. A CPU controla o sistema de computador e é capaz de rodar o sistema armazenados na memória. A memória pode incluir, por exemplo, RAM de memória interna e/ou ROM, memória externa, como CD-ROMs, DVDs, pen drives, ou qualquer atualmente existentes ou armazenamento de dados futuros meios. O circuito de relógio pode incluir qualquer tipo de circuito capaz de gerar informações que indiquem o momento e/ou data. O circuito de clock pode também ser capaz de ser programado para contar a um conjunto predeterminado ou quantidade de tempo. A interface permite a comunicação de dados entre uma ou mais redes que pode ser uma LAN (rede local), WAN (Wide Area Network), ou qualquer tipo de rede que liga cada parte a requisição de manipulação. Sistemas de computadores diferentes, como, por exemplo, um laptop e um telefone celular geralmente usam protocolos diferentes (ie, diferentes linguagens). Para permitir que os dispositivos diferentes para se comunicar, a interface de dados pode incluir ou interagir com um programa de conversão de dados ou um dispositivo para troca de dados. A interface de dados pode também permitir que os dispositivos diferentes para se comunicar através de um Public Switched Telephone Network (PSTN), a Internet e redes privadas ou semi-privado. Referindo-se a fig. 2, sistema de tratamento automatizado de pedidos 10 inclui um programa de software 34 tendo uma pluralidade de interfaces gráficas do usuário (interfaces gráficas) que são exibidos para um usuário em um texto ou de forma gráfica para permitir a entrada de dados relativos ao titular do contrato benéfico cobertura, benéfico cobertura do evento da perda do contrato, e outros fatos subjacentes à requisição. A GUI também pode ser usado para exibir o status da requisição à companhia de seguros ou instituição financeira pessoal, bem como o cliente reclamante.

O programa 34 também pode produzir e imprimir uma série de reportagens que documentam essa informação. Finalmente, ele vai comunicar a decisão alegações da companhia de seguros ou instituição financeira para o requerente.

O sistema automatizado de processamento de requisição de crédito 10 da presente invenção é mostrada em maior detalhe nas figuras 3-4. Na fase de originação 50, de 16 requerente pode apresentar um novo pedido, ou verificar o status de um pedido existente, através da comunicação através de um site externo 52 ou IVR site entrada de telefone 54 mantidos pelo operador do sistema automatizado de reivindicação de processamento 10, ou através de créditos telefônicos de call center 56 representante do operador. Uma vez na interface 18, o sistema leva 10 a 16, o requerente a escolha entre o depósito de um novo pedido/ ativação, solicitando benefícios continuados, ou verificar o status de um pedido existente/ativação. O sistema de 10, então, proceder com o pedido de dados chave do requerente para 16 o contrato de cobertura de beneficio. Estes dados fundamentais para a identificação do requerente inclui uma ou mais das seguintes características: o sobrenome do requerente e código postal, o número da conta para o contrato de cobertura de benefício, a data de nascimento do requerente, ea ativação/número de requisição. Esses elementos de dados podem ser pré-selecionado pelo sistema de 10 com base no tipo de produto (ou seja, apólice de seguro ou contrato de protecção de dívida), produto do requerente, ou uma combinação dos mesmos. Dados incompletos irá impedir o requerente de proceder com o sistema 10.

Com base nestes dados introduzidos a partir do 16

requerente,	o sistema	de	processamento	de	pedido 10
determina se	ele tem uma	companhia de seguros	ou registro
instituição	financeira	que	corresponda	as	informações

digitadas. Os dados devem corresponder exatamente as informações do registro mantido pela companhia de seguros ou instituição financeira para fins de segurança. O sistema de alerta 10 de maio de 16, o requerente a manter uma senha para a apólice de seguro ou registros de proteção da divida do contrato como uma precaução de segurança adicional.

O sistema de 10 procede então à fase de direito 60. Durante esta fase, o sistema 10 tem os dados requerente-62 desde a entrada do sistema de prestações de 64, e automaticamente compara com dados de matriculas, 66 e 68 regras de inscrição armazenados no banco de dados do sistema para determinar se uma apólice de seguro aplicáveis ou contrato de dívida de proteção abrangendo do beneficiário para o evento apresentou perda preexistia a data de alegado prejuízo. Durante esta fase de direito 60, elementos adicionais de dados são coletados a partir do reclamante para iniciar a fase de instalação 70. É durante esta fase de direito 60, que os 16 requerente também pode verificar o direito às prestações continua sob a sua apólice de seguro, digitando seu crédito/número de ativação. O sistema vai fornecer uma resposta com base em suas regras de direito armazenados 68 descrevendo os termos da referida apólice de seguro.

Em seguida, Sistema automatizado de processamento de requisição de crédito 10 cria durante o set up fase de 70 a reivindicações registro definir o contrato cobertura de benefícios e as informações relevantes que descrevem o evento de perda que formam a base para a reivindicação. Esse registro será avaliado pelo sistema durante a subsequente fase de avaliação de risco 80 e fase de verificação automática perda de 90 a automaticamente julgar o pedido, conforme descrito aqui.

Para novos pedidos, se a cobertura não for encontrado, então o sistema de 10 pedidos que a revisão 16 requerente as informações digitadas e re-enviá-lo. Após uma segunda tentativa mal sucedida, o requerente é perguntado sobre várias questões relativas à política ou do contrato e o tipo de de cobertura. Com base na informação prestada, a resposta será da seguinte forma, dependendo do meio utilizado para interface com o sistema de 18 (web, IVR, telefone, etc):

• Web: o sistema fornece ao requerente um número de chamada gratuita para pedidos de mais ajuda. Este número gratuito ignora o IVR e vai diretamente para um conhecedor créditos associados.

• IVR: o sistema transfere o requerente apresenta um pedido de conhecimentos associados.

• Telefone: associar as reivindicações tenta identificar a cobertura do requerente, solicitando informações adicionais.

• Correio/Fax: associar as reivindicações tenta

identificar	a cobertura	requerente.	Se vencida, os
formulários	são devolvidos	ao requerente	com uma letra e
outras instruções.
Se a	cobertura for	encontrada,	então o sistema
solicita a	contar da data	do requerente	de perda e exibe

todas as opções de cobertura a data da perda. O requerente escolhe tipo de perda e se move para a fase de montagem 70. Se os registros são encontrados vários cobertura pelo sistema que atendam o tipo de perda e data do sinistro, o requerente é solicitado a selecionar quais os benefícios que ele quer ativar/arquivo de um pedido de. Uma vez que a seleção é feita pelo requerente e, em seguida a fase de direito 60 e termina a fase de montagem 70 começa. Nesta fase de montagem, todas as informações necessárias para criar um pedido/registro de ativação é recolhido pelo sistema e verificada. Se os registros de cobertura são encontrados vários, mas nenhum cumprir a data de perda e/ou tipo de perda, em seguida, o requerente é informada sobre a cobertura que ele tem, com resumo, os termos cliente amigável e condições.

Se a cobertura for encontrado, mas o requerente não pode beneficiar de prestações devidas a um período de espera ou de outro requisito, o requerente é avisado desse facto e será solicitado a salvar as informações digitadas. Para guardar as informações, o requerente deve digitar um e-mail ou endereço. O sistema salva as informações e emails / envia uma carta ao requerente, uma vez a exigência período de espera foi satisfeita (com base em informações prestadas durante a fase de direito) . 0 requerente é dado um número de origem que lhe permitirá o acesso às informações digitadas, quando as exigências forem atendidas.

As informações devem ser mantidas no sistema de 10 para até 90 dias após a exigência for atendida. Se, após 90 dias, o requerente não tenha contactado o Centro de Sinistros 12, em seguida, uma notificação final é enviado ao requerente, e de 120 dias, a informação é excluída. Uma vez que o requerente se encontra em seu crédito existente/ número de ativação, o sistema de 10 exibe o status da requisição. O requerente, em seguida, verifica as

informações e procede	à	avaliação	do risco da	fase 80 do
sistema automatizado presente invenção.	de	reivindicação de processamento da
Durante a fase	de	montagem	70, todas as	informações

necessárias para estabelecer um registro de ativação requisição é recolhida e verificada pelo sistema de 10 antes de prosseguir para a fase de avaliação de risco 80, perda de verificação automática fase 90, e julgamento da fase 100. O requerente verifica as informações, tais como o nome do requerente/segurado, endereço, telefone, endereço, tipo de perda selecionado, ea data da perda entrou durante a fase de direito 60. Durante esta fase, o requerente é solicitado a selecionar o tipo de comunicação para o sistema de envio de sua decisão de adjudicação em relação ao pagamento sobre o pedido apresentado. O padrão é enviar e-mail, mas outras opções incluem o correio eletrônico e comunicação verbal.

Se esta seleção do tipo de comunicação é feito através de um link IVR, o sistema mantém um log de seleção e atribui-lo para o registro do cliente. Se isso for feito, enquanto no telefone com um colega de reivindicações, em seguida, as fitas associar a autorização. Gravado autorizações são dadas um número de confirmação que é anexado ao registro requerente para que ele possa ser recuperado no futuro.

Comunicação Verbal do tipo único significa que o requerente aceita a notificação verbal e desligar qualquer web ou papel de comunicações que resultam de uma chamada telefônica. Esta opção mostra apenas se o requerente está trabalhando com uma reivindicação associar via telefone. Quando essa opção for selecionada, o requerente está dando a autorização de créditos associados para não enviar a confirmação por escrito. Se este tipo de comunicação é selecionado, um adicional é necessário para operações de telefone não - por exemplo, Web/IVR. O requerente compromete-se a requisição de configurar, clicando em um botão de confirmação de set-up. Neste momento, o sistema exibe 10 as restrições associadas à abertura do crédito. Os exemplos incluem:

• Cartão de Crédito Uso Restrições (o requerente não pode usar o cartão de crédito durante a ativação).

• Período de espera entre as ativações (uma vez que a requisição seja aprovado, o requerente não pode apresentar outro pedido até 30 dias após o último pagamento até a data da requisição atual).

requerente é dada a oportunidade para a seleção de todos os registros de cobertura que ele não deseja prosseguir com. O sistema mantém um registro 10 na transação dos registros selecionados e não selecionados registros.

O requerente compromete o sistema e 10 oferece uma tela pop-up pedindo-lhe, Você tem certeza de que deseja criar um registro de pedidos de cobertura dos registros selecionados? Se o requerente selecionar Não, então o processo termina e um registro da operação é armazenado. Se o requerente seleciona Sim, em seguida, o requerente tem a oportunidade de estabelecer níveis de segurança. Baseado no setup requerente (não todos os credores podem optar por utilizar esta opção) , o requerente é dada a oportunidade de criar uma pergunta de segurança e senha. Esta senha será armazenada e ser necessário para alguém obter informações para esta conta reclamante. 0 sistema de processamento de pedido mostrado na figura 10. Inclui um processo de avaliação de risco módulo 82 para realizar fase de avaliação de risco 80 do processo subjacente. Associados com o módulo de avaliação de riscos é um processo 82 modelo 84 para predizer o risco relativo da cobertura de benefícios fraudulentos ou reivindicação a ser incorrectos. Um conjunto de regras de negócios 84 armazenados no banco de dados do sistema é utilizado pelo sistema de 10 para ativar o módulo de processo de avaliação de risco, utilizando modelo 82. Também está associado com o processo de avaliação de riscos 82 é uma tabela de escore de risco 86, que atribui uma pontuação de avaliação numérica de risco para o pedido de cobertura do contrato benéfico, em resposta à saída de previsão de risco do modelo 82. Log de auditoria 88 armazena os dados para o resultado de risco do mundo real do contrato de cobertura beneficio reivindicado anterior semelhantes para o crédito em questão. Usando essas informações, o modelo preditivo 82 podem ser modificados pelos operadores do sistema de 10 para torná-lo o mais preciso possível.

Na fase de avaliação de risco 80, as informações inseridas durante a origem, o direito, e set-up fases forem combinadas com outras informações, como saldo da conta, a pontuação de crédito do cliente, idade, etc, para avaliar o risco relativo do crédito a ser fraudulento, e atribuir uma pontuação de risco. Ά fase de avaliação de riscos 80 do sistema de processamento de pedido 10 utiliza uma ferramenta baseada em técnicas avançadas de modelagem preditiva para permitir que a companhia de seguros para avaliar o risco relativo associado com uma requisição, modelagem estatística utiliza atributos de dados de todos os segurados a desenvolver uma ferramenta de avaliação automática de risco (rato) 36 (ver figura 3.) para avaliar o risco associado a um pedido particular. Os modelos resultantes (na figura 4.) Considerar todas as possíveis tendências entre as variáveis para avaliar o modelo de requerimento e os potenciais riscos a ele associados.

Exemplos de diferentes fatores de risco associados a uma reivindicação de seguro são estabelecidos na Tabela 1.

Tabela 1: Riskyapfoilnformatiprij exemplar

CDs de dados (armazenados no Oracle) saldo em dívida; quanto tempo tem sido cobrado do tomador, o montante do prêmio, que o tomador do seguro só se inscrever, tem o segurado já cancelada; tem o segurado foi inscrito por um longo tempo?

Demográficas endereço Customer Data.

Créditos História (armazenados no Oracle) Tem o segurado já arquivou uma reivindicação com a companhia de seguros antes, que o tomador tem outros créditos em dívida, o que é o tomador do seguro é status créditos em curso; outros dados pedidos variável não aqui listados. Dados Enviados pelo requerente (passado por estes são todos os itens que o requerente ou reclamações Portal) entra na web ou IVR ou explica o representante através do telefone. Esses itens são utilizados posteriormente para chegar a uma decisão. Os exemplos incluem: data da perda, tipo de perda, da data de nascimento, data do último trabalho etc O RAT 36 modelo pré-scores toda a base segurado em uma base periódica (por exemplo, diária, semanal, mensal). Cada segurado tem vários pré-scores no produto/nível de cobertura. O pré-scores são armazenados no data warehouse da Oracle mantido pelo sistema 10.

Como uma reivindicação de seguro específico vem, as informações inseridas durante a originação, o direito e as fases de set-up de 50, 60 e 70 são combinados com as informações utilizadas no processo de pré-marcar a recontagem individual de cada pedido em tempo real. Note que os pedidos de benefícios de continuar, pelo contrário, passam por diferentes modelos de ratos adaptados à prossecução créditos só.

Ao fazer isso, os requerentes podem ser classificados pelo perfil de risco mais elevado para o menor. Estas recorrentes podem ser agrupadas por categoria de risco. Usando essas categorias, as seguradoras e credores podem determinar em que medida a uma etapa de validação deve ser aplicado a um pedido especial, como parte do processo de adjudicação. A decisão de qual fonte usar também modeldriven, onde o nivel de confiança para cada fonte de dados é determinada utilizando uma variedade de técnicas de modelagem estatística. Por exemplo, nas ilustrações requisição morte discutido anteriormente, essas duas afirmações podem receber qualquer risco alto ou baixo associado com o pedido. No caso de morte envolvendo o segurado com 80 anos de idade, o modelo pode o perfil de risco mais baixo. No caso da requisição de US $ 100.000, o modelo pode categorizar o crédito elevado. Em resposta a estas categorias, a companhia de seguros pode decidir aprovar o risco de crédito menor no início do processo de validação com as técnicas de proporcionar um menor nível de confiança. Além disso, o seguro da empresa pode optar por aprovar o maior risco de crédito somente após receber mais informações para a validação de perda, o que proporciona um maior grau de confiança. Por exemplo, no primeiro caso, a companhia de seguros pode aceitar um obituário como prova da morte, para aprovação. No segundo caso, a seguradora poderá exigir uma certidão de óbito do Estado, como prova da requisição de aprovação.

O RAT 36 serão de preferência, incluir uma tabela look-up que podem ser utilizados pelo computador 22 subjacente ao sistema 10, ou por um funcionário da empresa benéfico cobertura contratual que manualmente conduz a requisição de exercício de validação, tabela look-up Tal poderá adoptar a forma do quadro 2, no qual o nível de risco relativo de uma requisição é traduzido em um nível aproximado de confiança (ou seja, a prova) que é exigido pela seguradora ou instituição financeira para aprovar o pedido, tendo em conta o nível de risco associado a esse pedido.

Tabela 2

Nível de Risco Nível de Confidencia (muito baixo) 0%

1(baixo) 40%

60%

80%

4(alto) 100%

Assim, uma pontuação de 4 determina que a operação é de alto risco e podem exigir a validação através de uma fonte de dados, que foi determinada para fornecer 100% de confiança, ou em combinação de fontes que coletivamente fornecer 100% de confiança, sob a forma de documentação completa antes de um pagamento ou adiamento é concedido. Em contrapartida, uma baixa pontuação de 1 pode render menos exigência de documentação. A pontuação muito baixa 0 pode levar qualquer validação necessários através de uma fonte de dados para aprovação.

É importante para a validade do sistema automatizado de reivindicação de processamento 10 da presente invenção que os modelos avançados de previsão subjacente à ferramenta RAT 36 e 82 associados modelo ser verificada periodicamente contra os resultados reais para a validade das reivindicações apresentadas pelo requerente. Assim, as fontes de dados são controlados, monitorados e validados por um porão aleatórios amostra de 89 reclamantes que registrar uma requisição. A aguentar amostra 89 é gerado aleatoriamente, selecionando cada cliente nth. A aguentar amostra 89 é marcado pela ferramenta de RAT 36 e verificada por um ou mais dos verificação perda automática (ALV fontes) de dados - de preferência por todas as fontes de dados disponíveis se a confiança máxima que o sistema de trabalho é 10 é desejado. O sistema irá comparar o resultado de cada fonte de dados de verificação contra o resultado da verificação da perda requerente fornecido a fim de determinar que os modelos de sistema de ALV estão funcionando corretamente. Algumas das tendências, como os clientes que nunca desde a verificação da perda (abnegação) serão analisados e acompanhados em cima para determinar se as alterações precisam ser feitas para a fonte de dados (por exemplo: ajustar o nivel de confiança).

E possível que a companhia de seguros ou instituição financeira não pode exigir a validação de um pedido com um nível muito baixo risco (por exemplo, nível de risco 0), porque tanto o que parece ser válido na sua cara, ou então o montante da crédito em causa é demasiado baixo para garantir o custo do processo de validação. Nesse caso, o sistema de processamento de pedido 10 será estruturado para enviar esta requisição diretamente para a fase de julgamento 100 (ver figura 3.) Para comunicar uma decisão positiva para o pagamento ao requerente.

Os parâmetros para os modelos e valores RAT mesadriven são mantidas em um console de gerenciamento. Este console de gerenciamento permite a alteração/adaptação de pontuar elementos de dados, coeficientes, fontes de dados e níveis de confiança. Teste de hipótese é feito dentro de um ambiente controlado, utilizando o console de gerenciamento. A capacidade de testar teorias é permitida ao nível de gestão. Relatando na linguagem comercial comum é desenvolvido para que usuários possam tomar decisões baseadas em testes. No caso da tabela look-up ditou algumas medidas de nível de confiança exigido acima de 0% para o crédito no âmbito da avaliação de risco 80 fase, o sistema avançará para a fase de verificação automática a perda de 90. Automatizado de verificação da perda ou ALV é uma 5 ferramenta mesa-driven 38, que está ligado a várias fontes de dados, dependendo do tipo de perda. É o trabalho da ALV ferramenta para automatizar o processo de verificação através da atribuição de um requisito nível de confiança baseado no escore de risco e do produto, tipo de produto, 10 cliente e/ou estado (qualquer combinação). Então, com base no requisito de nível de confiança especificado para o pedido, uma tabela separada look-up identifica a fonte de dados independente ou uma combinação de fontes independentes de dados necessários para validar o pedido 15 com base em sua classificação de risco. A Tabela 3 ilustra como uma tabela look-up.

Tabela 3

Nível de confidência requerido para aprovar a requisição	Combinação de fonte de dados independentes
0%	Nenhuma
40%	A
60%	A, B
80%	A, B, C
100%	A, B, C, D

Alternativamente, um algoritmo ou lógica de base armazenados no software 34 pode ditar o fim das fontes de dados utilizadas pelo sistema. Cada uma destas fontes de dados independentes especificado então ser consultado 5 automaticamente pelo sistema de 10 por sua vez, para verificar o prejuízo alegado.

Uma lista com exemplos de fontes independentes de terceiros disponíveis para validar um pedido, eo nível de confiança relativa atribuída a cada fonte, é mostrada na 10 Tabela 4.

Tabela 4

Fonte de dados	Uso
Medispan Base de dados indicação de drogas	Verificar se um cliente está tomando medicação para uma condição específica.
Dr. 411 Doctor Database	Confirma: o médico e prático do paciente, potencialmente contata um médico
Intellscript Prescription Base de dados Milliman Co.	Verificar se um cliente está tomando medicação para uma medicação específica, acessando seu histórico de receita.
Medical Disability Advisor Official Disability Guidelines Reed Group	Determina períodos de benefício por invalidez e/ou requisições de auxílio desemprego
Claims Activity Index Medical Information Bureau	informações do cliente para acesso a validação dos créditos
Ingex	Verificar se um cliente está tomando medicação para uma medicação específica, acessando seu histórico de receita.
Scriptcheck	Verificar se um cliente está tomando medicação para uma medicação específica, acessando seu histórico de

	receita .
Obituary Registration.com	Pesquisa orbituário do falecido para verificar a morte
State Unemployment Offices	verifica o estado de desemprego
States Disability Offices	verificar se o estado de invalidez permanente foi concedido
Trusted Partners	Aceitar a verificação de parceiros da empresa de seguros (não é limitado a clientes)

A tabela a ALV, algoritmo ou ferramenta base lógica orientada 38 é conectado a várias fontes de dados, dependendo do tipo de perda. É o trabalho da ALV ferramenta para automatizar o processo de verificação pela atribuição de um requisito de nível de confiança para o pedido, com base no escore de risco e seguro do produto, tipo de produto, cliente e/ou estadual, ou qualquer combinação destes. A ferramenta de ALV tem a capacidade de recuperar informações de diferentes fontes de dados e acumular pontos/níveis de confiança, baseado em informações obtidas de cada uma das fontes de dados. Baseado no nível de confiança exigência de crédito, cada uma das fontes de dados necessário para atingir o nível de confiança é consultado para verificar automaticamente a perda. Algumas fontes de dados têm níveis de confiança diferentes com base no tipo de verificação que pode ser obtido a partir deles. Por exemplo, no caso do SSDI, a confirmação da morte de P pode resultar em um nível de confiança de 100%, enquanto a confirmação da morte de V pode render apenas uma pontuação de 50%. Cada fonte de dados os laços com um ou vários tipos de perda e podem ter resultados diferentes de confiança, dependendo do tipo de produto, produto, cliente, estado tipo de perda e/ou qualquer combinação, com base na configuração no nível de ALV.

Em uma modalidade preferida da ferramenta de verificação automática perda da presente invenção, o sistema atribui um nível de confiança exigido alvo (TCL) para validar um contrato de cobertura particular benéfico crédito correspondente ao escore de risco atribuída a essa reivindicação. Note que, assim como o escore de risco pode ser definido pela empresa seguradora ou instituição financeira que concedeu a apólice de seguro ou contrato de dívida de protecção em conformidade com a sua experiência reivindicações e políticas de subscrição, a companhia de seguros ou instituição financeira pode selecionar os seus próprios exigido TCL com base aceite o seu apetite para risco. Uma companhia de seguros ou instituição financeira pode aceitar um maior grau de risco para créditos potencialmente fraudulentos ou de outra forma imprecisa, e, portanto, requerem uma menor TCL para validar uma requisição nos termos desta ferramenta automatizada perda de verificação. Este valor mais baixo TCL vai permitir reduzir os custos administrativos associados ao processo de validação de créditos utilizando a ferramenta de verificação automática perda da presente invenção. Em contrapartida, outra companhia de seguros ou instituição financeira pode exigir um valor maior TCL, a fim de validar o pedido, devido ao nivel reduzido de risco aceito. Isso resultará em uma maior combinação de fonte de dados corroboradora as referências usadas para validar o pedido utilizando a ferramenta de verificação automática da perda. Cada uma das fonte de dados corroboradoras tem atribuído a ele uma pontuação de validação contributivo proporcional ao seu grau relativo de confiança para determinar a veracidade da requisição. Por exemplo, o cliente forneceu informações sobre a morte de uma apólice de seguro de vida somente pode ser caracterizada por um grau de confiança de 40%, enquanto que um obituário do jornal pode fornecer um grau de confiança de 60%. O jornal é uma fonte independente, logicamente, o direito de mais credibilidade para a veracidade do que o reclamante, a si mesmo. No entanto, os escritores do jornal ter sido conhecida a cometer erros.

Uma lista de falecido na Segurança Social Death Index, por outro lado, poderá ter direito a um nível de confiança de 80% da pontuação, devido ao processo de verificação de documentos utilizados pela Previdência Social para verificar a morte antes de início do pagamento das prestações. Finalmente, um atestado de óbito certificado emitido pelo governo local irá estabelecer o fato da morte com um grau de 100% de confiança. Note-se que a companhia de seguros ou instituição financeira pode determinar a sua pontuação própria confiança que atribui a cada fonte de dados corroboradora de acordo com sua própria experiência créditos de validação e perfil de tolerância ao risco.

O sistema da presente invenção realiza os seguintes cálculos iterativos para fins de utilização de fontes disponíveis corroborando os dados para validar um pedido:

Valor acumulado Verificação valores Σ de fontes de dados controlados (VAV) para o crédito.

Restante Verification Value (TCL - AVV), necessários para o RVV (crédito).

Possíveis Verification Value valores de Σ disponível unchecked (PVV Fontes) Dados para o pedido. Valor de verificação máximo valores Σ de todos os dados disponíveis (MVV) Fontes da requisição no início do processo automatizado perda de verificação. Eventual de Verificação de duração Σ todos PVVs (bater ou não bater) para cada valor (RPVV) pass: RPVV = PVV A ALV processo contínuo para os créditos só será iniciada se o período transitório para o produto correspondente/ cliente foi excedido. Se o período correspondente benefício ainda está ativo, então o processo de ALV não devem ser utilizados. Em vez disso, o processo de reivindicações deve prosseguir diretamente para a fase de adjudicação. Se a prova da perda de cobertura do contrato benéfico foi fornecida pelo requerente, o processo de ALV igualmente deve ser ignorada. Finalmente, o pedido deve ter passado a fase de Direito antes de iniciar o processo de ALV. Uma série de regras específicas são aplicadas à administração do processo de ALV. Em primeiro lugar, uma fonte de dados corroboradora, que pode ser um banco de dados interno mantido pelo operador do sistema de ALV, ou então um banco de dados externo fontes, só serão acessados se a TCL é atingível e que lhe foi atribuído como fonte de validação para a linha correspondente do negócio (produto/ componente do cliente). Assim, TCL> MVV.

Por outro lado, uma fonte de dados corroboradora serão usados apenas uma vez durante o julgamento de uma requisição, exceto quando indicado como fonte de validação de data-relacionados, ou se uma tentativa anterior de um banco de dados de pesquisa não conseguiu produzir um jogo. Em terceiro lugar, a pontuação de confiança de cada fonte de dados corroboradora sucessivamente procurou com um jogo para a reivindicação será adicionado ao AVV, de modo que a pontuação AVV representa a corrente, a validação da pontuação cumulativa para essa reivindicação. Em quarto lugar, depois de cada pesquisa corrobora os dados de origem, a pontuação AVV é comparado com o valor necessário TCL para que a requisição para determinar a pontuação TCL foi alcançado ainda para essa reivindicação. Se a pontuação TCL foi atingido, então o processo de ALV não for concluído eo sistema de processamento de pedidos 10 receitas para a fase de adjudicação 100 para a reivindicação. Se a pontuação TCL ainda não foi preenchida em relação ao pedido, o processo de ALV deve apenas continuar com a consulta das restantes fontes de dados corroboradoras disponíveis para o crédito se o valor do crédito para RVV (TCL - AVV) é alcançável pelo PVV dos restantes, corroborando os dados de fontes não-verifiçado. Se o valor dos restantes PVV, desmarcado fonte de dados corroboradoras não exceda a pontuação RVV para a reivindicação, o processo conclui ALV, e as reivindicações sistema de processamento de 10, deve proceder à verificação da perda de clientes, desde do crédito antes da fase de julgamento 100 é atingido.

Exemplo 1 Um exemplo da aplicação da ferramenta ALV processo da presente invenção a uma reivindicação política de seguro de vida é mostrado na figura. 5. Para que a requisição da política de seguros de vida 150, o processo de ALV tem préatribuídos dois corroborando os dados de fontes: o Social Security Death Index (SSDI) 152 administrado pela Federal

Social Security Administration, e um indice de 154 óbitos. 0 mecanismo de regras do processo ALV ferramenta contém uma tabela de conversão de TCL 156 pré-estabelecidos pela seguradora que emitiu a apólice de seguro de vida. Este quadro indica que, para um seguro de vida do tipo que é objecto da requisição de beneficio, uma pontuação de avaliação de risco (RAS) 158, de 1 traduz a pontuação necessária TCL 159, de 30% para validar um prejuízo invocado. A RAS, de 2, por outro lado, exige uma pontuação TCL de 40%. Os valores correspondentes RAS, de 3, 4 e 5, se traduzem em resultados TCL exigido de 75%, 85% e 100%, respectivamente, no âmbito do processo ALV exemplar.

De acordo com o mecanismo de regras, o processo de ALV primeira consulta o SSDI, que está acessível online. Se houver uma correspondência entre o número da pessoa falecida segurança social e data da morte prestadas pelo requerente e do registro SSDI, então o valor de confiança atribuído pré-50 é adicionado à pontuação AVV, como resultado dos dados deste jogo. Assim, AVV = 50% para o processo automatizado de reivindicação de validação. Neste caso, os créditos com uma pontuação de RAS, de 1 ou 2 e conseqüente exigência TCL de 30% ou 40% seria verificada, porque AVV> TCL. Tais reivindicações se movería para a fase de adjudicação.

Para reclamações, com uma pontuação de 3 RAS, 4 ou 5 correspondente a uma pontuação TCL de 75%, 85%, ou 100%, respetivamente, no entanto, do processo de ALV tem de prosseguir. Neste caso, o retorno SSDI Código de referência SSDI é consultado. Se o Código de retorno tem uma P valor, significando que a prova do falecido de morte sob a forma de um atestado de óbito já estava prevista para a Administração da Segurança Social, um valor de confiança adicional de pré-atribuido de 50% seria adicionado à AVV pontuação, assim AVV = 100%. Neste caso, todos os créditos com um valor RAS, de 3, 4 e 5 deverá ser verificada. Se, pelo contrário, a morte do defunto era apenas telefonou para a Administração da Segurança Social sem comprovação de um atestado de óbito, em seguida, o código de retorno SSDI será V, no caso, um valor adicional de confiança prédeterminadas de 25% será adicionada à pontuação AVV, para AVV = 7 5%. Nesse caso, um pedido com um valor de 3 RAS seria verificada, mas a prova adicional seria necessário para um pedido com um valor RAS de 4 ou 5. Se o registro SSDI desde uma correspondência para o falecido número de segurança social relatado pelo requerente, mas não a data da morte, então o processo de ALV procede a uma determinação da diferença entre a data SSDI da morte e da data da morte relatada na requisição. Se a diferença for < 2 dias, então AVV = 40% para o crédito. Neste caso, afirma ter uma pontuação RAS de 1 ou 2 seria verificada, enquanto aqueles com escores RAS, de 3, 4 ou 5 não. Se, por outro lado, a diferença entre a pedida é relatado e as datas de morte menos de 7 dias, então o valor

aportado por AVV	SSDI a referência	seria	apenas de 30%,
portanto, apenas verificadas.	um pedido com um	valor	de 1 RAS seria
Para todas	as reivindicações	não	verificadas com

êxito pelo registro SSDI, o processo de ALV procederá à consulta de um banco de dados do obituário 154. Se um registro obituário de correspondência para o morto é encontrado com o mesmo nome, a data da morte, estado e cidade em comparação com as informações encontradas no pedido, em seguida, um adicional de 50% é adicionado à pontuação AVV para a reivindicação. Se o RVV para uma reivindicação unverified <50% após o uso dos registros SSDI, em seguida, esses créditos serão verificadas por um casamento bem-sucedido obituário banco de dados.

Exemplo 2

A figura 6 apresenta um exemplo de aplicação do processo de ALV da presente invenção a um seguro de desemprego involuntário (IUI crédito). 0 motor de regras já pré-qualificadas pelo TALX TPA trabalho de verificação de banco de dados 172 como fonte de dados corroboradora para verificar um pedido de IUI. Esta base de dados será acessado por todos os clientes a apresentação de um pedido de desemprego. Nem todos os empregadores fazem parte deste banco de dados, assim que o processo ALV primeiro verifica o TALX TPA trabalho de verificação para o nome do empregador. A partida não contribui para o nivel de confiança de AVV para a reivindicação, mas permite que o processo ALV para prosseguir.

Em seguida, o processo verifica a ALV TALX TPA banco de dados para o nome da pessoa desempregada, o número de segurança social, e data da rescisão. Se esta informação no registro do banco de dados coincide com as informações prestadas pelo requerente, o processo de ALV contribui valor de 100% de confiança para a pontuação AVV para a reivindicação. Neste caso, o pedido, independentemente do seu valor RAS 176, seriam verificados por 178 a AVV escore> TCL.

Se a data de cessação relatado no banco de dados TPA TALX não coincide com a data de cessação prestadas pelo requerente, a diferença entre essas datas devem ser calculados no âmbito do processo de ALV. Se essa diferença não ultrapassa 7 dias, então um valor de confiança de 75% serão aportados ao AVV. Essa pontuação seria um AVV verificar todas as reclamações IUI com uma pontuação RAS de 1, 2 ou 3. IUI alega ter um escore de risco 4 ou 5, pelo contrário, exigiría prova fonte adicional corroborando os dados, o que podería ser na forma de desemprego do governo estadual, 180 ou verificação das informações fornecidas diretamente pelo empregador anterior 182. Se a diferença for superior a 7 dias, mas é inferior a 30 dias, então apenas 40% de confiança, o valor será contribuiu para a pontuação AVV para a reivindicação.

Exemplo 3

A figura 7 fornece um exemplo de aplicação do processo de ALV da presente invenção a uma reivindicação política de seguro de invalidez. A requisição de deficiência da política de seguros 190 tem associado a ele uma tabela look-up contendo 192 escores predeterminados RAS 194 e valores associados TCL 196. Uma variedade de fonte de dados corroboradoras 198 também é apresentada pela companhia de seguros para fins de verificação de uma apólice de seguro de deficiência no âmbito do processo de ALV.

Por exemplo, o médico lista de provedor de banco de dados pode ser acessada 200 para médicos e outros provedores de serviços médicos e de prestação de serviços ao paciente. Se um nome e número de telefone para o provedor de serviços médicos coincide com as informações prestadas pelo requerente, em seguida, um nível de confiança de 30% contribuiu para a pontuação AVV para a reivindicação. Neste caso, a requisição de ter uma pontuação de 1 RAS será verificada, enquanto afirma ter uma contagem de 2-5 RAS exigir corroboração adicional fonte de prova da sua veracidade.

O CID9 Diagnóstico / Especialidade banco de dados 202 contém uma lista de especialidades de serviços médicos e diagnósticos típicos associados com a especialidade. Um casamento bem-sucedido do diagnóstico fornecido pela reivindicação de seguro por invalidez com a especialidade do prestador de serviços médicos já verificado pelo banco de dados Lista de Medicina Provider 200 irá contribuir com 20% de confiança de valor, de modo gue AVV = 50%. Este irá verificar um seguro de invalidez com uma pontuação de 2 RAS. O processo de ALV, então, proceder à consulta de banco de dados de drogas Indicações 204.

Esta base de dados contém uma lista de nomes de remédios e médicos para o diagnóstico que são geralmente prescritos. Se um jogo entre a prescrição de medicamentos e informações de diagnóstico médico fornecido pelo requerente for encontrado no banco de dados Indicações de drogas, depois 20% de confiança é o valor adicionado ao escore de AVV para a reivindicação. Neste caso, a resultante de 70% da pontuação AVV não verificar a requisição RAS com uma pontuação de 3-5.

Requerente (206), autorização sob HIPAA para a companhia de seguros para verificar os registros médicos prevê um adicional de 5% de confiança é o valor aportado por este particular fonte de dados corroboradora. Agora, a pontuação AVV para a requisição é de 75%. Isso valida um seguro de invalidez requisição de ter uma pontuação de 3 RAS, mas não aqueles que têm uma pontuação de 4-5 RAS.

banco de dados CID9 208 contém uma lista de CID9 códigos atribuídos para o diagnóstico correspondente. Se este coincidir com o banco de dados de código CID9 fornecidas no pedido, então 25% de confiança é o valor contribuído para o escore de ACC para a reivindicação. Neste caso, o resultado de 100% da pontuação AVV seria verificar todos os créditos com uma pontuação de 4-5 RAS. Note, no entanto, que, se uma correspondência com o Provedor de Lista Medical Database 200 para o nome do especialista em atendimento médico não foi encontrado, então o banco de dados CID9 Specialty 202 não podería contribuir pontos confiança também. Nesse caso, bemsucedidos de usar esta droga Indicações de banco de dados 204, HIPAA consentimento autorização 206, e CID9 Database só fornecer um valor AVV total de 50%, portanto, apenas RAS 02/01 reivindicações seriam verificadas.

A Receita História Database 210 contém uma lista de medicamentos prescritos a um paciente em particular. Se o número de segurança social, data do sinistro, e os registros de nome no banco de dados Histórico da prescrição 210 informações partida no pedido eo nome da prescrição corresponde à receita identificados no crédito, então o uso desta fonte de dados corroboradora particular valor de fornecedores de confiança de 25% uma primeira reivindicação política seguro de invalidez e de 100% para um crédito de continuar. Isso pode ser suficiente para produzir uma pontuação AVV que exceda a pontuação necessária para a afirmação de TCL.

Portanto, o cálculo para RVV e PVV será recalculado de forma recursiva para um pedido depois de cada fonte de dados corroboradora é utilizado na validação ALV 38 processo. Esse processo determina se o valor exigido para a requisição TCL foi alcançado para validar o pedido, ou se o processo de ALV deve continuar a consulta outra fonte de dados corroboradora caso em que quaisquer dados adicionais necessários a partir da requerente é identificado. Como o custo das fontes de dados de terceiros tem impacto sobre a economia do sistema de 10, é importante utilizar a fonte mais rentável ou uma combinação de fontes que fornece o nível de confiança necessário para as reivindicações decisão de adjudicação processo de decisão. A ferramenta de verificação automática a perda de 90 da presente invenção consultar cada uma das fontes de dados independentes na sucessão de menor nível de confiança ao mais alto nível de confiança. Assim, se a informação da perda de clientes desde corrobora a requisição de satisfazer o nível de confiança necessário, em seguida, o sistema procede à decisão nos termos do ponto para a fase de julgamento 100. Se o nivel de confiança exigido não for atingido, então o sistema irá proceder à busca de fontes de sucessivas corroborando os dados até AVV> TCL para a reivindicação. Dependendo do risco do crédito, o sistema pode ter definido um nível de confiança muito elevados que só podem ser satisfeitas por duas ou mais fontes de dados independentes em combinação.

Se o nivel de confiança exigido é atingido, a fase de ALV 90 é completo eo crédito / movimentos de ativação para a fase de adjudicação 100. Se o nivel de confiança não for atingido, a fase de ALV 90 é completo, o nível de confiança exigido eo nivel de confiança alcançado é gravada, ea requisição movimentos / ativação de uma prova de clientes desde do processo de perda.

Assim, ao contrário de antes arte sistemas de processamento de crédito utilizadas na indústria, onde as companhias de seguros e instituições financeiras geralmente a carga do cliente com a tarefa de fornecer as informações necessárias para validar o evento, o sistema de 10 da presente invenção salva o requerente, na maioria dos casos de este encargo. Por exemplo, sob o enfoque da arte prévia, o beneficiário apresentar uma requisição a morte é solicitado a fornecer a companhia de seguros com o atestado de óbito antes da requisição de aprovação. Um depósito segurado um pedido de deficiência é obrigado a fornecer um formulário assinado pelo médico validar sua deficiência e da incapacidade para o trabalho. Esta etapa de fornecer ao cliente os custos de uma prova de tempo e dinheiro. Além disso, os custos de recursos da empresa de seguros para documentar o pedido de informações, acompanhamento da requisição, processar as informações recebidas e reter as informações para referência futura. Acrescenta também que o tempo de ciclo necessário para cumprir o benefício de volta ao cliente.

Pedindo o recorrente a prova da perda é uma organização não-standard, método de verificação menos preferido perda nos termos do presente invenção. Créditos / ativações que não se qualificam para a verificação da perda automática devido ao risco/níveis de confiança não sejam atingidos, ou por cliente/produto/exigências do estado irá desencadear este requisito. 0 requerente é solicitado para completar certas informações e/ou anexar a documentação exigida (web). Por exemplo, uma Declaração de Atendimento Médico (APS) podem ser necessários. Se uma Declaração Médica (APS) ou outra forma for exigida, o cliente é solicitado a imprimir o documento ou pedir que seja enviado toda a documentação impressa (via web) ou enviado pelo correio é de código de barras, para amarrar o registro pedido adequado.

Toda a documentação em anexo (apenas na web) é enviado para a fila apropriada examinador examinador de trabalho para revisão e julgamento. O requerente é informado que a documentação foi enviada para análise e que uma notificação será enviada (via email ou correio postal), dentro de 5 a 10 dias úteis (o número de dias em que é exibido depende da configuração do cliente). Neste ponto, o reclamante se lembra de o método de comunicação selecionada e é a oportunidade de atualizar ou alterar as informações prestadas. Nesta fase, a requerente também é lembrado para continuar a fazer os pagamentos até que a requisição/ ativação foi aprovado (ou qualquer outro requisito script baseado na instalação do cliente) . Se a documentação não estiver conectado, o requerente receberá email/notificação de email da documentação pendente periodicamente, com base no produto, cliente, estado, etc entradas da tabela que a correspondência da unidade.

Note que em alguns casos, a verificação verbais prestadas pelo requerente pode atuar como uma fonte de dados comprobatórios suficientes para efeitos de validação do evento indenizatório requerido. Isso na maioria das vezes vai ocorrer no caso de uma reivindicação muito baixo risco, o risco relativo de um crédito fraudulento ou errôneo ou recitação de facto prestadas pelo requerente simplesmente não justificam os custos ea inconveniência dos clientes associados com a pesquisa mais aprofundada, nomeadamente no âmbito da ALV processo e sistema da presente invenção.

A descrição anterior do sistema de ALV da presente invenção tem-se centrado em cima de um processo de duas etapas: (1) Utilização do rato para atribuir uma pontuação de avaliação de risco para o prejuízo invocado e seleção de um valor TCL que devem ser atingidos para verificar a validade do prejuízo invocado, e (2) seleção iterativa de uma ou mais fontes de dados comprobatórios que contribuam predeterminado escores de confiança para a realização dos TCL valor como eles são atingidos pelo sistema para verificar com sucesso a perda reivindicada. Em uma modalidade preferida da presente invenção, um modelo de sistema de um passo ALV é produzida a partir de análises. Nesta modalidade, todos os dados que caracterizam a requerente, requerida evento de perda, e os dados disponíveis de fontes concordantes são combinados para produzir um modelo por meio de técnicas estatísticas que fornece uma pontuação única e global que representa o nível de confiança associado com a aprovação da requisição com a fonte de validação eleito (s). Este sistema funciona para encontrar a combinação de crédito e fonte de dados comprobatórios (s) que fornecem o limite mínimo estabelecido no sistema. 0 custo associado com a fonte de dados deve ser considerada dentro do modelo, a fim de otimizar os custos de funcionamento do processo de ALV.

Após a perda do cliente ou automático de informações fornecidas processo de verificação, uma decisão é proferida com base na verificação recebidos e as regras estabelecidas por produto, cliente do Estado, na fase de julgamento 100 (e exceções do estado), e etc, ou qualquer combinação destas. É nesta fase que a duração do julgamento benefício (se aplicável) e valor do pagamento é determinada e divulgada ao requerente.

Para as prestações continuadas, a beneficiar casas automatizadas duração modelo regras que determinam a duração de apro va para as reivindicações benefício uma vez a aprovação do crédito foi concedido. Uma série de fatores é abordada por essas regras, incluindo o diagnóstico médico, tipo de emprego, eo estado de residência (por exemplo, os eventos conhecidos desemprego, catástrofes naturais). Dessa forma, requerida duração os benefícios podem estar ligados a condição do requerente perda específica, em vez dos mais generalizada, one-size-fitstodas as regras. Se o pedido de ativação/for aprovado, o requerente considera que todas as informações relativas à homologação. Por exemplo, um montante de pagamento ou adiamento ou se o montante não estiver disponível, mensal ou uma substituição simples de sua propriedade foi aprovado declaração. Os detalhes que aparecem são movidos por entradas da tabela no motor de regras. Dependendo do cliente / instalação do produto, modelo automatizado do sistema determina:

• Onde / como obter as informações necessárias (recuperação de dados automatizados contra declaração de faturamento da requisição) • O método de cálculo apropriado de pagamento • Os juros aplicáveis devido • Quaisquer benefícios adicionais (ie, benefícios adicionais morte acidental baseado apólice de seguro de vida) • Se o tipo de requisição tem um modelo de duração associados dados fatura é automaticamente recuperado para tomar uma decisão montante do pagamento, com base na configuração do cliente. Vários métodos estão disponíveis:

A conectividade com o dados do cliente; feeds de dados do cliente para o centro das reivindicações, utilizando processo de loop, etc O sistema também pode buscar os dados de faturamento declaração da instituição financeira sobre a demanda. Se as informações de declaração de faturamento não está disponível automaticamente, há um processo semi-automático e um menos preferido processo manual, para determinar a relação benefício/valor do pagamento. O usuário é aconselhado a contar da notificação futuro, eo processo semi-automático ou manual começa.

As companhias de seguros e instituições financeiras log em uma ferramenta web que mostra sinistros/ativações onde a informação fatura é necessário determinar uma relação benefício/valor do pagamento. A companhia de seguros ou instituição financeira insere as informações necessárias e transmite os dados necessários para o centro de comunicações reclamante 12, onde o sistema determina automaticamente o benefício o valor do pagamento e notifica o requerente.

O requerente (web) pode optar por anexar uma cópia da fatura. Se o requerente é a apresentação de uma requisição/ativação através do IVR, eles são avisados de que podem e-mail ou enviar e-mail a documentação exigida através da web.

Menos de preferência, o operador do sistema irá procurar fatura anexa diretamente da requerente. Os anexos de declaração de faturamento são enviados para a fila apropriada examinador de trabalho para determinação dos benefícios e/ou valor do pagamento. Notificação de pagamento/valor do benefício será enviado (via e-mail ou correio postal), de preferência no prazo de dois dias úteis, ou o número de dias definido pela configuração do cliente dentro do sistema de ALV.

Quando o cliente fornecido pelo processo de verificação de perda é necessário, os examinadores usar um passo-a-passo processo de revisão do documento. O sistema especifica os requisitos de documentação aceitáveis para cada produto de seguro em termos de seu cliente, a estrutura de benefícios, etc Como o examinador analisa a documentação relativa ao sistema pede que o examinador ou anda com o processo.

Por exemplo, em uma morte acidental reivindicação, um Certificado de Óbito (CDC) é necessária. 0 sistema irá solicitar que o examinador da seguinte forma:

• Você tem um CDC?

• A causa da morte acidental?

• Qual foi a data da perda?

• Foi para o titular do cartão principal?

Como o examinador entra / seleciona a resposta, o processo decisório é concluído.

Toda decisão é ligada à verbosidade que é comunicada ao requerente através do método de comunicação requerente selecionados - web, e-mail, URA, carta, afirma script associado. Os pedidos de documentação adicional lista toda a documentação exigida; recusas listar todos os motivos para a recusa, e aprovações de fornecer detalhes específicos quanto à data de pagamento, método e que o espera. Este módulo de habitação todo o palavreado é de tabela dirigida e mantida pelo usuário. Ele permite que as companhias de seguros e instituições financeiras para criar palavreado por produto/requerente/benefício/estado, etc examinadores podem ver e aprovar ou rever palavreado antes da liberação ao requerente (se o processo é conduzido por Aiz) . Nesta fase, se o pagamento é devido, o requerente, então, seleciona o método de pagamento (Cheque, ACH, etc) . Formas de pagamento serão armazenados em tabelas e apresentados com base em cliente/instalação do produto. Quando o usuário seleciona o método de pagamento, o sistema informará quanto à data de entrega prevista de pagamento, com base no método de instalação selecionado e cliente/produto. Uma vez que o pagamento é feito a seleção, o requerente é solicitado a salvar as informações (Aiz/ user web) ou print (web) . O requerente é lembrado de seu pedido ou número de ativação e é fornecido com um 800 # endereço da Web (ou para usuários de Internet) . Neste ponto, a sessão termina.

Se o pedido de ativação/negado, o motivo da negação é exibido, com base em produto, cliente, estado de regras, etc. Uma vez negado, o reclamante tem a opção de visualizar os termos e condições ou ter uma cópia enviada/enviada para o seu endereço de escolha. Um número verde gratuito créditos também podem ser fornecidos nesta fase (web).

Record de negação é mantida, bem como registro de notificação requerente - o interessado pode optar por receber a comunicação escrita ou não. Neste ponto, a sessão termina. Todos os scripts de decisão são mesa-driven. Que o reclamante vê ou ouve é dependente do cliente/produto/ configuração do Estado.

Portanto, de acordo com o sistema automatizado de reivindicação de processamento 10 da presente invenção, os créditos podem ser revistos de forma rápida e eficiente sem sobrecarregar na maioria dos casos o reclamante com a necessidade de preencher formulários detalhados reclamações e obter e fornecer documentação comprovando a provar o evento coberto. Ao obter a documentação probatória de tal disposição de terceiros ou fontes proprietárias, a empresa de seguros ou instituição financeira pode julgar o pedido de acordo com sua aceita nível de risco, enquanto redução de custos administrativos e reduzindo o período de exame e julgamento de um mês ou mais para um período de tempo curto. Para efeitos da presente invenção, curta duração, dois dias, de preferência, duas horas, ainda mais, de preferência dentro do tempo real, enquanto o requerente está no telefone com a companhia de seguros ou instituição financeira representante de atendimento ao cliente, ou conectado ao site ou IVR sistema de ativação do portal benefícios. Além disso, o requerente inevitavelmente apreciar os pedidos de processamento do sistema simplificado de atendimento exemplar.

A arquitetura do processo de ALV 38 parcela de créditos de processamento do sistema 10 é representado nas figuras 10/08. Uma vez que um produto benéfico cobertura contrato de crédito através da sua fase de Origem 50, Direito Fase 60, Set-Up Phase 70, eo risco Fase de avaliação 80, chega a 230 o ponto de partida do sistema de ALV 38. Na etapa 1, o sistema verifica o status 232 da bandeira do cliente ALV. Um banco de dados de 234 lojas uma lista de todas as diferentes companhias de seguros e clientes de instituições financeiras atendidos pelo sistema de processamento de pedido 10 e 38 sistema de verificação automática dos sistemas presentes no caso em que a empresa opera um sistema de manutenção das reivindicações de vários clientes. Se a opção do cliente tem sido definida como a posição on, em seguida, o sistema procede à configuração ALV ALV 234 etapas da Etapa 2. Se o sinalizador ALV não foi definido, em seguida, o sistema atualiza o banco de dados de log de auditoria 238 a refletir esse fato, e, em seguida, procede a uma verificação de perda de clientes, desde o pedido de benefício da cobertura do contrato. Banco de dados armazena os dados de 240 para a configuração específica de cada cliente do sistema de ALV 38 . Esses dados devem incluir ou não o sistema de ALV deve ser usado para verificar um sinistro requerido, os parâmetros para que as reivindicações sejam abrangidos pelo sistema de ALV, com que freqüência a testar o sistema de ALV, as regras ou modelos de algoritmo subjacente ao sistema de ALV, o escores de avaliação de riscos para os créditos, os valores necessários para TCL créditos e os aceitável fontes de dados independentes para corroborar eventos prejuízo invocado, e os níveis relativos confidencial concedido a cada fonte de tais dados. Se a configuração não for encontrada, então o log de auditoria 244 é atualizado pelo sistema para refletir esse fato, o sistema procede à verificação da perda de clientes, desde do crédito. A ALV passo processo de seleção 242 do passo 3 é contratado por banco de dados 246, que armazena os dados necessários para cada cliente, ou um produto especifico desse cliente. Basicamente, o cliente pode personalizar personalizado de um conjunto de regras que determinam para cada tipo de seu seguro ou contratos de proteção da divida ou o tipo de beneficiários se quer permitir que o sistema ALV 38 para verificar automaticamente o pedido como parte do processo de validação de crédito em vez de mais trabalho e processo de verificação de tempo intensivo desde a perda de clientes. Um tipo particular de produto, reclamações ou beneficiário pode apresentar um grau excessivo de risco para o cliente para delegar pedido de verificação do processo de ALV. Se as regras armazenadas no banco de dados de 246 indicam que o processo de ALV não deve ser usado, então o log de auditoria 248 é atualizado para refletir esse fato, o sistema procederá à verificação da perda de clientes, desde do crédito.

Se as regras indicam que o processo de ALV deve ser usado para avaliar e verificar o pedido, o sistema procede para determinar o tipo de configuração é de um tipo de modelo (250) para os quais um valor RAS já foi calculado e armazenado no sistema. Se o tipo de configuração é de um tal tipo de modelo, em seguida, o sistema procede à determinação de avaliação de risco de 252 a etapa 4. Os escores de avaliação de risco (RAS) para o contrato de cobertura, tais benefícios são armazenadas no banco de dados 254. No processo passo 4, o sistema (252) pesquisas de banco de dados 254 para RAS como um sinistro, bem como um indicador de amostra aguentar. Se, por outro lado, o tipo de configuração é a regra-driven, em seguida, o sistema irá executar as 256 regras armazenadas no banco de dados de 258 para calcular em tempo real o RAS para essa reivindicação. Note que este cálculo RAS é adaptada ao perfil de risco específico de aceitação da seguradora ou instituição financeira do cliente e, portanto, podem variar amplamente entre os clientes para o mesmo tipo de requisição. Se as regras necessárias para o cálculo da RAS para a reivindicação estiverem disponíveis, então o sistema procede ao nó 258. Se essas regras não estão disponíveis, a RAS não pode ser calculada para o sistema a operar o processo de ALV para verificar a requisição. Em vez disso, log de auditoria 260 será atualizado para refletir essa RAS desconhecido para o crédito, eo sistema vai proceder à verificação da perda de clientes, desde do crédito.

Se uma determinada RAS foi encontrado no banco de dados 254 para o pedido, o sistema determina se estão presentes as regras de negócio que modificam o RAS. Tal modificação do padrão RAS do cliente podería acomodar situações especiais, como áreas de desastre em verificações código postal poderá ser desnecessário. Esta etapa do processo utiliza as regras e os dados armazenados no banco de dados 264. Utilizando o aprendizado a partir da análise da amostra aguentar descrito abaixo, os modelos podem aprender a partir de reivindicações de uma experiência prévia para ajustar o RAS predeterminado para o crédito quando necessário para causar-lhe caracterizar com precisão, tanto quanto possível o risco real que a requisição de poses de fraude ou erro. O sistema, em seguida, prossegue com a RAS, conforme alterada, para o nó 258 do processo de ALV.

Tendo encontrado, modificados ou calculado o RAS para a reivindicação no nó 258, o sistema procede a etapa 6 na qual um TCL associada RAS que é recuperado a 266. Tais TCLS serão armazenadas em banco de dados de 268, normalmente através de uma mesa de pesquisa. Como explicado anteriormente, este TCL, ou nível de confiança total, a pontuação determina o limiar de tolerância específica que deve ser preenchida pelo jogo de sucesso do documentário corroborando verbal ou fontes de dados independentes, no total, para verificar o crédito através do processo de ALV. Os valores mais elevados RAS vai exigir maior pontuação TCL para refletir o maior grau de risco de crédito da companhia de seguros ou instituição financeira por fraude ou erro, créditos Menor risco, pelo contrário, vai exigir uma menor pontuação TCL, permitindo assim a pretensão de ser verificado através do processo de ALV, com menos de fonte de dados corroboradora encontrados. Se um TCL não é encontrado pelo sistema de crédito, então o log de auditoria 270 é atualizado para refletir esse fato, o sistema vai proceder à verificação da perda de clientes, desde do crédito.

Se a pontuação TCL foi encontrado pelo sistema de crédito no Passo 6, o sistema aplica as regras armazenadas no banco de dados de 272 a modificar (274) a pontuação TCL, se necessário. Mais uma vez, este aspecto do processo de ALV permite a pontuação TCL a ser modificada com base em alegações experiência passada para causá-lo para caracterizar o mais fielmente possível os riscos decorrentes de uma verdadeira relação ao pedido de fraude ou erro. Assim, o sistema de ALV 38 da presente invenção permite o pré-cálculo e armazenamento do RAS e pontuações TCL por um grande número de políticas da companhia de seguros de seguros ou contratos de instituições financeiras de proteção de divida para acelerar o processamento de pedido automático de uma requisição nos termos de tal seguro ou contrato de divida de proteção, confiando no fato de que o sistema pode utilizar as regras armazenadas para modificar a RAS e os escores TCL em tempo real, os juros de precisão.

Na etapa 8 do processo de ALV, o sistema inicia o processo de verificação automática a perda de 276. Este processo aplica-se os dados armazenados no banco de dados 278, incluindo as diversas fonte de dados corroboradoras, a atribuição especifica de determinadas fontes de dados corroboradoras para verificação do crédito, os escores de confiança pré-atribuido nivel para cada fonte de dados corroboradora, elementos de olhar para cima os dados necessários, e as regras para a realização das comparações fonte de dados corroboradora em relação às informações apresentadas pelo requerente para o pedido, bem como as informações armazenadas no registro e registros de requisição anterior. Se o crédito é uma reivindicação continua (por exemplo, a benefícios por incapacidade verificado anteriormente pedido quando o requerente apresentou um pedido de prestações para o período de tempo também sob a sua política), então o sistema irá excluir fontes de dados corroboradoras que anteriormente eram utilizados para verificar a requisição e não são dados múltiplas fontes de sucessos.

Na etapa 9, o sistema calcula ALV 38 (280) o RVV para a afirmação de que, como descrito acima representa o AVV para a afirmação de seu valor subtraído do TCL set. Note que esta pontuação RVV será inicialmente definido como igual ao valor TCL o pedido antes da primeira iteração do corroborando os dados de origem que correspondem à recuperação e à requisição de informações set-up.

O sistema de 38 produtos próximos para a etapa 10 na qual o valor MVV para o crédito é calculado 282. Esta etapa do processo utiliza as informações armazenadas no banco de dados 284 para fonte de dados corroboradoras particulares pré-designado para a verificação do que reclamar. Como descrito acima, os níveis de confiança para todas estas fonte de dados corroboradoras são combinados para produzir o MVV verificação ou valor máximo. Se a pontuação necessária TCL para verificação do crédito for superior a este valor MVV, então este fato é refletido no 286 autolog atualizado e as receitas do sistema com a verificação do sinistro fornecida pelo cliente do crédito. Porque mesmo igualar o sucesso de todos os pré-determinadas fontes de dados corroboradoras com as informações contidas no pedido não pôde produzir o suficiente valor agregado a confiança de satisfazer o requisito TCL, então não há nenhum ponto em prosseguir com a aplicação do sistema de ALV 38 da pedido, na ausência de outras fontes de dados corroboradoras disponíveis para a verificação do que reclamar. Se o valor combinado para o MVV fonte de dados corroboradoras disponíveis para verificação do crédito é determinada na etapa 11 para ultrapassar a pontuação necessária TCL para a verificação do que reclamar, então o sistema de 38 receitas para a etapa 12 em que o sistema calculou que o valor PVV (288) de todas as fontes de dados para corroborar a requisição de que ainda não foram recuperados para a verificação do crédito e estão disponíveis para verificar a perda reclamado durante a iteração. Note-se que com cada recuperação de uma fonte de dados corroboradora, o valor combinado PVV para as fontes de dados corroboradoras prédesignado restantes para essa reivindicação será necessariamente diminuir.

Banco de dados 290 contém os pré-atribuído fonte de dados corroboradoras, os níveis de confiança para as fonte de dados corroboradoras e as regras para o cálculo deste PVV. Banco de dados 290 também mantém controle de quaisquer fontes de dados confirmando que já foram recuperados e aplicados com o crédito de modo que eles são omitidos do cálculo do PVV para o passe atual.

Também na etapa 12, o sistema calcula o valor de verificação execução possível (RPW tally) para o processo ALVS onde:

RPW PVV = + RPW.

Este registro RPW mantém a confiança de todos os valores de ponto corroborando os dados de fontes de verificação iterações anteriores (RPW), combinada com os valores de ponto de confiança das fontes de dados corroboradoras para a iteração atual de verificação (PW).

Na etapa 13, o sistema determina se PVV 38> 0. A única vez que o valor não ultrapasse PVV 0 é se todos os pré-determinadas fontes de dados corroboradoras foram obtidos e aplicados pelo sistema de verificação de crédito, ou se as fontes de dados não estão disponíveis. Nesse caso, a verificação da requisição usando o atualmente disponível fontes de dados corroboradoras para satisfazer o valor exigido TCL é impossível, então o sistema aborta nova aplicação do processo de ALV, e prossegue até o nó 292. Se, por outro lado, PVV> 0, então o sistema de 38 receitas para a etapa 14 para determinar qual fonte de dados corroboradora a recuperar (294) do banco de dados 290, com base em uma série de fatores. Em primeiro lugar, as regras armazenadas no banco de dados 290 define uma lógica de base para a seleção das especificas fonte de dados corroboradora deve ter sido pré-designado para o subconjunto de corroborar as fontes de dados para verificar se o pedido.

Em segundo lugar, cada fonte de dados tem um custo associado a ele. Alguns fornecedores de corroborar as fontes de dados podem cobrar por cada vez que o sistema de utilização dos pedidos de sua fonte de dados. Em alguns casos, essas taxas podem ser significativas. Em outros casos, a companhia de seguros ou instituição financeira

pode ter criado	uma fonte	de dados	proprietárias,	e ele vai
dar prioridade	ao uso dessa fonte	de dados para	verificar
uma requisição,	a fim de	recuperar	seus dados os	custos de
desenvolvimento	de código	e evitar	incrementai de	terceiros
fonte de dados Terceiro,	encargos. nem todas	as fontes de dados pode	fornecer

a mesma taxa de sucesso para combinar informações afirmam contribuinte para verificação do que reclamar. Deve ser dada prioridade aos dados fontes de ter uma maior taxa de sucesso a menos que o custo de acesso a essa fonte de dados particular exceder o seu valor, tendo em conta a sua taxa de acerto.

Em quarto lugar, o valor RVV (ie, AVV - TCL) que precisa ser preenchida para verificar a requisição pode ser obtida através da recuperação e aplicação de uma ou um par de fontes de dados disponíveis. Faz mais sentido utilizar as fontes poucos dados para alcançar o resultado desejado, em vez de verificação de um número maior de fontes de dados individualmente mais barato. Portanto, as regras para seleção de fonte de dados 294 são flexivelmente reativa ao estado atual do processo de ALV da presente invenção. Na etapa 15 do processo de ALV, a fonte de dados em particular é obtido e aplicado 296 contra as informações prestadas no pedido. Regras da fonte de dados e elementos de dados armazenados dentro do banco de dados regra 298 facilitar o funcionamento deste processo. As fontes de dados são provenientes de duas fontes de dados internas e 300 externas, de terceiros fontes de dados fornecidos pelo 302. Se as regras de verificação da fonte de dados pertinentes não corresponde às informações de crédito, então ela não contribui com pontos para o nível de confiança de pontuação AVV para a reivindicação. Se, por outro lado, a fonte de dados não correspondem com sucesso as informações reivindicação, então, corroborou a afirmação, e os seus pontos de nível pré-atribuído confiança são adicionados ao registro AVV 304 para execução do crédito na etapa 16.

Na etapa 17, a pontuação RVV para a requisição é recalculado 306 subtraindo-se o registro atualizado AVV do valor exigido TCL para verificar a requisição. Neste ponto, a atualização do AVV e pontuações RVV, juntamente com a identificação da fonte de dados corroboradora com sucesso comparado com o crédito, são adicionados ao log de auditoria 308, com as informações armazenadas no banco de dados 310.

Em seguida, o processo de ALV receitas para a etapa 19 em que a atualização da pontuação AVV é comparado (312) contra a pontuação necessária para a afirmação de TCL. IfAVV> TCL, TCL, em seguida, o limiar exigido tenha sido satisfeita pelo processo de ALV, e essa informação é gravada no log de auditoria 314. A requisição verificado será então enviada pelo sistema ALV para a fase de julgamento 100 (ver figura 3.).

Se, no entanto, AVV <TCL para o pedido, em seguida, o pedido ainda não foi verificada.

Na etapa 20, o sistema determina (316) se fontes adicionais corroborando os dados estão disponíveis para a recuperação e aplicação ao crédito, em conformidade com as regras e base 127% 49vl 40 lógica de 294 passo 14. Se não houver mais fontes de dados corroboradoras estiverem disponíveis, então o processo de ALV e de execução sistema procede ao nó 292.

Voltando à figura. 10, um pedido para que não mais fontes de dados comprobatórios 300, 302 produtos estão disponíveis para a etapa 21. Nesta etapa do processo ALV, o sistema determina se 320 RVV> MVV - RPVV. Se sim, então o sistema atualiza autolog 322 a refletir o fato de que a pontuação exigida TCL não pode ser alcançado. O sistema então retorna para o portal com a requisição de não verificadas.

Se, no entanto, RVV = MVV - RPVV, em seguida, o sistema procede a etapa 22 para determinar que 324 fontes de dados comprobatórios para bater com base na lógica de base armazenados em banco de dados de 325 ou de prioridade. Esses outros elementos comprobatórios dos dados deve ser solicitada 328 da requerente nos termos do passo 23. A frase para o pedido é fornecido pelo banco de dados de 330, e 332 autólogos é atualizado. 0 sistema retorna para o portal para solicitar 334 esta informação adicional do cliente, porque a pontuação necessária TCL é alcançável se uma ou mais fontes concordantes dados são disponibilizados nos termos do requerente respostas às questões colocadas. Qualquer bit como novos dados obtidos a partir do cliente 338 é utilizado pelo sistema em uma passagem secundária 340 (ver figura 9.) Para iniciar novamente o processo de consulta recursive para verificar o pedido a partir de PVV etapa de cálculo de 288 passo (12).

Exemplo 4 Um exemplo do processo de ALVS representado nas figuras 80-10 é fornecido como segue:

• Obrigatório TCL para verificação crédito: 70%

MVV%

4 • Os dados comprobatórios fontes: banco de dados o SSN = 20% o banco de dados Data de Morte = 30% o banco de dados de publicação Obituary = confirmação o 30% Verbal = 10% .

• A iteração: Somente o SSN e Data de fontes de dados Death estão disponíveis. RVV o TCL = = 90% (Passo 9).

MW o = 90% (Passo 10) . Porque o TCL <MVV, em seguida, proceder (Passo 11) . PVV ο = 20% + 30% = 50% (Passo 12). PVV RPVV + o = RPVV (Passo 12). RPVV = 0% + 50% RPVV = 50%, o PVV> 0, para avançar (Passo 13) . o Sistema de sucessos obtém positivo para ambos os SNN e Data de fontes de dados Morte (Etapas 14-15).

AVV o = 20% + 30% = 50% (Passo 16).

RVV o = TCL - AVV (Passo 17)

RVV = 70% - 50% = 20%. o AVV <TCL, para prosseguir com a segunda iteração (etapa 19). o Existe uma nova fonte de dados disponível obituário (Passo 20).

É o MVV RVV> - RPVV? (Passo 21)

20% <90% - 50% 20% <40%, assim proceder.

• Iteração 2: Base de dados Obituary o valor de 30 pontos de confiança o PVV = 30% (Passo 12) . o RPVV = RPVV + PVV (Passo 12) RPVV = 50% + 30% = 80% RPVV o PVV = 30%> 0, para avançar (Passo 13). o sistema não consegue um jogo de sucesso (Etapas 14-15). AVV o = 50% ainda (Passo 16). RVV o = TCL - AVV (Passo 17) RVV = 70% - RVV 50% = 20%. o AVV <TCL, então vá para a terceira iteração (etapa 19).

• Iteração 3R:

o Existe uma nova fonte de dados disponível verbal (Passo 20). É o MVV RVV> - RPVV? (Passo 21). 20%> 90% - 80% 20% <10%, para processo ALVS final, porque os 10 pontos de fonte de dados verbal é insuficiente para satisfazer a lacuna restante TCL.

discrepâncias. Desta forma, o RAT e parâmetros de processo ALV pode ser modificado quando necessário, para melhorar a precisão do indicador da RAT e de ALV. Outro aspecto crucial da presente invenção é o console de gerenciamento do sistema de ALV 38. Composto por um programa de software e interfaces gráficas associadas (GUIs), este console de gerenciamento permite a companhia de seguros, instituições financeiras, ou operador de outro sistema para estabelecer e manter os diferentes parâmetros para o funcionamento do processo de ALV 38.

A Figura 13 mostra a tela de login 450 para o sistema de ALV 38. Ele contém um campo User ID 452 no qual o usuário digita seu nome de identificação atribuído para o servidor em que a ALV Management Console reside. O usuário também deve digitar uma senha pré-determinada no campo 354 para fins de segurança. Depois de clicar no log in ícone 456, o sistema irá verificar sua lista de IDs de usuário e respectivas senhas de acesso do usuário à ALV Management

Console somente se houver uma correspondência exacta. Se o usuário esquece sua senha, ela pode clicar em Esquecí a senha hyperlink 458, caso em que o administrador do sistema irá enviar e-mail uma senha de sua substituta, como é conhecido nas artes computador.

A home page 460 para a Gestão ALV Console da presente invenção é mostrada na figura. 14. Localizado na home page GUI é uma série de ícones: RAS/Fontes TCL 462, Data 464, 466 elementos de dados, configuração do cliente 468, 470 Busca, teste 472, 474 e relatórios. As funcionalidades desses ícones será descrito a seguir.

Ao clicar sobre o ícone RAS TCL / 462, 480 GUI é chamada por diante, como mostrado na figura. 15, que permite que o operador de sistemas para inserir ou excluir os valores para os escores de avaliação de risco (RAS) eo nível de confiança total (TCL) os valores de uma companhia de seguro particular ou uma instituição financeira. RAS valores são números sem pontos decimais. A números podem situar-se entre -999 e 999. TCL valores são números sem pontos decimais maiores ou iguais a zero e inferior a 999. Assim, RAS e TCL valores são armazenados em um ou mais bancos de dados do sistema.

Os valores atuais RAS são representados nos campos 482. Ao clicar em um botão de rádio 484, o valor correspondente RAS pode ser editado clicando sobre o

Insert hyperlink 486.

Os valores atuais TCL são retratados nos campos 487. Ao clicar em um botão de rádio 488, no valor correspondente TCL pode ser editado por clicando sobre o Inserir hiperlink 489.

As fontes de dados GUI 490 mostrado na figura. 16 é acessada clicando em fontes de dados ícone 464. Essa tela permite que o operador de sistemas para configurar as fonte de dados corroboradoras para o sistema de ALV 38 usos para verificação reivindicações. Definições nesta sessão se aplica às fonte de dados corroboradoras. Campo 4 92 permite que a fonte de dados deve ser identificado com o nome formal entrou em campo 494. A base de custos para a fonte de dados (por exemplo, livre, taxas fixas, por batida) está inscrita no campo 496. O custo real de uso para a fonte de dados está inscrita no campo 498. O campo de vários sucessos 500 shows por um sim ou sem entrada se a fonte de dados pode ser invocada várias vezes para fins de verificação da ocorrência do sinistro. Por exemplo, o banco de dados histórico receita mostrada na figura. 16 como sendo verificado sim é um banco de dados data-driven, informações de verificação para que ele possa fornecer atualizadas várias vezes durante o processo de verificação de créditos. Em contrapartida, o banco de dados médico especialista fornece um único ponto de dados de todos os tempos no que diz respeito ao crédito. Portanto, o sistema só deve consultar esse banco de dados médico especialista uma vez durante o processo de verificação de créditos.

A taxa de sucesso para cada fonte de dados corroboradora é calculado sobre o número total de sucessos válidos dividido pelo número total de acessos. Este valor pode ser expresso como uma percentagem e caracteriza a utilidade da fonte de dados para verificar uma requisição, e está inscrita no campo 502. 0 valor da taxa de sucesso podem ser inseridos manualmente pelo operador do sistema. Alternativamente, pode ser calculado automaticamente pelo sistema se o botão calcular 504 está marcada. 0 escritório de campo 506 e região campo 508 indicam a aplicabilidade geográfica de uma determinada fonte de dados corroboradora a requisição de verificar as informações. Office refere-se ao país do cliente de operação. Região se refere a um estado ou província no país. A data efectiva da entrada de dados fonte de dados ou revisão é identificado pelo sistema no campo 509.

Clicando no símbolo do globo 510 abre uma janela popup 512, que permite a seleção da região (todos contra regiões selecionadas). Ao clicar em elementos de dados ícone 466, o sistema computador ALVS 38 evoca o mostrado GUI 520 figura 17.

Este tela permite que os elementos de dados para cada fonte de dados corroboradora a ser digitada pelo operador de sistemas. Definições nesta tela aplicável a todas as configurações do cliente.

Os elementos corroborando pode ser filtrado pela fonte de campo caixa suspensa 522 ou mais no campo de pesquisa drop down box 524. Essa tela permite que o nome do elemento de dados a ser modificado no campo 526, e de estabelecer ou não o elemento de dados é um campo de busca no campo 528. O nome dado não pode ter mais de 50 caracteres. O campo de pesquisa o elemento determinante de dados está sendo usado ou não através de um conjunto de regras para verificação de dados, e se o requerente tem de fornecer as informações para o elemento. O aplicativo usa este campo para determinar perguntas adicionais. Autorizações e consentimentos são considerados elementos de dados. Assim, se uma fonte de dados exige uma autorização antes de ser batida, então essa autorização será definido como um elemento de dados.

Campo 530 define o elemento particular que pode ser pesquisado para cada fonte de dados. Para a Segurança Social Death Index 532, este pode ser o falecido nome ou sobrenome. Para a base de dados obituário, que podería ser o do falecido data da morte de 534. A data efetiva da entrada da fonte de dados é identificada pelo sistema no campo 536.

A figura 18 ilustra ALV configuração do cliente GUI 540, que pode ser acessado clicando sobre o ícone 468. Este cliente ALV reúne todas as configurações de configuração que caem sob o mesmo cargo (por exemplo, Estados Unidos, Canadá, Porto Rico), linha de negócio (por exemplo, seguros, protecção de dívida), o pacote do produto, cliente e componente. O sistema de ALV 38 usa essa configuração para determinar que corroborem as fontes de dados e regras para empregar para verificar a reivindicar o benefício. A tela exibe o GUI 540 existentes ALV configurações do sistema do cliente. Ele também permite configurações de cliente novo a ser criado, clicando em Clique aqui para adicionar uma nova configuração hyperlink 542. As configurações existentes do cliente também pode ser editado. entradas de configuração do cliente pode ser facilmente pesquisados. Por exemplo, para obter uma lista de todas as configurações de ALV para o cargo Estados Unidos da companhia de seguros ou instituição financeira, United States deve ser inserido dentro do Office campo 544 e no botão buscar 546 clicado. Para obter todas as configurações para um cliente, Cliente A deve ser inserido no campo Cliente 548, seguido pela ativação do botão de pesquisa 546. Outros campos de busca para incluir configurações de cliente Configuração ID campo 550, Produto Bundle campo 552, Linha de Negócio campo 544, e campo Component 556. Todas as informações de campo relevante para uma configuração de cliente particular é mostrada na caixa de resumo 558. 0 botão reset 559 permite que uma nova pesquisa será realizada.

A Figura 19 mostra GUI 560 para criar uma configuração de cliente novo. Ele é acessado clicando no link 542 em GUI 540. O sistema de ALV 38 irá atribuir um Configuração ID no campo 562, o que pode constituir números, letras ou uma combinação dos dois. Drop-down caixas de fornecer um meio conveniente para o operador de sistemas para fornecer informações pertinentes para a identificação de escritório (564), cliente (568), o pacote do produto (570) , e componente (572) . O status da configuração (ou seja, on, off, ensaio) pode também ser inserida em caixa suspensa 574. O tipo de contrato de cobertura de benefícios (por exemplo, seguros, protecção de dívida) é inserido na caixa suspensa 576. Por fim, comenta sobre a configuração do cliente pode ser facilmente introduzido pelo operador de sistemas no campo 578. Clicando no botão Next 580 traz o operador de sistemas de GUI 590 representada na figura. 20 para selecionar o conjunto de regras a partir do motor de 108 regras que devem ser aplicadas para a configuração do cliente. Estes são o processo de avaliação de risco (RAP), regras que são aplicadas pelo sistema de ALV para modificar o resultado de avaliação de risco pré-atribuído (RAS) para a apólice de seguro ou produto de proteção de dívida a entrada particular configuração do cliente. Essa tela permite que os bits regra RAP a ser inseridos, atualizados e excluídos. Os bits regra RAP são inseridos em campos, ao clicar em um botão de rádio na coluna de entrada 595 594 permite uma entrada de regra existente RAP a ser editado. Botão Next 596 permite que o operador de sistemas para proceder a GUI 600 mostrado na figura. 21. Botão Anterior 598 560 a GUI permite ser revisitado. GUI 600 proporciona a tabela tradutor usado pelo sistema para converter ALV 38

RAS para um	nível de confiança	alvo ALV (TCL) .	Os	valores
disponíveis	RAS são inseridos	em campos RAS	602	com o
auxílio de	caixa drop-down 604.	Em seguida, a	TCL	valores
escolhidos	pela companhia de	seguros ou	instituição

financeira para uma pontuação RAS particular são inseridos no campo 606 com o auxílio de caixa suspensa 608. O conjunto de regras selecionadas para o cálculo da pontuação RAS para a apólice de seguro ou contrato de dívida de protecção no caso de uma pontuação RAS não foi préatribuído é entrou em campo 610 com a ajuda de uma caixa suspensa. Finalmente, o conjunto de regras para modificar o valor resultante da TCL tabela de conversão de 614 é inserido na caixa suspensa 612. Botão Avançar faz com que o sistema avance para GUI 620 mostrado na figura. 22.

GUI 620 permite a entrada de corroborar as fontes de dados e seus valores respectivos intervalos de confiança. Estas fontes de dados são usados pelo sistema de ALV 38 para verificar um sinistro, conforme descrito acima. As fontes de dados podem ser inseridos, apagados ou atualizados através desta tela. A identificação da fonte de dados está inscrita no campo 622 com o auxilio de uma caixa suspensa. A caixa suspensa mostra apenas as fontes relevantes disponíveis corroborando os dados para esse tipo de apólice de seguro ou contratos de proteção de dívida. Por exemplo, apenas as fontes de dados relacionados com a vida (por exemplo, Social Security Death Index, base de dados Obituary) será mostrado para um seguro de vida. O sistema também leva em conta o cargo definido para a fonte de dados. A prioridade campo 624 é um número de 0-99, e não é necessário para a criação de uma entrada de fonte de dados. Status campo 626 é uma caixa suspensa que oferece as opções: ligar, desligar, e teste.

O valor de confiança campo 628 é o repositório para o nível de confiança relativo atribuído por uma companhia de seguros ou instituição financeira para cada fonte de dados. Isso será tipicamente uma porcentagem entre 0 e 100. Cada fonte de dados corroboradora terá um custo de acesso a ela associados. Este número custo está inscrita no campo 628, juntamente com o tipo de custo (por exemplo, taxa fixa, por golpe, livre) inserido no campo 630. Hit Rate 632 é uma caixa suspensa com três opções: padrão, calculado e atribuído. Padrão significa que a taxa de acerto que foi digitado na tela de fontes de dados devem ser usados. Calculado significa que o sistema deverá calcular automaticamente o valor de acordo com a fórmula: Hit Rate = Número total de sucessos válidos para esta configuração

Número total de sucessos para esta configuração Assigned significa que o operador do sistema deve entrar o valor manualmente.

O Multiple Hits campo 634 permite a entrada das escolhas: Sim, não e padrão.

Isso determina se uma fonte de dados pode ser atingida várias vezes pelo sistema para a mesma requisição. Se default for escolhida, em seguida, as informações colhidas na tela fontes de dados é utilizado. Ao clicar em Next 636 botões, 640 GUI mostrado na figura. 23 é acessada para especificar os conjuntos de regras aplicadas a várias fontes de dados para verificar as informações afirmar, como descrito acima. Ele também permite o ajuste do valor de confiança e de status para cada regra no conjunto de regras.

Há um guia 642 para cada fonte de dados para a configuração atual. Cada fonte de dados deve ter pelo menos um conjunto de regras 644. 0 conjunto de regras é o conjunto de regras de identificação que foi atribuído no motor de regras. O valor de confiança para a fonte de dados está inscrita no campo 646, embora o estatuto de Estado associado (on, off, ensaio) é representado no campo 648. A soma dos valores de todas as regras de confiança para uma fonte de dados não pode exceder o valor de confiança atribuído para a fonte de dados. 0 aplicativo salva a configuração quando o operador clica no botão acabado 649. Antes de guardar a informação, a aplicação de software valida que não existem duas configurações com as mesmas configurações.

A Figura 24 mostra GUI 650 para pesquisar reivindicações que foram processados pelo sistema de ALV 38. Essa tela não servem como um relatório de pedidos processados. Ele é acessado clicando em pesquisar o ícone

470. 650 GUI	permite pesquisar	reclamações	de qualquer
combinação dos	seguintes elementos:
• Office	(652) : Derrube com	a lista de	escritórios.
AH Opção está	disponível.
• Linha	de Negócios (654	): Derrube	os valores
dependendo do	Office selecionado	A opção	Todos está

disponível.

• Cliente (656): Derrube com a lista de clientes. A lista depende do Office selecionados e linha de negócios. A opção Todos está disponível.

• Produto Bundle (658) : Lista de pacotes do produto em função selecionada Office, linha de negócio e clientes.

A opção Todos está disponível.

• Componente (660): Lista de componentes, dependendo do Office selecionado, linha de negócio, clientes e produtos Bundle. A opção Todos está disponível. · Número de Benefício (662): caixa de texto para entrar Benefício Number.

• Sequence (664): Derrube com números de sequência, dependendo Benefício Number.

• RAS (666): Derrube com escores de risco possível. A opção Todos está disponível. · TCL (668): Derrube com os valores possíveis TCL. A opção Todos está disponível.

• Fonte de Dados (670): Derrube com a lista de fontes de dados. Esta lista de filtro é baseado no componente selecionado.

• Continuar inicial (672): Derrube com três opções Tudo, inicial, e Continuação.

• Configuração (674): caixa de texto para entrar ALV Client Configuration ID.

• Mantenha as amostras (676): Derrube com três opções

- Tudo, Sim ou Não

Beneficiar (678): caixa de texto para inserir a data. Para benefício (680) : caixa de texto para inserir a data.

A busca retorna todos os registros que correspondem aos critérios selecionados. Ele mostra os seguintes campos:

• Número de Benefício • Número de seqüência • Data em que ALV verificado benefício • Office • Linha de Negócios • Pacote de Produtos • Componente • Cliente • RAS TCL • Fontes de Dados • Mantenha fora • Status

Clicando no ícone busca 682 puxa as entradas de crédito processados, que estão resumidas na caixa 684.

Botão Reset 686 permite que outra pesquisa será realizada.

GUI 690 ilustrado na figura 25 mostra todos os detalhes do sistema de verificação processados ALV selecionado. No campo superior 692, que mostra o número de benefício 694, nome do reclamante 696, gabinete 698, linha de negócios de 700, 702 pacotes de produtos, o cliente 704,

706 componentes, a data da perda de 708, inicial ou contínua status do beneficio 710, a configuração do cliente ALV ID 712, ALV status 714, RAS pontuação 716, TCL pontuação 718, MW valor de 720, e mantenha a amostra 722.

Esta informação é puxada pelo sistema de bancos de dados. A tela também mostra na tabela 724 conjuntos de regra, se houver, que foram executadas pelo sistema de ALV 38 para determinar se o processo de verificação ALV deve prosseguir. Finalmente, GUI 690 726 mostra na tabela todas as fontes de dados que foram utilizados para validar o crédito e as resultantes PVV 728, RPVV 730, atingiu o valor 732, AVV 734, RVV 736, 738 fonte de dados prioritários, dados de status fonte 740, e do Estado 741 conjuntos utilizados para verificar a informação. Se foram solicitadas informações adicionais do requerente, este facto reflecte-se no campo 742. 0 estado ALV é indicado no campo 744 para cada uso iterative das fontes de dados.

No entanto, outra característica importante da ferramenta de verificação automática da perda 38 da presente invenção é o seu ambiente de testes de controle 800 módulo. Tal como é descrito na fig. 26, que compreende um motor de regras paralelas 802, banco 804, e um conjunto de controle de gestão de GUIs 806 que são acessados por testar o ícone 472 da gestão ALV console (ver figura 14.) . Este módulo de controle do ambiente de teste é usado para testar as alterações propostas para as configurações de ALV ou regras antes de serem incorporadas no sistema de produção. As regras do motor 108, bancos de dados associados 62, 66, 68, 82, 84, 86, controle e gestão de GUIs 450 para o sistema de produção já foram descritas acima. Corroborando com as fontes de dados 110, 112 suportam o sistema de produção eo sistema de controle do ambiente de teste. Por ter o seu motor de regras próprias e 802 804 bases de dados associadas, os dados de teste podem ser obtidos quer a partir de reivindicações históricas contidas nos pedidos de dados a visão de produção 810, ou inseridos manualmente através de créditos do banco de dados de teste de visão 808. Desta forma, o operador de sistemas pode modificar as variáveis de entrada importante para o sistema de ALV, como os valores de RAS para um crédito, os valores necessários para o pedido TCL, os pontos de confiança os valores atribuídos às fontes de dados comprobatórios (internos e externos), novas fontes internas ou externas de dados comprobatórios, a combinação de fontes de dados comprobatórios atribuído a verificar um sinistro específico que, a ordem de consulta para essa combinação de fontes de dados comprobatórios atribuído a esse pedido, etc, para determinar dentro de um ambiente de teste controlado os resultados de desempenho para o sistema de ALV 38. 0 operador de sistemas vai querer se certificar de que as mudanças propostas para os parâmetros do sistema ALV produzir benefícios de um resultado que precisa verifica a perda testados antes requerida que as modificações sejam realmente incorporados no motor de regras e bases de dados para o sistema de produção. Assim, este módulo de controle do ambiente de teste 800 permite que o sistema ALV 38 para ser verificada, mantidos e ajustados, quando necessário, para garantir a otimização do sistema 38.

Outros exemplos:

Os três exemplos seguintes ilustram uma requisição em que a seguradora valida um pedido, solicitando a verificação de uma fonte independente do requerente.

Exemplo 5:

Um cliente que apresente um pedido de morte e a requisição é classificada como de baixo risco. A alternativa mínimos aceitáveis de validação para aprovação incluem: (a) revisão da obituário publicado, (b) obter a confirmação de uma agência de governo que o indivíduo está morto, ou (c) a obtenção de uma certidão de óbito. Neste exemplo, o sistema automaticamente procura um banco de dados adquiridos obituário publicado em uma notícia boa reputação de serviço on-line para uma pessoa combinando os fatos fornecidos pelo beneficiário. A web não é uma fonte válida por um obituário a menos que seja em um site de notícias oficial. Se houver uma correspondência, o pedido é automaticamente aprovado. Se nenhuma correspondência for encontrada, o sistema automaticamente procura o banco de dados de segurança social para um indivíduo relatou falecido correspondente a fatos fornecidos pelo beneficiário. Se for encontrada uma correspondência, o pedido é automaticamente aprovado. Se nenhuma correspondência for encontrada, o sistema notifica os clientes que eles devem fornecer provas da morte através do envio de uma certidão de óbito.

Exemplo 6:

Um cliente que apresente um pedido de morte ea requisição é classificada como de médio risco. Os métodos alternativos de validação mínima para aprovação incluem:

(a) obtenção da confirmação de uma agência governamental, ou (b) a obtenção de uma certidão de óbito. Neste exemplo, o sistema automaticamente procura o banco de dados de segurança social para um indivíduo relatou falecido correspondente a fatos fornecidos pelo beneficiário. Se for encontrada uma correspondência, o pedido é aprovado. Se nenhuma correspondência for encontrada, o cliente será

notificado para fornecer uma cópia do	atestado de	óbito.
Exemplo 7:
Um cliente que apresente um	pedido de	morte ea
requisição é classificada como de	alto risco.	0 único

método aceitável para aprovação de validação é um atestado de óbito. O cliente é convidado a apresentar uma certidão de óbito. Os exemplos 1 e 2 ilustram situações em que o processo é automaticamente pesquisa de várias fontes para confirmar o evento (morte), independente da intervenção do requerente. Nesses exemplos, se o sistema for bem sucedido na validação da morte através de uma das alternativas validação independente, o cliente é imediatamente informado que a perda tenha sido verificada, sem necessidade de verificação pelo cliente, além disso.

A vantagem é que o cliente é livre de encargos, a requisição é aprovada mais rapidamente, ea companhia de seguros ou credor completar a operação mais eficiente. Os exemplos seguintes ilustram uma situação em que uma companhia de seguros ou credor valida um pedido de indemnização, independentemente compilação de informações de várias fontes para aumentar a confiança que eles têm em afirmações feitas pelo autor.

Exemplo 8:

A requerente apresente um pedido de deficiência. Eles tornaram-se incapazes de trabalhar como resultado de um ataque cardíaco recente. 0 cliente chama a empresa de seguros para registrar uma requisição deficiência. A empresa recolhe as informações relacionadas com o evento, que inclui a data de ataque cardíaco, o médico, medicações prescritas, duração da estadia no hospital. O sistema valida automaticamente que o médico identificou pelo cliente é um especialista cardíaca. Ele também confirma que o medicamento é identificado normalmente prescritos para vitimas de ataque cardíaco. O sistema também automaticamente valida contra um serviço de base de dados da prescrição que o cliente recebeu as drogas da prescrição de algum tempo após o evento. Usando uma combinação desses pontos de informação verificada, o sistema aprova o pedido.

Exemplo 9:

Um cliente que apresente um pedido de deficiência. Eles tornam-se incapazes de trabalhar devido a lesão das costas. O cliente chama a empresa de seguros para registrar uma requisição deficiência. A empresa recolhe as informações relacionadas com o evento. O sistema valida automaticamente que a medicação que o reclamante alega ter como resultado da lesão é indicada para esse tipo de lesão. O sistema valida que o médico identificado como o médico é um médico licenciado. O sistema gera uma confirmação por email automático de visitar o médico e os clientes afirmaram que eles são pessoas com deficiência e incapacidade para o trabalho e solicita que o médico responder de imediato se as informações prestadas são imprecisas. Após dois dias de suspense, o sistema automaticamente aprova o pedido sem trabalho adicional.

A especificação acima, exemplos e dados fornecem uma descrição completa do sistema de verificação automático de indenização associado ao método da presente invenção. Uma vez que muitas modalidades da invenção podem ser feitas sem se afastar do espírito e âmbito de aplicação da invenção, a invenção reside nas reivindicações aqui anexadas.

Claims (16)

1. REIVINDICAÇÕES

   1. Sistema automatizado tendo um banco de dados de informações para o processamento de uma requisição no âmbito de um contrato de cobertura de benefício emitido por uma seguradora ou instituição financeira, tal sistema, sendo CARACTERIZADO por compreender:

   (a) identificar o contrato de cobertura de beneficio e fatos que caracterizam um evento indenizatório requerido no âmbito de um contrato de cobertura de beneficio;

   (b) dispositivos para atribuir uma pontuação de avaliação de risco através de um modelo estatístico ou um conjunto de regras de negócio da companhia de seguros ou instituição financeira para o crédito no âmbito do contrato de cobertura de benefício para caracterizar o risco de que a requisição é fraudulenta ou incorrecta utilizando técnicas de modelagem estatística;

   (c) dispositivos para associação do resultaqdo de riscos da avaliação para a requisição de um nível total de confiança (TCL) do valor requerido pela companhia de seguros ou instituição financeira para verificação do evento indenizatório requerido;

   (d) dispositivos para pré-selecionar uma pluralidade de fonte de dados corroboradoras com cada uma caracterizada por um valor de nível de confiança escolhido ou modelado estatisticamente pela companhia de seguros ou por uma instituição financeira para tal capacidade da fonte de dados, de verificar o evento indenizatório requerido;

   (e) dispositivos para consultar automaticamente uma das fonte de dados corroboradoras para determinar se o seu conteúdo informacional confere com as informações fornecidas pelo requerente para o evento indenizatório requerido, e somente no caso positivo, o valor do nível de confiança préatribuído da fonte de dados corroboradora está sendo adicionado a um resultado do valor acumulado de verificação (VAV) para a requisição;

   (f) dispositivos para determinar um valor de verificação restante (RVV) necessário para verificação do evento indenizatório requerido pela subtração da pontuação AVV do valor TCL (ie, RVV = TCL - AVV);

   (g) a repetição iterative das etapas (e) e (f) , com sucessivas fontes de dados corroboradoras se o valor RVV é inferior ao valor TCL;

   (h) no caso em que a pontuação AVV para as requisições é pelo menos igual ao valor TCL necessário, tratar a requisição como verificado para a adjudicação de acordo com as regras do contrato de cobertura de benefício para disposição final; e (i) tratar a requisição como não verificada se o valor acumulado AVV não for igual ou superior ao valor TCL necessário, com nenhuma outra fonte de dados disponível que corrobore com um valor de nível suficiente de confiança atribuído que eliminaria a diferença entre o valor AVV e o valor TCL neceesário se isto fosse consultado pelo sistema.
2. 2. Sistema automatizado de processamento de requisição de crédito, de acordo com a reivindicação 1, CARACTERIZADO por adicionalmente compreender meios para verificar que o requerente tem direito a requerer um benefício nos termos do contrato de cobertura do benefício antes da utilização iterativa das etapas (e) e (f) , corroborando com as fontes de dados.
3. 3. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO por adicionalmente compreender meios para verificar que o requerente tem direito a requerer um benefício nos termos do contrato de cobertura do beneficio após pelo menos o primeiro uso iterativo das etapas (e) e (f) corroborando com as fontes de dados.
4. 4. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a disposição final da requisição inclui o pagamento do crédito ao requerente de acordo com as regras do contrato de cobertura de benefícios conforme o evento do sinistro requerido e verificado.
5. 5. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a disposição final da requisição inclui um requisição para a verificação do sinistro fornecida pelo cliente do evento indenizatório requerido conforme a o evento do sinistro requerido não verificado após a aplicação do processo de verificação automática utilizando as fonte de dados corroboradoras com a requisição.
6. 6. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO por adicionalmente compreender na ocorrência que pelo menos uma fonte de dados corroboradoras adicional se torne disponível para consulta automática pelo sistema durante o processamento da requisição:

   (J) dispositivos para calcular o valor máximo da verificação (MVV) para todas as fontes de dados corroboradoras disponíveis a qualquer momento durante o processamento da requisição;

   (K) dispositivos para calcular o valor presente da verificação (PVV), conforme os valores de confiança total para as fontes de dados corroboradoras particular disponível durante a iteração atual das etapas (e) e (f) ;

   (1) dispositivos para calcular o valor presente de verificação em execução (RPVV) conforme a soma do valor RPVV anterior e o valor PVV para as fontes de dados corroboradoras disponíveis durante a iteração atual das

   etapas (f) e (g) (ie, RPVV = RPVV + PVV); (M) somente proceder com o processo de iteração das etapas (f) e (g) se PVV> 0; e (N) , somente proceder com a repetição das etapas (f) e (g) para a disponibilização de fontes de dados

   corroboradoras se RVV> MVV - RPVV.
7. 7. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO por contrato de cobertura de benefícios compreender uma apólice de seguro.
8. 8. Sistema automatizado de processamento de requisição de crédito de reivindicação 5, CARACTERIZADO por a apólice de seguro ser selecionada do grupo do seguro de invalidez de curto prazo ou longo prazo, seguro de saúde, seguro de doença grave, seguro odontológico, seguro de vida, seguro de vida universal, seguro de vida variável, anuidades, seguro contra incêndio, seguro de proprietário de imóvel, seguro contra tornado, furacão e inundação, seguro de automóvel, seguro marítimo, e outras formas de propriedade e seguro contra acidentes.
9. 9. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o contrato de cobertura de benefícios compreende um contrato de protecção de dívida.
10. 10. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO por adicionalmente compreender um conjunto de regras para automaticamente escolher a fonte de dados corroboradora a ser comparados com a informação da ocorrência do sinistro requerida baseada em sua aptidão para a verificação da ocorrência do sinistro de uma forma rentável.
11. 11. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que a conveniência das fonte de dados corroboradoras compreende o seu custo de acesso.
12. 12. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que a conveniência das fonte de dados corroboradoras compreende a taxa de sucesso.
13. 13. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 8, CARACTERIZADO pelo fato de que a conveniência das fonte de dados corroboradoras compreende a comparação do valor do nível de confiança da fonte de dados corroboradora com o valor RW para a requisição.
14. 14. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a fonte de dados corroboradora é um banco de dados interno mantido pela companhia de seguros, uma instituição financeira, ou o operador do sistema.
15. 15. Sistema automatizado de processamento de requisição de crédito de acordo com a reivindicação, CARACTERIZADO pelo fato de que a fonte de dados corroboradora é um banco de dados externos provenientes de terceiros.
16. 16. Sistema automatizado compreendendo um banco de dados de informações para processar uma requisição nos termos de um contrato de cobertura de benefício emitido por uma companhia seguradora ou instituição financeira, tal sistema sendo CARACTERIZADO pelo fato de que compreender:

    (a) identificar o contrato de cobertura de benefícios e fatos que caracterizam um evento indenizatório requerido nos termos do contrato de cobertura do benefício;

    (b) dispositivos para atribuir uma pontuação única que combina a avaliação do risco relativo do requerente, o evento do sinistro reivindicado, e um ou mais fonte de dados corroboradora pré-selecionadoa usando técnicas de modelagem estatística que representam um nível de confiança de que a requisição não é fraudulenta ou errônea;

    (C) dispositivos para consultar automaticamente uma ou mais fontes de dados corroboradoras para determinar se o seu conteúdo informacional coincide as informações prestadas pelo requerente para o evento indenizatório requerido;

    (d) apenas no caso de informações casadas, o tratamento da requisição conforme verificada para liberação em conformidade com as regras do contrato de cobertura de benefício para disposição final, e (e) considerar a requisição como não verificada se não houver uma correspondência positivade informações.