BRPI0715484A2 - controle de conformidade em um programa com base em cartço - Google Patents

Abstract

CONTROLE DE CONFORMIDADE EM UM PROGRAMA COM BASE EM CARTçO. A presente invenção refere-se a um sistema de análise que processa dados de transações financeiras para verificar a conformidade com um programa de pagamento, tal que o processamento envolve receber dados em relação a um conjunto de transações financeiras que foram autorizadas por um sistema de processamento do pagamento, e determinar se uma ou várias das transações financeiras autorizadas serão submetidas a uma transformação adicional, em que a transformação adicional opera sobre os dados recebidos e identifica as transações financeiras autorizadas que podem estar fora de conformidade com as regras de transação do programa de pagamento.

Description

Relatório Descritivo da Patente de Invenção para "CONTROLE DE CONFORMIDADE EM UM PROGRAMA COM BASE EM CARTÃO".

Referência Cruzada a Pedidos Relacionados

Esse pedido está relacionado com o pedido provisório U.S. No.

60/833.455, depositado em 25 de julho de 2006 intitulado "Fraud Detection in a Controlled Card Based Program" de Matthew Mullen e Scott Spivack. O conteúdo do pedido provisório é incorporado aqui por referência em sua tota- lidade para todas as finalidades. Antecedentes Campo da Invenção

A presente invenção refere-se a transações financeiras conduzi- das com dispositivos de consumidor portáteis tal como cartões de pagamen- to e cartões inteligentes, e mais particularmente, se refere ao gerenciamento de programa para tais transações financeiras. Descrição da Técnica Relacionada

O uso indevido e abuso dos programas de pagamento de tran- sação, tal como programas de cartão de crédito que utilizam cartões de co- brança, cartões inteligentes, cartões de débito e outros dispositivos de con- sumidor portáteis para pagamento de transações financeiras, afetam uma ampla variedade de negócios envolvidos em tais transações. Como resulta- do disso, o controle de conformidade é importante para os negócios envolvi- dos nos programas de pagamento com base em cartão, incluindo comerci- antes, aquisitores de pagamento e emissores. Tais programas de pagamen- to sujeitam tipicamente as transações a uma série de verificações de valida- de e autorização através do processamento online antes de qualquer transa- ção individual ser aprovada. Uma variedade de códigos especiais, chaves de criptografia, e similares são freqüentemente utilizados para garantir que a- penas os cartões válidos sejam apresentados a um comerciante. Essas pro- teções são direcionadas para evitar fraude, mas não são de grande vanta- gem no gerenciamento de programas de pagamento para impedir o uso in- devido e o abuso.

O uso indevido e o abuso podem ocorrer em transações com cartões válidos onde a transação propriamente dita pode não estar em con- formidade com as regulamentações do programa de pagamento para uso. Por exemplo, uma transação pode ser a compra de cobranças inadequadas e não permitidas, ou uma transação pode exceder o limite de transação au- torizado para o usuário, apesar de a transação poder, de outra forma, ser válida. Tal uso indevido e abuso dos cartões autorizados continuam a ser um problema. Como resultado disso, os negócios continuam a sofrer de perdas significativas devido à atividade que constitui o uso indevido ou abuso dos cartões autorizados.

O uso em não conformidade dos cartões é um problema tão im-

portante que o governo americano ordenou controles internos para as agên- cias governamentais com relação a programas de pagamento com cartão de cobrança governamentais administrados pelas agências. Tais programas de pagamento com cartão de cobrança incluem programas para contas de car- tão de compra e para contas de cartão de viagem. Como resultado disso, os emissores de cartão que desejam fornecer o processamento de transações financeiras e participar de programas de compra com base em cartão patro- cinados pelo governo devem ter em mente tais regulamentações. Os contro- les internos necessários para tais cartões emitidos pelo governo são descri- tos na Circular A-123 do Escritório de Gerenciamento e Orçamento do Go- verno dos Estados Unidos (OMB) referente ao programa de cartão de con- trole federal. O Anexo B (revisado em fevereiro de 2006) da publicação da Circular A-123 é intitulado "Improving the Management of Government Char- ge Card Program" e é direcionado à garantia de controles efetivos para miti- gar o risco de abuso, uso indevido, e delinqüência em tais contas de cartão. O treinamento, métricas de desempenho, e reporte de dados são componen- tes do programa. Dessa forma, a preocupação com o uso em não conformi- dade dos cartões de pagamento se estende das empresas comerciais às agências do governo. Deve ser aparente a partir da discussão acima que existe a ne-

cessidade de se ter um processamento de transação de pagamento que a- jude a reduzir a incidência do uso indevido e abuso nos programas de pa- gamento de transação financeira que envolvem cartões de compra, disposi- tivos de consumidor portáteis, e similares. As modalidades da presente in- venção satisfazem essa necessidade. Sumário

As modalidades da presente invenção permitem o processamen-

to de dados de transações financeiras em conformidade com um programa de pagamento, de forma que o processamento envolva o recebimento de dados referentes a um conjunto de transações financeiras que foram autori- zadas por um sistema de processamento de pagamento, e a determinação de se uma ou mais transações financeiras autorizadas serão submetidas a processamento adicional, onde o processamento adicional opera nos dados recebidos e identifica as transações financeiras autorizadas que podem não estar em conformidade com as regulamentações de transação do programa de pagamento. Em outro aspecto, o processamento adicional pode compre- ender o processamento de dados recebidos com um conjunto de regras de comercialização predeterminadas e identificação das transações financeiras como uma transação passada que está em conformidade com as regula- mentações de transação, ou como uma transação sinalizada que deve ser verificada por violação de uma ou mais das regulamentações de transação. No contexto da presente discussão, uma "transação passada" compreende uma transação que não foi rotulada como violando uma regulamentação de transação. A transação financeira, se identificada como uma transação pas- sada, pode ser processada para determinar se a transação passada inclui as características de transação que indicam uma transação provavelmente em não conformidade. Dessa forma, mesmo as transações passadas que são autorizadas podem ser submetidas a processamento adicional. Dessa forma, a invenção ajuda a reduzir a incidência de uso indevido e abuso nos pro- gramas de pagamento de transação financeira que envolvem os cartões de compra, dispositivos de consumidor portáteis, e similares. Em outro aspecto adicional, o processamento adicional pode

compreender a amostragem do desempenho nas transações passadas para designar uma ou mais das transações passadas como transações sinaliza- das a serem verificadas por violação de uma ou mais das regulamentações de transação. Em outro aspecto, o processamento adicional pode compre- ender a realização do processamento de predição nas transações passadas para identificar as características da transação que compreendem o compor- tamento para evitar as regras indicando uma transação provavelmente em não conformidade. Em outro aspecto, uma interface de usuário conveniente pode ser fornecida de modo que o registro de usuário pode ser recebido a- través de uma rede, o usuário pode ser considerado autorizado, e a opera- ção do processamento adicional pode ser ajustada de acordo com o registro de usuário. Em particular, o processamento das transações passadas pode ser alterado dessa forma.

Um sistema construído de acordo com a invenção pode incluir componentes para realizar o processamento da transação financeira de for- ma que a amostragem e o processamento de predição possam ocorrer para as transações passadas. Tais componentes podem ser mantidos pelos e- missões do cartão para operação durante o processamento de transação financeira para mitigar a incidência de práticas de transação em não confor- midade.

Outras características e vantagens da presente invenção devem ser aparentes a partir da descrição a seguir das modalidades ilustrativas, que ilustram, por meio de exemplo, os aspectos da invenção. Breve Descrição dos Desenhos

a figura 1 é uma representação de diagrama em bloco funcional de alto nível de um sistema de processamento construído de acordo com a presente invenção;

a figura 2 é um diagrama em bloco dos componentes compreen- dendo o sistema de análise ilustrado na figura 1;

a figura 3 é um fluxograma que ilustra as operações realizadas pelo processador de Regras De comercialização/Filtro do sistema de análise ilustrado na figura 1;

a figura 4 é um fluxograma que ilustra as operações realizadas pelo processador de amostragem do sistema de análise ilustrado na figura 1; a figura 5 é um fluxograma que ilustra as operações realizadas pelo processador de predição do sistema de análise ilustrado na figura 1;

a figura 6 é um fluxograma que ilustra as operações realizadas pelo processador de Conformidade e Auditoria do sistema de análise ilustra- do na figurai;

a figura 7 ilustra os desenhos de plano de amostragem como recebidos no sistema de análise de dados através do registro de usuário. Descrição Detalhada

Um diagrama funcional de alto nível de um sistema de proces- samento de transação 100 construído de acordo com a presente invenção é ilustrado na figura 1. No sistema 100, um cartão 102 (ou outro dispositivo de consumidor portátil) é utilizado em uma transação financeira, tal como sendo apresentado a um comerciante 104 para o pagamento de bens ou serviços. A apresentação do cartão 104 pode compreender a leitura do cartão por uma leitora de processamento no comerciante, ou o fornecimento por parte do detentor do cartão do número do cartão a um comerciante através de um pedido por telefone, ou o registro do número do cartão de informação asso- ciada através de uma conexão de dados de rede. Uma vez que a informação do cartão é registrada, o processo de pagamento para a transação financeira associada é iniciado e os dados de transação prosseguem através de um sistema de processamento de pagamento 106 que será familiar aos versa- dos na técnica.

O sistema de processamento de pagamento 10 inclui um pro- cessamento de autorização e verificação para pagamento através da conta do detentor do cartão. No sistema 100 da figura 1, os dados relacionados com a transação financeira são recebidos em um sistema de análise 108 construído de acordo com a invenção. O sistema de análise 108 permite que os usuários do sistema 110 acessem os dados recebidos através de uma rede segura 112 e realizem várias funções de gerenciamento de dados, ge- ração de relatório e administração de sistema, compreendendo assim uma rede de análise de transação 114 que pode ajudar a mitigar as transações não em conformidade no sistema de processamento de pagamento 106. Os versados na técnica apreciarão que o sistema de processa- mento de pagamento 106 opera para receber transações financeiras em um comerciante 104 e fornecer as transações através da rede de dados do co- merciante 120 para um computador central do comerciante 122 para proces- samento adicional. No computador central do comerciante, as transações financeiras para o comerciante são transmitidas para a pessoa que adquire o pagamento do processamento do cartão 124 e são então transmitidas atra- vés de uma rede de processamento de pagamento 126 para o emissor do cartão 128. Deve-se notar que, apesar de os componentes específicos se- rem ilustrados na figura 1, os sistemas de acordo com as modalidades da invenção podem incluir mais ou menos componentes do que são ilustrados na figura 1. Por exemplo, apesar de dois blocos separados serem ilustrados para a pessoa que adquire o cartão 124 e o emissor 128, deve-se compre- ender que uma única organização pode agir como um emissor e um elemen- to de aquisição em alguns casos. Na figura 1, todas as linhas de conexão indicam as comunicações de dados entre os componentes. Todas as comu- nicações de dados ocorrem através de conexões seguras.

Os dados para uma transação 104 podem ser recebidos no sis- tema de análise 108 depois da autorização de pagamento e acerto com o emissor 128 já terem ocorrido. Os dados de transação geralmente incluem número de cartão e dados do detentor da conta tal como endereço, saldo, e limite autorizado de gastos, além de dados da transação como extrato da conta, nome e endereço do comerciante, data da cobrança, quantidade de pagamento e similar. A figura 1 ilustra que o sistema de análise 108 pode receber dados de transação diretamente de uma agência de cartão 130. A agência de cartão compreende uma organização de patrocínio ou outra enti- dade que é envolvida no gerenciamento da conta para o cartão 102 e que autoriza o uso do sistema de análise 108 para o gerenciamento da conta e para prevenir o uso em não conformidade. Dessa forma, se o cartão for for- necido por um empregador ou uma agência do governo, então esse empre- gador ou agência compreende a agência do cartão 130 que autoriza e ge- rencia o uso do sistema de análise 108 através dos usuários do sistema 110. Os usuários do sistema podem acessar o sistema de análise 108 através de uma conexão de rede segura 112, tal como uma conexão de Internet "https" através de um navegador da rede. O acesso à Rede permite um acesso re- lativamente conveniente para os usuários para o gerenciamento e adminis- tração da conta. Os usuários 110 serão geralmente empregados da agência de cartão 130 que receberam privilégios de acesso, mas podem incluir quaisquer outras pessoas que receberam acesso pela agência, como descri- to adicionalmente abaixo.

A figura 1 ilustra que o sistema de análise 108 também pode re- ceber dados de transação diretamente do emissor 128, como indicado pela conexão na figura 1. O sistema de análise também pode receber dados so- bre a transação financeira através de uma conexão de rede 112, tal como através de uma conexão de Internet segura através do protocolo https. Isto é, os dados da transação podem ser recebidos através de uma rede pública como a Internet, desde que a conexão seja uma conexão segura entre o re- metente e o destinatário.

O cartão 102 pode alternativamente ser um dispositivo de con- sumidor portátil em qualquer forma adequada para registrar os dados da transação no sistema 106. Por exemplo, em adição a compreender um car- tão de crédito convencional, o dispositivo de consumidor portátil pode com- preender um dispositivo portátil que pode encaixar na carteira e/ou bolso do consumidor (por exemplo, um dispositivo de bolso). Tais dispositivos de con- sumidor portáteis podem incluir cartões inteligentes, cartões de credito ou debito convencionais (com uma tira magnética e sem um microprocessador), um token ou dispositivo para chaveiro (tal como dispositivo Speedpass™ comercialmente disponível, na Exxon-Mobil Corp.) e similares. Outros exem- plos de dispositivos de consumidor portáteis adequados incluem dispositivos eletrônicos de consumidor tal como telefones celulares, assistentes digitais pessoais (PDAs), pagers e similares. Outros exemplos de dispositivos de consumidor portáteis 102 incluem cartões de pagamento, cartões de segu- rança, cartões de acesso, mídia inteligente, transponderes, e similares, des- de que a informação do detentor da conta e os dados da transação possam ser registrados no sistema de processamento 106.

O sistema de análise 108 pode ser baseado na rede, compreen- dendo um computador servidor de Rede que executa os módulos de pro- grama que realizam as operações descritas aqui. Os módulos de programa compreendem aplicativos de software de computador que são instalados e são executados em um processador de computador tal como o computador de servidor da Rede. Como notado acima, o computador servidor da Rede do sistema 108 pode ser acessados através de uma conexão de Internet segura 112 por usuários autorizados 110. A figura 2 ilustra os módulos que executam no computador do servidor da Rede em uma modalidade constru- ída de acordo com a presente invenção. Na discussão apresentada aqui, as referências a "o aplicativo" serão compreendidas como se referindo ao sis- tema de análise 108, ou a um ou mais componentes do mesmo.

O sistema da figura 1 recebe os dados referentes a uma transa- ção financeira que recebeu autorização de pagamento pelo sistema de pro- cessamento de pagamento 106 e identifica a transação financeira como uma transação indicada que deve ser verificada por violação de um ou mais es- quemas de filtragem de transação ou regras comerciais, ou como uma tran- sação passada. Uma transação passada compreende uma transação finan- ceira que foi verificada por um filtro e/ou violação de regras das regulamen- tações de transação de programa, ao passo que uma transação passada é uma transação autorizada que "passou" pela investigação inicial por violação das regulamentações de programa, ao passo que uma transação "indicada" compreende uma transação autorizada que foi designada para revisão adi- cional. O sistema determina se uma transação autorizada deve ser submeti- da a processamento adicional, onde tal processamento adicional é para fins de identificação das características da transação que indicam uma transação provavelmente em não conformidade (uso indevido ou abuso). Tipicamente, o processamento por violações de parâmetros de filtro e regras comerciais são automaticamente uma parte do processamento adicional. Como descrito adicionalmente abaixo, o processamento adicional pode incluir o processa- mento de amostragem para identificação das transações por investigação adicional independentemente de quaisquer características relacionadas com a transação propriamente dita. Alternativamente como descrito abaixo, o processamento adicional pode compreender o processamento do elemento de previsão no qual as características da transação de uma transação pas- sada são examinadas para identificar as características que indicam a ativi- dade provavelmente em não conformidade.

A figura 2 ilustra 12 módulos compreendendo uma modalidade de um sistema de analise 200 construído de acordo com a invenção. O sis- tema é apresentado na figura 2, para fins de ilustração, como doze módulos dispostos em torno do sistema de analise 200 no cento. Deve-se compreen- der que o sistema de análise pode interoperar com outros sistemas de com- putador, de forma que não seja necessário que o sistema de análise realize as funções de todos os doze módulos. Isto é, um ou mais dos doze módulos podem ser instalados em outros computadores que não estão localizados no mesmo nó de rede (e não compartilham a memória operacional) no compu- tador do servidor da Rede do sistema de análise 108 (figura 1). Qualquer sistema de computador ou servidor de Rede com qualquer um dos módulos instalados e em execução serão referidos como um "processador" do tipo de módulo associado. Dessa forma, um sistema de computador com um módu- lo de gerenciamento de programa instalado no sistema pode ser referido aqui como um "processador de gerenciamento de programa" e referências a "módulo" e "processador" devem ser utilizadas de forma intercambiável para se referir a um sistema de computador com um software de módulo associa- do instalado e em execução.

Os doze módulos ilustrados na figura 2 incluem: um módulo de gerenciamento de dados principal 202; um módulo de segurança 204; um módulo de relatório 206; um módulo de painel 208; um módulo de fil- tro/regras 210; um módulo de amostragem 212; um módulo de previsão 214; um módulo de auditoria de conformidade 216; um módulo de otimização 218; um módulo de fonte estratégica 220; um módulo de gerenciamento de programa 222; e um módulo de treinamento 224. O módulo de gerenciamen- to de dados principal 202 e o módulo de segurança 204 garantem a segu- rança adequada dos dados e as capacidades de administração e gerencia- mento do programa. Qualquer um dos módulos acima (ou processadores correspondentes) pode ser combinado de forma adequada. Por exemplo, uma modalidade da invenção pode incluir a combinação do módulo de fil- tro/regras, o módulo de amostragem, e o módulo de previsão, com ou sem qualquer um dos outros módulos, em um sistema de computador para ope- ração de acordo com a invenção.

O sistema de análise ilustrado na figura 2 fornece um percurso de processamento para as transações financeiras em adição ao processa- mento através do sistema de processamento de pagamento 106 (ver figura 1). De acordo com a invenção, o processamento do sistema de análise en- volve o processamento de filtro/regras que recebe as transações autorizadas (depois do pagamento) que foram aprovadas (e, portanto, não são conheci- das por terem violado qualquer regulamentação do programa de cartão). Tais transações serão referidas como transações autorizadas ou acertadas. O processamento de filtro/regras então identifica um subconjunto de transa- ções autorizadas que são suspeitas de envolverem atividade em não con- formidade que constituiriam uso indevido ou abuso. Tais transações identifi- cadas serão referidas como transações "indicadas". O estante das transa- ções autorizadas compreende transações "passadas" que não foram identifi- cadas por um filtro ou regra como sendo uma transação em não conformida- de. O processamento do sistema de análise então envolve a identificação de um grupo das transações passadas que será submetido a processamento adicional em busca de atividade potencialmente em não conformidade. O processamento adicional pode envolver a amostragem pelo módulo de a- mostragem 212 ou processamento de previsão pelo módulo de previsão 214, ou ambos. Todos os doze módulos serão descritos em maiores deta- lhes abaixo.

Módulo de Gerenciamento de Dados Principal O módulo de gerenciamento de dados principal 202 aloja todos

os dados para o aplicativo. Pode gerenciar o processo para importação e exportação de dados de aplicativo. Esse módulo se comunicará com todos os doze módulos ilustrados na figura 2 pelo fornecimento da interseção de compartilhamento e permuta de dados. O módulo de gerenciamento de da- dos principal 202 coordenará e facilitará a interação com todas as fontes de dados em potencial. A figura 1 ilustra algumas das fontes de dados prová- veis. As fontes não são totalmente inclusivas e fontes adicionais podem ser incluídas, tal como uma ampla variedade de sistemas externos, de acordo com as capacidades de segurança e iniciativas dos usuários do sistema de análise. O módulo de gerenciamento de dados principal 202 também ajudará a gerenciar o compartilhamento de dados entre os aplicativos independentes (por exemplo, sistema de acesso eletrônico de agência, sistema de acesso eletrônico a banco, bases de dados do emissor tal como dados de perfil do comerciante, sistemas ERP (planejamento de recurso empresarial), e simila- res).

Dessa forma, o módulo de gerenciamento de dados principal 202 pode fornecer as seguintes funções. O módulo pode gerenciar todos os dados de aplicativo. O módulo também pode fornecer armazenamento e es- quemas para todas as tabelas de aplicativo e elementos de dados. Isso pode envolver o fornecimento de funções ETL (extração, transformação e carga) para gerenciar os processos que movem os dados a partir de múltiplas fon- tes, reformatam e limpam (por exemplo, verificação de vírus) os dados e car- regam os mesmos em outra base de dados, um depósito de dados para aná- lise, ou em outro sistema operacional para suportar um processo comercial. O módulo pode manter os perfis dos comerciantes, que envolve o armaze- namento de dados sobre cada comerciante compilados a partir de múltiplas fontes de dados. Pode determinar como combinar um comerciante de dife- rentes fontes sem um chave comum, o que é desejável para se evitar regis- tros duplicados. O módulo também pode gerenciar a funcionalidade de im- portação e exportação de aplicativo. Tal gerenciamento pode envolver a ca- pacidade de aceitar os elementos de dados de uma fonte de dados externa (por exemplo, arquivo de texto, base de dados) e a capacidade de fornecer exportações de dados que podem ser integradas em um Planejamento de Recurso Empresarial da organização, livro caixa geral, ou outros aplicativos de escritório. O módulo também pode fornecer uma ferramenta de mapea- mento de dados, possuindo a funcionalidade para criar uma relação em um novo conjunto de dados e associar a mesma com um campo estabelecido no aplicativo (por exemplo, uma fonte de dados pode rotular o campo "nome do comerciante" como "nome abreviado do vendedor"). Essa funcionalidade pode ser similar a um processo de dados de importação Microsoft Access®. Exemplos de fontes de dados em potencial são ilustrados na figura 1 e po- dem incluir a agência de cartão 130 e as entidades dentro do sistema de processamento de pagamento 106.

A seqüência das operações nas quais esse módulo pode ser

utilizado inclui a seqüência de operações como se segue na Tabela 1.

Tabela 1 Caso de utilização de módulo: 1. Conectar-se ao aplicativo através da extremidade dianteira do portal;

2. Visualizar as conexões com os módulos intitulados;

3. Selecionar o módulo de gerenciamento de dados principal;

4. O usuário do administrador da agência pode selecionar qualquer uma das opções a seguir dentro do módulo de gerenciamento de dados principal;

4.1. Revisar, editar e modificar as relações de mapeamento de dados (por exemplo, visualizar a base de dados Microsoft SQL);

4.2. Monitorar e gerenciar as bases de dados e os serviços de manutenção associados dentro do aplicativo;

4.3. Selecionar a fonte de dados de entrada e relacionar os elementos de

dados com os elementos de dados do aplicativo para importação de

dados (por exemplo, "vendedor" no campo de dados de entrada é o mesmo que "comerciante" no aplicativo. Essa relação seria criada de modo que os dados de "vendedor" sejam importados para dentro do a- plicativo no campo "comerciante");

4.4. Definir, criar e executar arquivos de importação ou exportação de da- dos (por exemplo, exportar um arquivo de dados a ser interfaceado com um aplicativo financeiro local para evitar novo chaveamento de dados);

4.5 Receber confirmação via e-mail de que a extração ou upload foi realizada com sucesso. Se houver erros na extração ou upload, as mensagens de erro podem ser incluídas em um e-mail.

5. O usuário fecha o módulo.__

Módulo de Segurança

O módulo de segurança 204 gerencia a segurança geral do apli- cativo e fornece cada usuário com seus direitos à titularidade do aplicativo específicos. Esse módulo pode servir como um marco para se garantir a se- gurança dos dados para cada agência e usuário. Os direitos à segurança podem ser acionados utilizando-se a estrutura de hierarquia de aplicativo para cada agência. Os direitos podem ser determinados para permitir que apenas os usuários autorizados visualizem seus dados de programa de car- tão. Por exemplo, um programa federal não será capaz de visualizar dados de outro programa federa, e um usuário/detentor de cartão dentro de uma agência não será capaz de visualizar a informação de transação de outro usuário/detentor de cartão. O aplicativo também pode ser projetado para corresponder às exigências de conformidade com a segurança de informa- ção do detentor de cartão pertinentes. A funcionalidade do sistema de análise pode fornecer várias op-

ções de designação de papel para os usuários. Os papéis do usuário e uma breve descrição de sua titularidade antecipada incluem os usuários a seguir. Primeiro, um administrador pode ser um indivíduo que pode ser um "super" usuário que não tem quaisquer restrições dentro do aplicativo, que pode adi- cionar, editar, modificar, eliminar por todo o aplicativo e que pode visualizar os nós de hierarquia dentro do aplicativo e se aprofundar em um nível de detalhamento de transação. Outro usuário é um usuário do sistema de análi- se típico. O usuário do sistema pode ter acesso restrito dentro do aplicativo e pode visualizar os nós de hierarquia intitulados dentro do aplicativo e se a- profundar em um nível de detalhamento de transação. Outro usuário é um administrador de agência. O administrador da agência pode ser um usuário específico da agência, tipicamente no nível de escritório de gerenciamento de programa, intitulado a nenhuma restrição dentro de um ponto de hierar- quia da agência específico, que pode adicionar, editar, modificar ou eliminar informação por todo o aplicativo, mas está restrito aos nós de hierarquia inti- tulados. Um usuário da agência pode ser um usuário que é um usuário intitu- lado a acesso restrito dentro de um ponto de hierarquia de agência específi- co, tal como um coordenador de programa da agência, um oficial de aprova- ção, ou detentor de cartão. Outro usuário é referido como um usuário auditor do sistema de análise, que é intitulado a direitos de visualização apenas dentro do aplicativo. Esse papel é destinado, por exemplo, com relação a usuários na perspectiva do governo federal dos Estados unidos, envolvendo GSA (Administração de Serviços Governamentais), GAO (Escritório de Con- tabilidade do Governo), IG (Inspetor Geral), e similares. O auditor do sistema de análise também pode visualizar todos os nós de hierarquia dentro do a- plicativo e se aprofundar em um nível de detalhamento de transação. Por fim, um usuário auditor de agência é um usuário que é intitulado a direitos de visualização apenas dentro de um ponto de hierarquia de agência específi- co.

Dessa forma, o módulo de segurança 204 pode fornecer as fun- ções de gerenciamento de toda a segurança do aplicativo, manutenção dos perfis de usuário, e gerenciamento da hierarquia de programa. No gerencia- mento de segurança, o módulo pode impedir que uma agência determine se qualquer outra agência está utilizando o aplicativo, mantendo, assim, a con- fidencialidade. No gerenciamento de perfis de usuário, o módulo pode ajudar os usuários a criarem e gerenciarem os perfis de usuário, gerenciarem os direitos de titularidade do usuário, e podem automatizar o processamento de senha esquecida. O gerenciamento da hierarquia do programa envolverá a criação e gerenciamento dos perfis do ponto de hierarquia do programa de gerenciamento e direitos de titularidade do programa de gerenciamento.

As operações ilustrativas associadas com esse módulo são ilus- tradas na Tabela 2 abaixo: Tabela 2

Caso de utilização de módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira do portal;

2. Visualizar as conexões com os módulos intitulados;

3. Selecionar o módulo de gerenciamento de dados principal;

4. O usuário do administrador da agência pode selecionar qualquer uma das opções a seguir dentro do módulo de segurança;

4.1 Gerenciar a segurança do aplicativo como um todo pelo estabelecimen- to da hierarquia de aplicativo. Um usuário pode criar e gerenciar os per-

fis de ponto de hierarquia de programa juntamente com seus direitos à

titularidade de programa associados. A capacidade de realizar essas mudanças será restringida no nível de agência. Criar um perfil para um usuário pelo preenchimento dos campos obrigatórios.

4.2 Designar a um usuário os direitos de titularidade que permitem que um usuário específico visualize e utilize os módulos de aplicativo;

4.3 Designar a um usuário os direitos de titularidade para permitir que um usuário específico visualize, edite, adicione e/ou elimine dentro de seu ponto na hierarquia;

4.4 Gerenciar as partes específicas do processo de "senha esquecida" au- tomatizado e reconfigurar as senhas manualmente como desejado.

5. Usuário fecha o módulo._

Módulo de Relatório

O módulo de relatório 206 gerencia todo o relatório para o apli- cativo. Fornece relatórios padrão, capacidades de geração de relatório ad- hoc e funcionalidade de alerta personalizado. Os alertas personalizados po- dem ser personalizados para corresponder a necessidades específicas de usuário enviando a um usuário uma mensagem de e-mail quando um con- junto predeterminado de critérios foi combinado por uma transação.

Cada programa de carta pode se deparar com muitos desvios em torno dos relatórios. O aplicativo é projetado para auxiliar as agências no preenchimento de suas exigências de relatório. Por exemplo, o aplicativo pode conter relatórios padrão que são projetados para corresponder às exi- gências de relatório federais como negócios pequenos, negócios de proprie- dade de minorias e de propriedade de mulheres, e exigências de relatório para 1099-MISC (pagamentos de serviço) e 1057 (resumo mensal da ação de contratação).

O módulo de relatório 206 pode fornecer acesso online aos da-

dos de transação através de formatos de relatório escalonáveis, pesquisas e métodos de exportação de dados. Dessa forma, os administradores, geren- tes e detentores de cartão podem ter acesso a inúmeros relatórios em uma variedade de formatos, incluindo padrão e gerados por processador, além de pesquisas às bases de dados. A disponibilidade do relatório pode ser restrita pelos direitos à titularidade do perfil do usuário. O módulo também pode for- necer relatórios padrão, incluindo relatórios padrão onde o usuário pode in- dicar critérios específicos (por exemplo, faixa de data, quantia em dólares, etc.) das transações a serem incluídas no relatório. O módulo também pode fornecer capacidades de relatório ad-hoc totais com seleção de apontar e clicar dos elementos de dados a serem incluídos no relatório e pode permitir que o usuário projete, desenvolva e rode um relatório contendo qualquer um dos elementos de dados do aplicativo.

O módulo de relatório também pode fornecer um sistema de a- lerta, possuindo a capacidade de enviar alertas por e-mail com Bse em qual- quer critério do sistema (por exemplo, transações superiores a $ 50,000), envio de um alerta por e-mail para o usuário como solicitado pelo usuário no processo de configuração. O módulo de relatório também pode fornecer pro- gramação de relatório, onde os relatórios utilizarão uma estratégia de geren- ciamento avisando aos usuários que se conectem no aplicativo e iniciem a visualização ou download dos relatórios. Os relatórios podem ser fornecidos em uma variedade de formatos, tal como os formatos de documento PDF, Excel, Word e CSV (valor separado por vírgula). O módulo de relatório per- mite que os usuários programem a emissão de um relatório e distribuição de uma mensagem por e-mail depois da finalização com uma conexão para conectar ao aplicativo e fazer download do relatório.

Operações ilustrativas associadas com esse módulo incluem as seguintes operações na Tabela 3 abaixo:

Tabela 3 Caso de utilização de módulo:

1. Conectar-se;

2. Visualizar menu com a lista disponível dos relatórios padrão e relató- rios ad-hoc;

3. O usuário administrador da agência pode realizar qualquer uma das opções a seguir dentro do módulo de relatório;

3.1 relatórios padrão

3.1.1 o usuário visualiza uma lista de relatórios padrão do aplicativo;

3.1.2 o usuário pode modificar determinados parâmetros (por exemplo, da- ta, etc.) antes de rodar um relatório;

3.1.3 o relatório é gerado;

3.1.4 o relatório pode ser impresso ou enviado por e-mail;

3.2. relatórios personalizados

3.2.1 o usuário visualiza uma lista de seus relatórios personalizados "sal- vados";

3.2.2 o usuário pode modificar determinados parâmetros (por exemplo, da- ta, etc.) antes de rodar um relatório;

3.2.3 o relatório é gerado;

3.2.4 o relatório pode ser salvado, impresso ou enviado por e-mail;

3.3. relatórios ad-hoc

3.3.1 o usuário visualiza uma lista de opções de projeto para a criação de um relatório personalizado;

3.3.2 o usuário pode modificar os parâmetros disponíveis e incluir quais- quer elementos de dados antes de rodar um relatório;

3.3.3 o relatório é gerado;

3.3.4 o relatório é salvado, impresso ou enviado por e-mail;

3.4 Configuração do sistema de alerta por e-mail

3.4.1 estabelecer limites para ativação de um alerta específico;

3.4.2 determinar lista de recipientes

4. usuário fecha o módulo. Módulo de Painel

O módulo de painel fornece uma visualização rápida das métri- cas operacionais chave. O usuário pode determinar quais métricas exibir e como gostaria que a informação fosse exibida. Para cada programa de car- tão de agência, o relatório de dados é uma ferramenta desejável para o a- perfeiçoamento do gerenciamento do cartão de cobrança. Os gerentes de cartão de cobrança e outros acionistas precisam de dados temporais e pre- cisos para determinar a conformidade com as exigências legislativas e ad- ministrativas, a eficiência dos esforços para mitigar os riscos de uso indevi- do, desperdício, e abuso e as tendências de desempenho nos custos de ge- renciamento e outros indicadores relevantes do sucesso do programa. Uma característica desse aplicativo é facilitar a padronizar cada uma das exigên- cias de relatório da agência.

O módulo de painel pode fornecer a funcionalidade de exibição de um painel de programa através do qual os usuários podem alcançar a- cesso online de dados de transação através de formatos de relatório escalo- náveis, pesquisas e métodos de exportação de dados. Através do módulo de painel, os usuários podem visualizar as métricas de programa chave, gráfi- cos, e outras apresentações visuais da informação, se aprofundando para visualiza os detalhes de dados núcleo, configurar os critérios de indicadores "vermelho-amarelo-verde" e uma geração de relatório de solicitação para os relatórios de gerenciamento.

As operações ilustrativas associadas com esse módulo são ilus- tradas abaixo na Tabela 4:

Tabela 4

Caso de utilização de módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira do portal;

2. Visualizar as conexões com os módulos intitulados;

3. Selecionar o módulo de painel;

4. O usuário do administrador da agência verá sua visualização de painel personalizado exibindo as métricas operacionais chave que são perti- nentes ao usuário; 5. O usuário administrador da agência pode realizar qualquer uma das seguintes opções dentro do módulo de painel;

5.1 configurar uma visualização padrão da parte específica de usuário;

5.2 visualizar todas as métricas operacionais chave disponíveis e selecio- nar quais métricas visualizar em seu painel;

5.3 Selecionar o formato de exibição visual das métricas (por exemplo, ta- bela, gráfico, etc.)

5.4 Configurar os indicadores de limite superior e inferior para o usuário. Isso determinará as regiões "vermelha, amarela, verde" das exibições;

5.5 No painel personalizado do usuário, o usuário pode se aprofundar no painel, gráficos e relatórios clicando nos dados exibidos; 5.6 Rodar e modificar os relatórios de gerenciamento. A capacidade de modificação pode ser limitada a mudanças simples (por exemplo, faixa de data, ponto de hierarquia, etc.) 6. O usuário fecha o módulo.___

Módulo de Filtros/Regras

O módulo de filtros/regras gerencia todas as regras comerciais para as transações indicadas. Pode fornecer aos usuários com regras do padrão da indústria juntamente com a capacidade de se criar e personalizar os filtros/regras específicos para suas necessidades. Isso é, as regras co- merciais são independentes das regulamentações do programa de cartão, que não são conhecidas como tenso sido violadas pelas transações autori- zadas. Ao invés disso, as regras comerciais compreendem regras, a viola- ção das quais pode tender a indicar uso indevido ou atividade abusiva. As regras comerciais são critérios determinados pela agência

utilizados para comparar com os critérios de transação a fim de determinar se há uma combinação. Se uma combinação ocorrer, então uma transação é considerada como necessitando de processamento adicional e é "indicada" para investigação adicional. Um conjunto de regras comerciais padrão e con- figurações de filtro pode ser fornecido, e uma interface de módulo é forneci- da para permitir que os usuários autorizados criem regras comerciais e con- figurações de filtro. As regras comerciais comuns utilizadas nos programas de cartão do setor público será tipicamente incluídas nas regras comerciais padrão de aplicativo, que podem incluir o seguinte: lista do governo de "co- merciantes banidos", lista de comerciantes suspeitos, lista MCC bloquea- do/restrito (código de categoria de comerciante), lista MCC suspeita, nova regra comercial, regra de limite excessivo em dólar de transação, regra de transação rápida, regra de compra parcelada, regra de atividade em contas fechadas, regra de transações forçadas, regra de transações em disputa, e regra de transações durante fim de semana e feriados.

Cada agência pode detectar um conjunto personalizado de re- gras comerciais a serem aplicadas a suas transações. As agências podem utilizar o módulo para modificar qualquer uma das regras comerciais padrão ou criar suas próprias regras personalizadas. Cada regra aplicada por esse módulo também terá a capacidade de ser designada para um alerta. O alerta pode notificar um usuário designado através de e-mail de que um critério de regra comercial específico foi combinado dentro de uma transação. Essa funcionalidade pode se provar útil no alerta dos escritórios de gerenciamento de programa de quaisquer transações de alto valor que são processadas utilizando seus cartões.

O módulo de filtros/regras pode fornecer a funcionalidade das transações de indicação para revisão com base nos critérios estabelecidos pelo administrador do programa. O módulo pode conter uma lista de regras. Regras específicas podem ser escolhidas pelo usuário para inclusão em um processo específico. Cada usuário intitulado pode visualizar as regras com base em seu ponto específico na hierarquia. Cada regra pode ser configura- do para os atributos específicos do programa ou de acordo com a determi- nação do administrador do programa. O processo de módulo de filtro/regras pode ser iniciado pelo usuário de forma programada (por exemplo, diaria- mente, semanalmente, mensalmente, etc.) ou como necessário. O módulo de filtro/regras pode ser aplicado através de qualquer período agregado ou de histórico definido das transações por conta ou agência (por exemplo, vis- ta de uma regra aplicada às transações dentro de um único dia, semana, mês, ano, etc.) para compreender melhor o verdadeiro impacto comercial da regra. O módulo de filtro/regras também pode fornecer um retorno temporal sobre as transações, que pode permitir que uma agência inicie um processo de disputa dentro do período de disputa de 60 dias se desejar. O módulo pode integrar com o módulo de conformidade e auditoria 216.

O sistema de análise fornece uma interface de usuário, tal como

uma tela de exibição de critérios de regras, através da qual os usuários auto- rizados podem especificar o conjunto de regras a ser utilizado para proces- samento, além de criar as regras definidas por usuário. Adicionalmente, os usuários podem programar a execução das regras a serem aplicadas. Os usuários podem definir suas próprias regras pela especificação de um nome de campo, uma expressão de comparação, um valor de teste e um operando de união. Os nomes de campo se referem a transações financeiras, e inclu- em dados tal como: parâmetros de extrato de conta (data de fechamento, valor devido, último pagamento, valor em atraso, extrato anterior, e simila- res); tipo de conta de cartão; informação do detentor da conta (nome, ende- reço, limite de gastos); informação de transação (quantia a ser cobrança, categoria do comerciante, nome do comerciante, endereço, tipo de transa- ção). A expressão de comparação incluirá os operadores tal como igual, maior que, menor que e similares. O valor de teste será os valores particula- res para o teste de combinação pela regra, tal como "primeiro nome = Ro- bert" ou "último nome = Smith," onde o valor de teste seria "Robert" ou "Smi- th", respectivamente. Os valores de teste podem ser valores singulares, tal como "Smith" ou pode ser uma lista de valores, tal como "Smith, Smithy, Smithson." O operador de união será um operando para conectar as regras em uma regra composta, tal como o operador AND e o operador OR. Quan- do um usuário cria uma regra, o usuário pode dar um nome à regra, para uma especificação mais conveniente em outro momento. As regras podem ser programadas para serem executadas (rodadas) em momentos prede- terminados, tal como rodada uma vez imediatamente ou em um dia e hora particular, ou diariamente, semanalmente e mensalmente, de acordo com um dia e hora iniciais.

A saída de uma execução de filtro/regra compreenderá uma lista ou grupo de transações financeiras que são identificadas como combinando com a especificação da regra. O resultado pode ser salvado em um arquivo ou base de dados para exame posterior. Parte da execução de filtro/regra é a capacidade de indicar combinações identificadas (isso é, transações) para revisão adicional. Tal revisão adicional, por exemplo, pode ser realizada pelo módulo de conformidade/auditoria, ou pode ser realizada pela revisão de um usuário. O sistema de análise fornece uma interface de usuário (tela de exi- bição) que permite que os usuários revisem o resultado das regras e indi- quem transações particulares para revisão adicional. Em outro aspecto do sistema de análise, um gerente de progra-

ma pode criar uma regra e pode especificar um ambiente para testar a regra. Isto é, a especificação de regra e a característica de teste permitem que uma pessoa autorizada tal como um gerente de programa defina uma regra e crie um conjunto de dados de teste (ou designe uma cópia dos dados reais) que serão submetidos a processamento pela regra. O módulo pode coletar o re- sultado da operação da regra de teste de forma que a pessoa autorizada possa avaliar os resultados da aplicação da regra.

Operações ilustrativas associadas com esse módulo são listadas na Tabela 5 abaixo:

Tabela 5

Caso de utilização de módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira do portal;

2. Visualizar as conexões com os módulos intitulados;

3. Selecionar módulo de filtros/regras;

4. O usuário do administrador da agência pode selecionar qualquer uma das opções a seguir dentro do módulo de filtros/regras;

4. 1 Selecionar a ativação ou desativação de quaisquer filtros fornecidos por aplicativo;

4.2 Modificar a configuração para qualquer um dos filtros fornecidos por aplicativo;

4.3 Criar, editar e eliminar os filtros específicos de agência personalizados;

4.4 Rodar relatórios de situação de filtro para determinar o impacto das modificações de filtro nos resultados; 4.5 Selecionar a freqüência na qual se rodar as regras/alertas e gerar re- sultados (por exemplo, diariamente, semanalmente, mensalmente, etc.);

5. Usuário fecha o módulo._

A figura 3 ilustra um fluxograma que ilustra o processamento de filtro/regras para a especificação de usuário do processamento de regras. Na caixa de fluxograma de número 302, um usuário do sistema de análise de dados especifica um período de tempo de transação através do qual a regra deve ser aplicada. Isto é, o usuário registra uma faixa de data que especifica as datas das transações financeiras à qual a regra será aplicada. Dessa forma, a faixa de data registrada será aplicada ao campo de data de transa- ção da base de dados de transação. A segui, na caixa numerada 304, o u- suário registra um nível de hierarquia. Esse nível se refere a um nível de or- ganização. Por exemplo, a hierarquia pode ser utilizada para aplicar regras com base na entidade ou divisão corporativa, ou com base na situação de isento ou não isento de um detentor de cartão, ou com base nos níveis or- ganizacionais predeterminados que são uma função da implementação do sistema de análise em particular. Na caixa 306, os usuários indicam se estão criando uma nova regra. Se não estiverem, um resultado negativo surge na caixa 306, então podem selecionar uma regra existente, tal como através de uma caixa pendente ou listagem de regras, na caixa 308. Os usuários têm a oportunidade de modificar os parâmetros de regra padrão na caixa 310, e na caixa 312 os usuários podem especificar o aplicativo de filtros sobrepostos e combinações de regras utilizando operandos de união notados acima. Se um usuário desejar criar uma nova regra na caixa 306, um resultado afirmativo, então o usuário é levado para uma exibição da criação de filtro (caixa 314). Na caixa 316, o usuário é solicitado um nome de regra. Na caixa 318 o usuá- rio pode selecionar os campos desejados, na caixa 320 o usuário pode re- gistrar os critérios de seleção para transações que combinam com a regra (isso é, campo, expressão de comparação, combinações de valor de teste). O usuário salva a regra na caixa 322, para reutilização. O processamento então prossegue para a caixa 312 para especificar as combinações das re- gras, se desejado.

Na caixa 324, o usuário pode visualizar os resultados do aplica- tivo de regra. Isso fornece ao usuário uma oportunidade de modificar os pa- râmetros de filtro, se desejado (caixa 326). A modificação de filtro é iniciada por um retorno forçado (através do comando da interface de usuário) para o processamento da caixa 320. Se os resultados visualizados forem aceitos, o processamento move para a caixa 328, onde o usuário pode determinar a validade de cada transação que foi identificada como combinando com a regra. Na caixa 330, o usuário pode indicar as transações financeiras que serão enviadas para o módulo de auditoria e conformidade para processa- mento adicional. Na caixa 332, o usuário pode configurar a freqüência para rodar a regra, como notado acima. Módulo de Amostragem O módulo de amostragem 212 fornece aos usuários com a ca-

pacidade de amostrar de forma estatística suas transações com base nos planos de amostragem aceitos pela indústria. Os usuários podem personali- zar os parâmetros de plano de amostragem para ajustar o resultado de for- ma que a amostragem alinhe com os parâmetros de amostragem desejados pela agência e capacidades de recurso. O módulo de amostragem opera em transações que já foram autorizadas pelo sistema de processamento 106 (figura 1) para identificar as transações que são submetidas a processamen- to adicional, tal como verificação de violações de regras comerciais, que a transação pode não ter recebido. Dessa forma, o módulo de amostragem fornece uma agência com a capacidade de utilizar uma melhor prática de auditoria de contabilidade pela revisão estatística de uma parte de uma po- pulação de transação e determinar a probabilidade de uma ocorrência inde- sejável que possa indicar uma atividade em não conformidade. Esse proces- so de amostragem, no entanto, não garante que a agência de um nível acei- tável de qualidade de dados sendo transmitida e recebida dos comerciantes e processadores. O nível de qualidade de dados que entra no aplicativo de- pende de que detalhes são transmitidos a partir do comerciante e do proces- sador no sistema de pagamento 106 para o sistema de analise 108.

O módulo de amostragem pode fornecer um processo chamado "aceitação de amostragem". A aceitação da amostragem é um procedimento utilizado para a determinação de se bateladas ou grupos de entrada das transações devem ser aceitos ou rejeitados. Cada agência pode definir de- feitos menores, maiores e críticos de acordo com esse nível de tolerância. Muitas organizações utilizam tabelas de padrões militares para desenvolver critérios de aceitação e rejeição. As tabelas desenvolvidas para os níveis de aceitação e rejeição fornecerão planos de inspeção para amostragem pelos atributos para um tamanho de batelada determinado e nível de qualidade aceitável (AQL). Um plano de inspeção inclui: tamanho da amostragem (n), valores de aceitação (c), e valores de rejeição (r).

O padrão de amostragem inclui três tipos de inspeção (normal, justo e reduzido). O tipo de inspeção a ser aplicado depende tipicamente da qualidade do último grupo de transações inspecionado. No começo da ins- peção, sem qualquer histórico anterior, a inspeção normal é utilizada. A ins- peção justa (para um histórico de transações de baixa qualidade) pode exigir um tamanho de amostra maior do que a inspeção normal. A amostragem reduzida (para um histórico de alta qualidade) possui um número maior de aceitação com relação à inspeção normal (logo é mais fácil de aceitar a ba- telada ou grupo de transações). Existem tipicamente regras de comutação especiais entre os três tipos de inspeção, além de uma regra para desconti- nuar a inspeção. Um tipo de paradigma de amostragem que pode ser utiliza- do é especificado pelos padrões militares do governo dos Estados Unidos, referido como MIL-STD 105E e MIL-STD 1916, que serão conhecidos dos versados na técnica.

O módulo de amostragem pode fornecer a funcionalidade de seleção de transações a partir de um conjunto de dados de ciclo depois que os filtros/regras foram aplicados. O módulo pode receber registros com os quais o usuário pode selecionar/registrar o nível de confiança desejado e selecionar/registrar o plano de amostragem. O usuário do módulo pode defi- nir os defeitos menores, maiores e críticos. O plano de amostragem pode selecionar a partir de toda a população de transações autorizadas, ou pode ser configurado para selecionar apenas a partir das transações passadas (isso é, transações que foram aprovadas pelo processamento de fil- tros/regra). O processo de módulo de amostragem pode ser iniciado pelo usuário de forma programada (por exemplo, diariamente, semanalmente, mensalmente, etc.) ou como necessário.

O plano de amostragem pode ser aplicado através de qualquer período de transações de histórico ou agregado definido pelo usuário por conta ou agência (por exemplo, visualização dos parâmetros de amostragem aplicados às transações dentro de um único dia, semana, mês, ano, etc.). O módulo de amostragem também pode fornecer um retorno temporal das transações, que permitirá que uma agência inicie um processo de disputa dentro de um período de disputa de 60 dias, se desejado. O módulo também pode selecionar de forma aleatória o número especificado pelo usuário de transações para evitar subjetividade.

Os desenhos de plano de amostragem ilustrativos que podem ser recebidos da especificação de usuário através da interface de sistema de análise são ilustrados na figura 7. As tabelas 700 ilustradas na figura 7 são exemplos de exibições em tela dos registros de usuário no sistema de análi- se 108 (figura 1) através do qual um usuário registra dados para definir um plano de amostragem para execução de acordo com a invenção. A exibição de tabela mais superior 702 ilustra parâmetros para inspeção normal, inspe- ção rígida e inspeção reduzida. As três próximas tabelas 704, 706 e 708 ilus- tram o registro de usuário para especificação dos níveis aceitáveis de quali- dade.

As operações ilustrativas associadas com esse módulo são lis- tadas na Tabela 6 abaixo:

Tabela 6

Caso de Uso de Módulo: 1. Conectar-se ao aplicativo através da extremidade dianteira do portal.

2. Visualizar links para os módulos intitulados.

3. Selecionar módulo de amostragem. 4. O usuário administrador da agência pode selecionar qualquer uma das seguintes opções dento do módulo de amostragem.

4.1 Registrar as especificações de plano de amostragem desejadas. Al- guns planos de amostra padrão serão fornecidos como uma opção su-

gerida.

4.2 Configurar ou modificar o nível de qualidade aceitável (AQL).

4.3 Configurar o nível de confiança.

4.4 Selecionar a duração de tempo para amostragem registrando uma faixa de data.

4.5 Selecionar o número de transações a serem amostradas depois da a- plicação do plano de amostragem.

4.6 Estabelecer critérios de aceitação/rejeição de transação em AQL sob inspeção normal, reduzida e rígida.

4.7 Definir os defeitos menores, maiores e críticos para a agência. 4.8 Rodar o plano de amostragem e visualizar os resultados.

5. O usuário fecha o módulo._

A figura 4 ilustra um fluxograma que ilustra o processamento de amostragem do sistema de análise de dados e especificação de usuário da operação de amostragem. Na caixa 402, um usuário registra uma faixa de dados para aplicação do plano de amostragem. Na caixa 404, como com o módulo de filtro/regras, o usuário registra a seguir um nível de hierarquia para o processamento. O usuário registra a seguir um tamanho de lote de transação na caixa 406 (para os valores ilustrativos, vide figura 7). A seguir, na caixa 408, se o usuário não desejar utilizar o plano de amostragem sal- vado, um resultado negativo, então na caixa 410 o usuário cria um novo pla- no de amostragem. Se o usuário desejar utilizar um plano salvado, um resul- tado afirmativo na caixa 408, então o usuário selecionar um plano de amos- tragem e na caixa 412 o usuário especifica um AQL para o plano. Na caixa 414, o usuário configura o nível de confiança. Na caixa 416, o usuário de- termina o tipo de plano de inspeção a ser utilizado. Por exemplo, o usuário pode selecionar entre inspeção normal, rígida ou reduzida. Na caixa 418, o usuário determina o tamanho da amostra a ser utilizada, de acordo com as tabelas de plano de amostra. Na caixa 420, o usuário determina o número do tamanho de amostra pela seleção do número de transações a serem a- mostradas depois da aplicação do plano de amostragem. A seguir, na caixa 422, o usuário inicia o processamento de amostra. Na caixa 424, o usuário recebe os resultados de amostragens e revisa os mesmos. O usuário então especifica quando um resultado é menor (caixa 426, 428) e prossegue para a próxima transação (caixa 430), e continua a especificar se o resultado é maior (caixa 432, 434) ou crítica (caixa 436, 438). Na última transação, caixa 440, o processamento de amostragem é completado quando a última amos- tra foi processada. Módulo de Predição

O módulo de predição pode fornecer aos usuários a capacidade de identificar dinamicamente as transações que apresentam as áreas mais novas de risco e vulnerabilidade para as operações de programa. O módulo de predição opera nas transações á autorizadas que foram aprovadas pelo sistema de processamento 106 (figura 1) para identificar as transações que possuem características que indicam uma transação provavelmente em não conformidade. Existe algum grau de cooperação entre os módulos, visto que o módulo de regras 210 identifica as transações como transações "rotula- das" que compreendem uma violação das regras e, portanto, exigem verifi- cação adicional para saber se possivelmente estão em não conformidade, e de forma que as transações sinalizadas possam ser verificadas pelo módulo de conformidade 216. O módulo de amostragem 212 determina as transa- ções que, de outra forma, não possuem as características que indicariam uma transação em não conformidade, mas são selecionadas para verifica- ção adicional não obstante, de acordo com um paradigma de amostragem, de forma que as transações determinadas também sejam verificadas adicio- nalmente pelo módulo de conformidade 216 por quaisquer características que possam indicar uma transação em não conformidade. O módulo de pre- dição 214 examina as transações já autorizadas que não possuem violação conhecidas das regulamentações de programa (um exemplo de uma transa- ção passada) para determinar se a transação apresenta características que indiquem o comportamento de evitar regulamentações em potencial. As transações identificadas podem ser verificadas pelo módulo de conformidade 216 para identificar quaisquer violações reais e atividade de não conformi- dade.

O módulo de predição 214 pode fornecer à agência uma varie-

dade de métodos para uso na seleção de transações em risco para revisão adicional. Por exemplo, os métodos podem compreender a análise de re- gressão, análise de redes neurais, e algoritmos genéticos. Cada método for- necerá uma abordagem singular e avançada para a seleção de transações para revisão. Uma descrição ilustrativa de cada implementação em potencial é fornecida abaixo.

Análise de Regressão. O aplicativo utilizará a análise para medir a relação dos elementos de dados associados com um conjunto de transa- ção. Quando um outlier é detectado, a transação será rotulado para revisão adicional. O usuário pode ajustar a sensibilidade do processo de forma que alinhe com os níveis de tolerância da agência e capacidades de recurso.

Redes Neurais. Uma rede neural modela o grau da interconexão e a interação adaptativa entre os elementos de dados associados com uma transação de cartão. As redes neurais são capazes de revisar as transações de cartão de forma similar à abordagem utilizada por uma mente humana. Existem vários tipos diferentes de redes neurais que podem ser incorpora- das ao aplicativo. Perceptrons simples, propagação retroativa, e redes com base radial podem ser utilizadas. Depois do treinamento suficiente ter ocorri- do, as redes podem ser adaptadas de maneira pura aos registros de transa- ção.

Algoritmos Genéticos. O aplicativo pode utilizar os algoritmos genéticos para revisar a população de transação e apresentar as transações para consideração para revisão adicional. A evolução do algoritmo genético começa no conjunto de transação e analisa o encaixe de cada transação no algoritmo. A seguir, pode rodar situações diferentes ou combinadas para formar novas populações para determinar se quaisquer anomalias existem no conjunto de transação. Novamente, com base nas configurações de tole- rância de usuário, o algoritmo genético pode apresentar as transações para consideração.

O módulo de predição 214 pode ser utilizado com o módulo de filtro/regras 210 e o módulo de amostragem 212. Enquanto o módulo de fil- tro/regras 210 seleciona as transações com critérios conhecidos e o módulo de amostragem 212 fornece alguma confiança de que um conjunto de tran- sações contém transações aceitáveis, o módulo de predição 214 pode anali- sar ativamente e apresentar as transações possuindo padrões novos que podem ser suspeitos. Uma vez que uma transação é selecionada pelo módulo de pre-

dição 214, a mesma pode ser transferida para o módulo de conformidade e auditoria 216 (se esse módulo estiver sendo utilizado). O módulo de predi- ção 214 é projetado para interfacear completamente com o módulo de con- formidade e auditoria 216. No módulo de conformidade e auditoria 216, a informação associada será utilizada para estabelecer um caso que facilitará o rastreamento e gerenciamento de revisão adicional da transação.

O módulo de predição 214 utiliza um modelo de aprendizado que analisa e rotula as transações novas para revisão adicional. Geralmente, o módulo de predição 214 pode ser utilizado depois da aplicação de regras de comercialização e abordagens de amostragem estatisticamente válidas. O módulo pode utilizar uma variedade de técnicas para determinar as tran- sações que são determinadas como sendo merecedoras de análise adicio- nal. Como notado, essas técnicas podem incluir regressão linear, redes neu- rais, e algoritmos genéticos. O processo de módulo de predição pode geral- mente ser iniciado pelo usuário de forma programada (por exemplo, diaria- mente, semanalmente, mensalmente, etc.) ou como necessário. O processo de módulo de predição pode ser aplicado através de qualquer período de transação agregado ou de histórico especificado por usuário pela conta ou agência (por exemplo, visualizar uma faixa de predição aplicada à transação dentro de um único dia, semana, mês, ano, etc.) O módulo de predição tam- bém pode fornecer um retorno temporal sobre as transações que permitirão que uma agência inicie o processo de disputa dentro de um período de dis- puta de 60 dias, e pode fornecer resultados de forma que o gerenciamento de programa possa revisar as transações selecionadas e determinar se são válidas.

As operações ilustrativas associadas com esse módulo são Iis- tadas na tabela 7 abaixo:

Tabela 7 Caso de Utilização de Módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira do portal.

2. Visualizar os links para os módulos intitulados. 3. Selecionar o módulo de predição.

4. O usuário administrador de agência pode selecionar qualquer uma das seguintes opções dento do módulo de predição.

4.1 Selecionar o módulo de aprendizado para transações de per- fil/agrupamento.

4.2 Modificar as configurações para cada método oferecido.

4.3 Rodar e visualizar os resultados/impacto do método selecionado.

5. O usuário fecha o módulo.__

A figura 5 ilustra a seqüência geral de processamento para o módulo de predição. Inicialmente, na caixa 502, o usuário seleciona uma faixa de dados para verificação das violações de filtro/regras contra as tran- sações financeiras. Na caixa 504, o usuário seleciona um previsor, ou cria um novo previsor, como notado acima, para incorporar a análise de regres- são linear 505a, análise de rede neural 505b, ou análise de algoritmo genéti- co 505c. O processo de predição é então executado pelo sistema de análise na caixa 506 para identificar as transações com características que indicam a atividade de não conformidade potencial, tal como o comportamento que evita as regras aparentes. Na caixa 508, os resultados são visualizados pelo usuário para determinar a validade de cada transação identificada. Se o u- suário confirmar a validade questionável na caixa 510, então a transação é fornecida para o módulo de conformidade e auditoria na caixa 512 para pro- cessamento adicional. O usuário pode fornecer um retorno referente à técni- ca de análise que foi utilizada, para melhorias futuras ou seleção de técnicas alternativas (caixa 514). Por fim, na caixa 516, o usuário pode selecionar uma freqüência de funcionamento para o processo de módulo de predição e determinar notificações de alerta. Módulo de Conformidade e Auditoria O módulo de conformidade e auditoria 216 pode fornecer aos

usuários a capacidade de gerenciar sua carga de transações sinalizadas. Esse módulo pode ajudar a automatizar o processo de seleção, revisão e documentação do processo de auditoria em torno das transações sinaliza- das. O módulo de conformidade e auditoria pode auxiliar e fornecer orienta- ção na implementação dos controles adequados para garantir a conformida- de às regras da agência, tal como as leis Federais, as regulamentações Fe- derais e da agência, e para monitorar a eficiência do programa. Uma das tarefas mais demoradas para um programa de cartão é a pesquisa que é realizada para garantir que quaisquer políticas de gerenciamento de risco e práticas estabelecidas no plano de gerenciamento de carga de cobrança da agência sejam realizadas de forma eficiente. Por exemplo, o Departamento de Defesa dos Estados Unidos ("DoD") está buscando especificamente um processo automatizado para cada nível de programa participante da revisão das transações selecionadas e documentam sua justificativa e retorno para revisão da auditoria. A integração do módulo de conformidade e auditoria com o módulo de filtro/regras, módulo de amostragem, e módulo de predição permitirá que cada agência sejam mais eficiente com seu processo de revi- são. A circular A-125 OMB e DoD fornecem exigências em torno da confor- midade de política e auditoria de transação. O módulo de conformidade e auditoria fornece a integração total

com o módulo de filtros/regras, módulo de amostragem, e módulo de predi- ção. O módulo de conformidade e auditoria pode ser utilizado pelos detento- res de cartão, escritório de gerenciamento de programa e aprovação, se au- torizado. O módulo também pode fornecer capacidades de gerenciamento de caso e permite que as transações selecionadas sejam direcionadas para os usuários adequados para revisão. Também pode apresenta várias ques- tões solicitando o registro do usuário para determinar a validade da transa- ção e pode fornecer o rastreamento completo do caso para manutenção de uma variedade extensa da informação associada com um caso (transação sinalizada).

Operações ilustrativas que podem ser utilizadas por esse módu- Io são listadas na Tabela 8 abaixo:

Tabela 8 Caso de Utilização de Módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira do porta.

2. Visualizar as conexões com os módulos intitulados. 3. Selecionar o módulo de conformidade e auditoria.

4. O usuário administrador da agência pode selecionar qualquer uma das seguintes opções dentro do módulo de conformidade e auditoria.

4.1 Criar, atualizar e visualizar um caso.

4.2 Revisar os resultados de transação rotulados do módulo de fil- tros/regras, módulo de amostragem e módulo de predição.

5. O usuário fecha o módulo._

A figura 6 ilustra a seqüência geral de processamento para a operação do módulo de conformidade e auditoria. Inicialmente, na caixa 602, o usuário visualizará uma transação que foi recebida no módulo de confor- midade e auditoria. Cada transação recebida no módulo de conformidade e auditoria é recebida decorrente de uma decisão de processamento no módu- lo de filtro/regras 604, ou no módulo de amostragem 606, ou no módulo de predição 608. Isso é, o módulo de conformidade e auditoria recebe as tran- sações sinalizadas para revisão adicional. Cada transação recebida pelo módulo de conformidade e auditoria será tipicamente associado com uma questão ou problema de revisão ou outra característica que terá sido anota- da pelo módulo de referência. Na caixa 610, o processamento do módulo aceita ou rejeita a transação recebida para revisão adicional. Uma transação rejeitada é uma transação que foi determinada pelo usuário para não exigir revisão adicional, e o processamento dessa transação no módulo de con- formidade e auditoria é completado depois da rejeição. Para cada transação aceita, na caixa 612, um elemento de caso é criado. Notas para revisão po- dem ser adicionadas na caixa 614. O caso é ativado na caixa 616 para inici- ar o processo de revisão. A decisão de ativação pode ser realizada, por e- xemplo, por um revisor inicial ou pelo mesmo usuário que tomou a decisão de aceitação.

Depois da ativação do caso, uma série de operações de proces-

samento pode ser realizada, incluindo a revisão das questões relacionadas com o caso aceito e a revisão da situação do caso. Em geral, tal revisão en- volve determinações subjetivas por parte dos revisores autorizados. Na cai- xa 620, um revisor verifica as questões de revisão tal como as questões ou problemas que resultaram na referência ao módulo de conformidade e audi- toria. Na caixa 622, o revisor está livre para adicionar, editar ou eliminar questões de revisão e na caixa 624 as questões de revisão são verificadas e então na caixa 626 as questões de revisão para o caso são ativadas para processamento adicional por outra pessoa. Alternativamente, se nenhuma questão permanecer depois da revisão adicional em 626, um revisor autori- zado pode encerrar o processamento.

O processamento adicional pode incluir a revisão por uma pes- soa designada que verifica a situação do caso para processamento (caixa 630). O revisor então verifica as respostas das questões anteriores ou inicia- tivas e fornece retorno (632), aceita ou rejeita a revisão adicional (634), e pode solicitar informação adicional para mais revisão, ou tomar uma ação tal como desativar a transação ou sugerir mudanças no procedimento de tran- sação, ou encerrar a revisão do caso (caixa 636). Módulo de Otimização O módulo de otimização 218 fornece aos usuários a capacidade

de realizar uma revisão de otimização de programa. Essa revisão pode for- necer uma unidade de agência de cartão, tal como um Escritório de Geren- ciamento de Programa, com uma visão geral de seu programa em compara- ção com as métricas operacionais chave padrão da indústria. O processo de otimização através do módulo de otimização é projetado para avaliar as prá- ticas existentes do programa de cartão da agência, identificar alvos de opor- tunidade para alavancagem das eficiências do programa de cartão, e ofere- cer sugestões para reforçar os controles e obter melhores processo e proce- dimentos práticos. Esse processo pode utilizar um sistema especialista para analisar os dados de transação de cartão para identificar áreas em potencial de oportunidade para o aumento do volume de transação de cartão.

Alguns dos resultados do processo de otimização devem com-

preender os padrões de gasto de agência e identificar os alvos de expansão de cartão de compra. O processo é focado na identificação de oportunidades de economia de curto prazo (1 a 3 meses) e prazo mais longo (+ de 3 me- ses) específicas para a agência de cartão. Alguns pontos de retorno especí- ficos do programa podem incluir, mas não estão limitados a, gasto total e conta das transações pelo método de pagamento, maiores fornecedores por gasto, conta de transações e método de pagamento, total gasto, conta de transações e método de pagamento por unidade comercial e oportunidades de programa de cartão por transação e gasto baseado na aceitação do e- missor dentre os fornecedores. O processo de otimização geral pode ser utilizado para quantificar os benefícios (por exemplo, economia de custo de processo, rebates, etc.) associados com a movimentação das transações de cheques e ordens de compra em papel para cartões de compra.

O módulo de otimização fornece análise de programa de carta com base nos registros de usuário. O módulo também pode suportar o ras- treamento de métricas chave de programa igual (por exemplo, programas de gasto similares, conta de empregado, orçamento de operação total, etc.) e atualização dos dados de benchmark à medida que o programa completa os esforços de otimização. O módulo pode ser utilizado para identificar as vul- nerabilidades do programa e as oportunidades de crescimento para o geren- ciamento de risco podem ser utilizadas para revisar os dados de pagamento de contas que não são de folha de pagamento para fornecer uma lista espe- cífica das oportunidades de expansão, avaliar o desempenho do cartão para marcar o programa de carta em comparação com os programas similares de melhor prática, e identificar as melhores práticas para revelar as oportunida- des para melhorar o desempenho do programa de cartão.

Operações ilustrativas associadas com esse módulo são listadas na Tabela 9 abaixo:

Tabela 9 Caso de Utilização de Módulo: 1. Conectar-se ao aplicativo através da extremidade dianteira do porta. 2. Visualizar as conexões com módulos intitulados.

3. Selecionar módulo de otimização.

4. Usuário administrador de agência pode selecionar qualquer uma das seguintes opções dentro do módulo de otimização.

4.1 Rodar e visualizar os resultados de uma análise de pagamento de con- tas que não de folha de pagamento.

4.2 Rodar e visualizar os resultados de uma análise de programa de car- tão.

4.3 Revisar um "cartão de relatório" de melhores práticas específicas de agência que fornece sugestões para melhorar o programa.

5. O usuário fecha o módulo._

Módulo de Fonte Estratégica

O módulo de fonte estratégica 220 fornecerá programas de car- tão com a capacidade de revisar os padrões de gasto da organização. Pela compreensão dos padrões de gasto, uma organização pode utilizar melhor seu poder de compra para alavancar um melhor preço com vendedores ata- cadistas. Por exemplo, o governo federal Norte Americano gasta bilhões de dólares em bens e serviços a cada ano, e as agências federais são respon- sáveis pela maximização do valor de cada dólar gasto. Portanto, as agências precisam alavancar o gasto ao máximo possível através de fontes estratégi- cas. A fonte estratégica é o processo de colaboração e estruturação de aná- lise crítica dos gastos de uma organização e utilização dessa informação para tomar decisões comerciais sobre a aquisição de commodities e servi- ços de forma mais eficiente. Esse processo ajuda as agências a otimizarem o desempenho, minimizarem o preço, aumentarem a obtenção de objetivos socioeconômicos, avaliar os custos de gerenciamento no ciclo útil total, aper- feiçoar o acesso do vendedor a oportunidades de negócios e aumentar o valor de cada dólar gasto. Os gerenciadores de programa de cartão de compra podem de- sempenhar melhor sua função de gerenciamento se estiverem cientes de qualquer contrato da agência ou múltiplas agências que possa resultar em uma melhor cotação de preço e garantir que os detentores de cartão estejam cientes das políticas de agência para utilização desses contratos. Por exem- plo, as agências podem minimizar o número de pequenos pedidos de contra- tos programados e considerar uma abordagem mais estratégica para a com- pra de determinados bens. Com relação aos programas do governo, o coor- denador do programa pode revisar os dados de gasto do cartão de compra e pode fazer recomendações para o Oficial de Aquisição para aperfeiçoar o processo de compra e aumentar a economia com base no volume. Esse módulo facilitará as tarefas necessárias por cada no preenchimento de suas responsabilidades de fonte estratégica descritas.

O módulo de fonte estratégica fornece funcionalidade incluindo a capacidade de um usuário em carregar um arquivo de dados com transa- ções pagáveis em conta e fornece uma análise dos pagamentos em conta. O módulo fornece as capacidades de fonte estratégica através de relatórios agrupados pela unidade comercial, comerciante, produto, e similares. O mó- dulo é capaz de corresponder ou exceder as exigências mínimas de fonte Federais. O módulo pode permitir a integração das bases de dados, tal como as bases de dados de perfil de comerciante, para análise das transações financeiras. O módulo também pode distribuir uma análise de gastos deta- lhada, incluindo dados de contrato, dados de pedido de entrega e dados de cartão de compra. Adicionalmente, o módulo pode integrar dados socioeco- nômicos para análise dos objetivos da agência e objetivos priorizados, tal como informação demográfica. Também fornece medidas de desempenho para determinar o progresso no sentido de se alcançar os objetivos de fonte estratégica da agência. A funcionalidade do módulo também permite se sal- var os resultados da análise da agência para serem utilizados como um pon- to de comparação para análise futura.

As operações ilustrativas associadas com esse módulo são lis- tadas na Tabela 10 abaixo: Tabela 10 Caso de Utilização de Módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira do portal.

2. Visualizar os links para módulos intitulados.

3. Selecionar o módulo de fonte estratégica.

4. O usuário administrador de agência pode selecionar qualquer uma das seguintes opções dento do módulo de fonte estratégica.

4.1 Selecionar os dados de não folha de pagamento pagáveis na conta para uso na análise.

4.2 Selecionar os dados de programa de cartão par auso na análise.

4.3 Criar, editar e salvar um arquivo de dados que pode ser submetido a processamento. Esse arquivo pode ser submetido a uma agência de cartão para processamento utilizando uma base de dados de perfil de comerciante ou pode ser utilizado por um provedor de terceiras partes

para fornecer dados socioeconômicos sobre os fornecedores.

4.4 Rodar uma análise de gastos utilizando os dados disponíveis de aplica- tivo.

4.5 Criar uma lista de métricas de desempenho chave da agência com al- vos/objetivos associados

4.6 Rodar e visualizar o relatório de medição de desempenho chave da agência.

5. O usuário fecha o módulo._

Módulo de Gerenciamento de Programa

O módulo de gerenciamento de programa pode fornecer ao usu-

ário a capacidade de revisa, reconcilia, designar fundos, e aprovar transa- ções para o sistema financeiro local. Esse módulo também pode ser utilizado para apresentar as declarações eletrônicas para os detentores de cartão em um esforço de facilitar a distribuição temporal. Utilizando o módulo, a agên- cia de cartão pode identificar e designar os papéis e responsabilidades para

cada um dos oficiais de gerenciamento chave da agência. Esses oficiais in- cluirão provavelmente, mas não estão limitados a, pessoas da Coordenação de Programa da Organização/Agência (A/OPC), oficiais de aprovação ou outros oficiais equivalentes, e outros oficieis de contabilidade/cobrança. Esse módulo também pode ser utilizado para auxiliar no escritório de gerencia- mento de programa facilitando o processo de fluxo de trabalho para o esta- belecimento de um processo para a indicação formal de detentores de car- tão e oficiais de aprovação. Um usuário também pode ter a capacidade de estabelecer os controles de autorização adequados para cada conta dentro do programa. Por exemplo, os limites de transação, limites de ciclo, limite de velocidade e restrições de código de categoria de comerciante. Outra carac- terística desse módulo que pode ser útil para o escritório de gerenciamento de programa é o processo de recuperação dos cartões e outra documenta- ção quando os empregados rescindem o contrato, e no caso no qual o em- pregado muda para uma organização diferente.

O módulo pode fornecer a funcionalidade de gerenciamento de conta, tal como fornecendo aos administradores do programa de cartão a capacidade de realizar a manutenção da conta de cartão, criar e gerenciar as contas de cartão comercial, e responder às necessidades do detentor de cartão em tempo real. O módulo de gerenciamento de programa também fornece funcionalidade de gerenciamento de transação, fornecendo aos de- tentores de cartão, aprovadores, e administradores de programa a visualiza- ção da transação, capacidade de dividir custos, realizar a edição de aloca- ção de transação, adicionar detalhes à transação (equivalente à informação de nível III), realizar fluxo de trabalho de aprovação, registrar despesas dire- tas, e anexar recibos digitalizados aos registros. O módulo também fornece a funcionalidade de gerenciamento de extrato, permitindo que os detentores de cartão, seus gerentes e administradores de programa recebam e visuali- zem as declarações. Os sumários de conta e atividade postados desde o ciclo de extrato mais recente são exibidos em tempo real, de forma que os usuários saibam exatamente o que foi gasto diariamente.

As operações ilustrativas que são associadas com esse módulo são mencionadas na Tabela 11 abaixo: Tabela 11

Caso de Utilização de Módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira de portal.

2. Visualizar conexões aos módulos intitulados.

3. Selecionar o módulo de gerenciamento de programa.

4. O usuário administrador de agência pode selecionar qualquer uma das opções a seguir dento do módulo de gerenciamento de programa.

4.1 Configurar novos detentores de cartão.

4.2 Realizar a manutenção da conta do cartão. 4.3 Realizar a manutenção das contas.

4.4 Visualizar, editar, alocar e aprovar transações.

4.5 Estabelecer o fluxo de trabalho de aprovação de transação.

4.6 Visualizar e aprovar um extrato

4.7 Marcar uma transação como incluída em um relatório de disputa (Para rastreamento no aplicativo e é um processo manual para a marcação e

eliminação da marca). (Isso é feito para iniciar o processo de disputa real como definido pelo provedor do cartão).

5. O usuário fecha o módulo._

Módulo de Treinamento

O módulo de treinamento fornece o treinamento de todos os as-

pectos do programa de cartão sob o qual o sistema de análise é utilizado. O módulo é projetado para facilitar o desenvolvimento, distribuição, teste e cer- tificação dos participantes do programa de cartão. Por exemplo, o módulo de treinamento é destinado a ajudar a se corresponder à Circular OMB A-123 destacada, Anexo B das exigências de treinamento para um programa de cartão de setor público. Apesar de o aplicativo poder não fornecer todo o escopo do processo de treinamento, o aplicativo ainda pode servir como um centro de rastreamento e reporte das exigências de treinamento e histórico de cada participante. Algumas das situações de treinamento prováveis para o módulo

incluem o treinamento para os detentores de cartão de compra sobre como se utilizar um cartão de compra. Por exemplo, para participantes federais, existem leis de aquisição e regulamentações, políticas da agência, e uso adequado do cartão com os quais os usuários devem estar em conformida- de. As exigências de treinamento devem ser consistentes com o nível de responsabilidade ou autoridade de gasto que o detentor de cartão pode ter. O módulo de treinamento fornece a funcionalidade de forneci-

mento de gerenciamento de documento para o material de treinamento, for- necendo a capacidade de apresentar material de treinamento on-line com teste, capacidades de áudio e vídeo, e rastreando o progresso do treinamen- to do usuário e certificação em comparação com as exigências do programa para treinamento de novo detentor de cartão e treinamento de atualização de detentor de cartão. O módulo pode ser utilizado também para fornecer aos usuários características e funcionalidade de ajuda de referência e tópi- cos especificados pelo aplicativo.

As operações ilustrativas associadas com esse módulo são Iis- tadas na Tabela 12 abaixo.

Tabela 12

Caso de Utilização de Módulo:

1. Conectar-se ao aplicativo através da extremidade dianteira do portal.

2. Visualizar a conexão com os módulos intitulados. 3. Selecionar o módulo de treinamento.

4. O usuário administrador de agência pode selecionar qualquer uma

das opções a seguir dentro do módulo de treinamento. 4.1. Criar o material de treinamento tipo de deslizamento distribuído atra- vés da rede.

4.2. Anexar um arquivo de áudio ou vídeo para suplementar o material de treinamento tipo deslizante.

4.3. Projetar e desenvolver questões de teste e a marcação associada para os participantes do programa.

4.4. Distribuir um certificado de treinamento para o usuário depois da fina- lização bem sucedida do teste.

4.5. Rodar relatórios sobre os participantes do programa e seu progresso de treinamento para novos detentores de cartão e participantes atuais do programa.

4.5.1. Situações e marcações de teste de histórico para treinamento novo ou de atualização;

4.5.2. Data da última certificação;

4.6. buscar os arquivos de ajuda do aplicativo

4.6.1. Funcionalidade de contexto

4.6.2. Funcionalidade de índice

4.6.3. Funcionalidade de busca

5. O usuário fecha o módulo._

Nas modalidades da invenção, um "computador servidor" pode

ser utilizado em um ou mais dos componentes ilustrados na figura 1. Um "computador servidor" pode incluir um computador poderoso ou agrupamen- to de computadores que se comporta como um único computador que serve as solicitações de um ou mais computadores de cliente. O computador ser- vidor pode ser um computador principal, um minicomputador, ou um agru- pamento de minicomputadores. Por exemplo, o computador servidor pode incluir um ou mais servidores de base de dados e um ou mais servidores de Rede.

Deve-se compreender que a presente invenção como descrita acima pode ser implementada na forma de lógica de controle utilizando soft- ware de computador de forma modular ou integrada. Com base na descrição e nos ensinamentos fornecidos aqui, os versados na técnica saberão e a- preciarão outras formas e/ou métodos de se implementar a presente inven- ção utilizando hardware e uma combinação de hardware e software. Qualquer um dos componentes de software, módulos, ou fun-

ções descritos nesse pedido podem ser implementados como código de software a ser executado por um processador de computador utilizando qualquer linguagem de computador adequada tal como, por exemplo, Java, C++, Basic Visual ou Perl utilizando, por exemplo, técnicas convencionais ou orientadas por objeto. O código de software pode ser armazenado como uma série de instruções, ou comandos em um meio legível por computador, tal como uma memória de acesso randômico (RAM), uma memória de leitura apenas (ROM), um meio magnético tal como um disco rígido ou um disco flexível, ou um meio ótico tal como um CD-ROM. Qualquer meio legível por computador pode residir em ou dentro de um único aparelho de computação, e pode estar presente em ou dentro de diferentes aparelhos de computação dentro de um sistema ou rede.

A descrição acima é ilustrativa e não restritiva. Muitas variações da invenção serão aparentes aos versados na técnica mediante revisão da descrição. O escopo da invenção deve, portanto, ser determinado não com referência à descrição acima, mas ao invés disso, deve ser determinado com referência às referências em anexo juntamente com seu escopo total e equi- valências.

Enquanto determinadas modalidades ilustrativas foram descritas em detalhes e ilustradas nos desenhos em anexo, deve-se compreender que tais modalidades são meramente ilustrativas e não devem ser restritivas da invenção ampla, e que essa invenção não está limitada às disposições es- pecíficas e construções ilustradas e descritas, visto que várias outras confi- gurações podem ocorrer aos versados na técnica.

A menção de "um", "uma" ou "a", "o" deve significar "um ou mais" a menos que especificamente indicado o contrário.

Claims (37)

1. Método para processar dados de transação financeira de um programa de pagamento, o método compreendendo: receber os dados relacionados a um conjunto de transações fi- nanceiras que foram autorizadas por um sistema de processamento de pa- gamento; determinar se uma ou várias das transações financeiras autori- zadas serão submetidas a uma transformação adicional, em que a transfor- mação adicional opera sobre os dados recebidos e identifica as transações financeiras autorizadas que podem compreender o emprego errado ou o a- buso do programa de pagamento ou podem estar fora de conformidade com o regulamento de transação do programa de pagamento.

2. Método, de acordo com a reivindicação 1, em que o proces- samento adicional compreende o processamento dos dados recebidos com um conjunto de regras predeterminadas de negócio e a identificação das transações financeiras como uma transação passada que esteja em confor- midade com as regras de negócio ou como uma transação sinalizada que deva ser verificada para ver se há a violação de uma ou várias das regras de negócio.

3. Método, de acordo com a reivindicação 2, em que o proces- samento adicional compreende a execução de amostragem em transações passadas para designar uma ou várias das transações passadas como as transações sinalizadas a serem verificadas para ver se há a violação de uma ou várias das regras de negócio.

4. Método, de acordo com a reivindicação 3, em que a amostra- gem compreende a amostragem de aceitação de acordo com os parâmetros que especificam um plano de inspeção.

5. Método, de acordo com a reivindicação 4, em que o plano de inspeção é especificado por uma entidade outra que não uma entidade de emissão que emite dispositivos portáteis de consumidor em conexão com o programa de pagamento.

6. Método, de acordo com a reivindicação 2, em que o proces- samento adicional compreende a execução de processamento de predição nas transações passadas para identificar as características da transação que compreendem o comportamento de anulação que indica uma transação de provável não conformidade.

7. Método, de acordo com a reivindicação 6, em que o proces- samento de predição utiliza a análise de regressão.

8. Método, de acordo com a reivindicação 6, em que o proces- samento de predição utiliza a análise de rede neural.

9. Método, de acordo com a reivindicação 6, em que o proces- samento de predição utiliza a análise genética de algoritmo.

10. Método, de acordo com a reivindicação 2, o método adicio- nalmente incluindo: receber a entrada do usuário via uma rede; determinar se o usuário está autorizado; e ajustar a operação de transformação adicional de acordo com a entrada do usuário.

11. Método, de acordo com a reivindicação 10, em que ajustar a operação compreende a mudar o processamento de transações passadas.

12. Sistema, para processar dados de transações financeiras, o sistema compreendendo: um processador de gerenciamento para receber os dados em relação a um conjunto de transações financeiras que foram autorizadas por um sistema de processamento de pagamento de um programa de pagamen- to; e um processador de análise que determina se uma ou várias das transações financeiras autorizadas serão submetidas a um processamento adicional, em que o processamento adicional opera sobre os dados recebi- dos e identifica as transações financeiras autorizadas que podem compre- ender o emprego errado ou o abuso do programa de pagamento ou podem estar fora de conformidade com os regulamentos de transação do programa de pagamento.

13. Sistema, de acordo com a reivindicação 12, em que o pro- cessamento adicional do processador de análise compreende o processa- mento dos dados recebidos com um conjunto de regras predeterminadas de negócio e a identificação de transações financeiras como uma transação passada que esteja em conformidade com as regras de negócio ou como uma transação sinalizada que deva ser verificada para ver se há a violação de umas ou várias das regras de negócio.

14. Sistema, de acordo com a reivindicação 13, em que o pro- cessamento adicional do processador de análise compreende a execução da amostragem em transações passadas para designar uma ou várias das transações passadas como as transações sinalizadas para serem verifica- das para ver se há a violação de uma ou várias das regras de negócio.

15. Sistema, de acordo com a reivindicação 14, em que o pro- cessador de análise executa amostragem de acordo com aceitação de pa- râmetros de amostragem especificando um plano de inspeção.

16. Sistema, de acordo com a reivindicação 15, em que o plano de inspeção é especificado por uma entidade diferente de uma entidade de designação que designa dispositivos do consumidor portáteis em conexão com o programa de pagamento.

17. Sistema, de acordo com a reivindicação 12, em que o pro- cessador de análise inclui ainda um processador de predição que identifica características de transação que compreendem comportamento de anulação indicando uma provável transação não compatível.

18. Sistema, de acordo com a reivindicação 17, em que o pro- cessador de predição identifica características de transação usando análise de regressão.

19. Sistema, de acordo com a reivindicação 17, em que o pro- cessador de predição identifica características de transação usando análise de rede neural.

20. Sistema, de acordo com a reivindicação 17, em que o pro- cessador de predição identifica características de transação usando análise de algoritmo genético.

21. Sistema, de acordo com a reivindicação 13, em que o pro- cessador de gerenciamento recebe entrada de usuário sobre uma rede, de- termina que o usuário seja autorizado e ajusta a operação do processamen- to adicional de acordo com a entrada do usuário.

22. Sistema, de acordo com a reivindicação 21, em que o pro- cessamento de gerenciamento ajusta a operação mudando o processamen- to de transações passadas.

23. Produto de programa para uso em um sistema de computa- ção que executa instruções de programa gravadas em uma mídia legível por computador para executar um método para processar dados de transação financeira, o produto de programa compreendendo: uma mídia gravável; um programa de instruções legíveis por computador executável pelo sistema de computação para executar operações compreendendo: receber dados relacionados a um conjunto de transações finan- ceiras que foram autorizadas por um sistema de processamento de paga- mento ou um programa de pagamento; determinar se uma ou mais transações financeiras autorizadas será submetida a processamento adicional, em que o processamento adi- cional opera sobre os dados recebidos e identifica transações financeiras autorizadas que podem compreender mau uso ou abuso do programa de pagamento ou podem estar em desacordo com as regras de transação do programa de pagamento.

24. Produto de programa, de acordo com a reivindicação 23, em que o processamento adicional compreende processar os dados recebidos com um conjunto de regras de negócio predeterminadas e identificar transa- ções financeiras como uma transação passada que está de acordo com as regras de negócio ou como uma transação sinalizada que está para ser veri- ficada por violação de uma ou mais regras de negócio.

25. Produto de programa, de acordo com a reivindicação 24, em que o processamento adicional compreende executar amostragem sobre transações passadas para designar uma ou mais transações passadas co- mo transações sinalizadas para serem verificadas por violação de uma ou mais regras de negócio.

26. Produto de programa, de acordo com a reivindicação 25, em que a amostragem compreende aceitação de amostragem de acordo com parâmetros que especificam um plano de inspeção.

27. Produto de programa, de acordo com a reivindicação 26, em que o plano de inspeção é especificado por uma entidade diferente de uma entidade de designação que designa dispositivos de consumidor portáteis em conexão com o programa de pagamento.

28. Produto de programa, de acordo com a reivindicação 24, em que a operação para determinar processamento adicional compreende exe- cutar processamento de predição na transação passada para identificar ca- racterísticas de transação que compreende comportamento de anulação in- dicando uma provável transação não compatível.

29. Produto de programa, de acordo com a reivindicação 28, em que o processamento de predição utiliza análise de regressão.

30. Produto de programa, de acordo com a reivindicação 28, em que o processamento de predição utiliza análise de rede neural.

31. Produto de programa, de acordo com a reivindicação 28, em que o processo de predição utiliza uma análise de algoritmo genético.

32. Produto de programa, de acordo com a reivindicação 23, em que as operações realizadas ainda incluem: receber uma entrada de usuário via uma rede; determinar se o usuário está autorizado; e ajustar a execução do processamento de acordo com a entrada de usuário.

33. Produto de programa, de acordo com a reivindicação 32, em que operação de ajuste compreende o processamento de transações pas- sadas.

34. Método de processamento de dados de transações financei- ras, o método compreendendo: receber dados que se relacionam com um conjunto de transa- ções financeiras que foram autorizadas por um sistema de processamento de pagamento de um programa de pagamento; processar os dados recebidos com um conjunto predeterminado de regras de comercialização e identificar transações financeiras como uma transação passada que está em conformidade com as regras de comerciali- zação ou como uma transação sinalizada que deve ser verificada quanto a violação de uma ou mais regras de comercialização; realizar amostragem nas transações passadas para designar uma ou mais de transações passadas como transações sinalizadas para serem verificadas quanto à violação de uma ou mais regras de comercializa- ção; e realizar um processo de predição com base nas transações pas- sadas para identificar as características de transações que compreendem comportamento de anulação indicando uma provável transação em não con- formidade.

35. Método, de acordo com a reivindicação 34, em que o pro- cessamento adicional compreende um processamento de auditagem / con- formidade para identificar uma transação em não conformidade.

36. Sistema para processamento de dados de transações finan- ceiras, o sistema compreendendo: um processador de gerenciamento para receber os dados rela- cionados com as transações financeiras submetidas a um sistema de pro- cessamento de pagamento de um programa de pagamento para autorização de pagamento; um processador de filtro / regras para identificar a transação fi- nanceira como uma transação passada que esteja em conformidade com um conjunto predeterminado de regras de comercialização ou como uma tran- sação sinalizada que deva ser verificada quanto à violação de uma ou mais regras de comercialização; um processador de amostragem para implementar um plano de amostragem que realize amostragem em transações passadas para desig- nar uma ou mais das transações passadas como transações sinalizadas pa- ra serem verificadas quanto à violação de uma ou mais regras de comercia- um processador de predição para realizar o processamento de predição em transações passadas para identificar características de transa- ção que compreendem o comportamento de anulação indicando uma prová- vel transação em não conformidade.

37. sistema de acordo com a reivindicação 36, em que o proces- samento adicional compreende o processamento por um processador de auditagem / conformidade para determinar se uma transação passada é uma transação em não conformidade.