Autor(ES): Ruggero Ruggieri, Mauricio Hiroki Chigashi e Teruo Miyamura Código: painel09

(1)

<código do documento> Página 1 de 11

Autor(ES): Ruggero Ruggieri, Mauricio Hiroki Chigashi e Teruo Miyamura

Código: painel09

INTRODUÇÃO:

O projeto de pagamentos do licenciamento eletrônico no estado de São Paulo foi implantado em 2007, oferecendo aos Bancos conveniados a entrega das informações em tempo real. Naquele momento houve uma mudança da informação, passando o ambiente local para outro ambiente mais controlado em tempo real. De qualquer maneira o projeto anterior possibilitava o pagamento em duplicidades quando realizados em Bancos distintos e as baixas das informações continuavam sendo um problema para os contribuintes. As informações de repasse financeiro no ambiente anterior eram demoradas e não havia como aferir estes depósitos, pois a Secretaria da Fazenda de São Paulo como agente arrecadador dependia das informações de pagamentos realizados pelos Bancos. Com a necessidade de implantação do Sistema IPVA e Licenciamento de veículos em tempo real no estado de São Paulo pela SEFAZ em curto espaço de tempo foi um grande desafio para a Prodesp, considerando todo o ambiente legado existente na época já em fase de preparação no ambiente mainframe para a aplicação em tempo real. Houve uma necessidade de implementação de padrões de formato de transações de pagamentos entre o Estado e com os Bancos. Com a implantação desta nova modalidade de pagamentos, houve uma inversão da informação. Em tempo real a Secretaria da Fazenda de São Paulo passou a aferir melhor os seus tributos, avaliar os pagamentos, melhorar o repasse financeiro e ajudar os contribuintes do Estado de São Paulo, realizar o seu licenciamento de veículo, pagamentos de IPVA, emitir o seu CRLV (Certificado de Registro de Licenciamento de Veículos). Havia a necessidade de implementação de uma solução SOA que viabilizasse a implantação do Projeto, porém, sem perder investimentos de infra-estrutura do legado.

SITUAÇÃO PROBLEMA OU OPORTUNIDADE:

A necessidade de implantação do Sistema IPVA e Licenciamento de veículos em tempo real no estado de São Paulo pela SEFAZ em curto espaço de tempo foi um grande desafio para a Prodesp, considerando todo o ambiente legado existente na época na modalidade cartucho, mas já em fase adiantada de desenvolvimento para a preparação no ambiente mainframe para a aplicação em tempo real.

Os aspectos relevantes abordados foram:

- A necessidade de implementação de padrões de formato de mensagens ISO8583 solicitado pela FEBRABAN trouxe à tona a necessidade de busca de solução que agregasse ao projeto já desenvolvido até momento, porém, sem perder os códigos de negócios já desenvolvidos até então. A busca por soluções em parceria que propiciassem a geração de uma camada de controle de formatos padrão ISO8583. Hoje o padrão ISO8583 é utilizado para o intercâmbio entre emissões e aquisições com cartões de crédito. A Implementação da ISO8583, particularmente com respeito a transações através de limites internos das instituições é tratado como transação financeira entre 2 instituições que estão negociando pagamentos com transferência monetárias, na qual, este formato reduz custos dos bancos que são membros e na interoperabilidade além das fronteiras internas das instituições entre usuários dos padrões ISO de forma a ser atingida mais efetivamente. Serviços da industria financeira incluem a troca de mensagens eletrônicas relacionadas a transações financeiras. Acordos na aplicação da especificação são geralmente ao nível de negócio ou a nível privado. Este padrão internacional é designado como uma especificação de interface habilitando mensagens serem trocadas entre sistemas adotando uma variedade de especificações de aplicações. A aplicação da especificação pode se manter a um nivel privado. As aplicações tem a completa liberdade de projetar totalmente restrições em que mensagens devem ser convertidas para o formato de interface em ordem que intercâmbios internacionais. Este padrão internacional usa um conceito chamado "bit map", onde cada elemento de dado é designado a uma posição indicadora no campo de control, ou "bit

map". Um bit ligado (1) na posição designada indica a presença do elemento de dado na especificação da

mensagem. Um zero no bit (desligado) na posição designada indica a ausência do elemento de dado. Este formato de mensagens usados em sistemas individuais são temas das relações comerciais entre as partes contratantes de cada sistema. Os formatos de dados especificada neste padrão internacional são designados para assegurar que a compatibilidade entre os sistemas conforme este padrão internacional é sempre viável.

(2)

- A necessidade de implementação de protocolo padronizado de troca de mensagens com conceito de Filas que não dependesse da infra-estrutura de hardware das Instituições Financeiras.

- A necessidade de implementação de conexão de rede confiável e de alta performance em um serviço utilizado por todos os Bancos filiados à FEBRABAN e que permitisse UPGRADES sem alterar a estrutura básica de rede. Evidentemente seria necessária a implementação de duas concessionárias distintas onde seus links pudessem ser inseridos em um contexto de redundância.

- A necessidade de implementação de segurança VPN com criptografia nas mensagens que trafegassem pelo túnel.

Solução:

Descreveremos a solução de cada uma das quatro necessiadades levantadas no item anterior: 1) Prova de Conceito de Software

No ano de 2005 a PRODESP juntamente com a Secretaria da Fazenda de São Paulo iniciou o processo de avaliação de software que fosse adequado aos padrões de mensageria que fosse aderente ao projeto de pagamentos do sistema. O produto deveria possibilitar a conectividade com a solução MQ para conexão externa. Para conexão com o Ambiente Externo (Bancos) foi adotado o software de mensageria MQSERIES. Havia uma referência de software utilizado neste projeto, no caso MQSeries da IBM, que deveria ser avaliado na modalidade de uso no projeto de pagamentos no caso Baixa plataforma ou Alta plataforma. Optou-se em utilizar o software na modalidade Baixa Plataforma. Em ambos casos o produto foi avaliado e customizado para o atendimento dos requisitos do projeto. A implementação MQ em servidores da Baixa Plataforma foi uma solução viável do ponto de vista financeiro e de fácil implementação considerando que os Bancos conheciam o mesmo e já utilizavam esse produto no Sistema SPB (Sistema de Pagamentos Brasileiros) desenvolvido pelo Banco Central do Brasil.

2) Treinamento

Após avaliação e compra do software, a PRODESP treinou o seu corpo técnico para obtção do conhecimento e condições de implementar o produto em seu parque tecnológico. Em decorrência deste acontecimento foram treinados 20 técnicos para a demanda inicial do projeto.

3) Implementação do Padrão ISO8583:

A necessidade de criação dessa camada externa de controle do formato das mensagens ISO8583 à aplicação de negócio instalado no Mainframe, levou a Prodesp a testar soluções diversas do mercado que tivessem como características que em sua essência seria uma solução SOA ( Arquitetura Orientada a Serviços): Possibilitasse o controle da entrada das mensagens vindas dos bancos se estariam conforme o padrão estabelecido. A implementação do ISO8583 na Baixa plataforma seria um fator importante para tirar a carga de processamento no Mainframe onde estaria a aplicação com as regras de negócio. Criação de uma infra-estrutura de camada que possibilitasse o desenvolvimento e padronização de métodos e a implementação de outros serviços que viessem a ser agregados ao primeiro. Manter a premissa que esta camada garantiria que as mensagens a serem enviadas para o Mainframe fossem sem erros de formatação, ou seja, mensagens limpas (data quality). Manter toda a infra-estrutura de DEBUG das mensagens dentro dessa camada controlada. O produto deveria ser customizável para atender às premissas de alta

performance e de tempo de reposta assim como permitindo a escalabilidade para no caso de necessidade

de expansão de servidores/produtos compatíveis com as demandas de transação. Criar um ambiente de pagamentos entre o Governo do Estado e com a iniciativa Privada. A solução que se mostrou adequada foi o WBI-Message Broker da IBM que além de atender os pré-requisitos anteriores, traria o produto MQ dentre os softwares de seu pacote de produtos nativo que faz parte das necessidades apontadas no item a seguir.

9300 – Solicitação do Banco para pesquisa de informação 9310 – Resposta do Governo com as informações

0200 – Início da transação de pagamento

0210 – Informação de retorno de pagamentos com o Governo 0202 – Conclusão do pagamento e encerramento da transação

(3)

interrompido a transação 0200

0610 – Sonda de definição e conclusão do pagamento – Resposta do Banco

0800 – Verificar se o sistema de mensageria está aberto entre as áreas (Governo e Banco) - ECO 0810 – Resposta do Banco informando que o canal de comunicação está aberto.

Figura 2 – Fluxo de mensagens ISO8583

(4)

4) Solução ISO8583 entre Bancos e Governo

Após estudos técnicos sobre a forma de mensageria, a Secretaria da Fazenda de São Paulo e PRODESP iniciaram juntamente com os Bancos a padronização das mensagerias e os conceitos de negociação transacional destes pagamentos. Ficou decidido que seriam transacionados os seguintes tipos de serviço:

• Transferência de Veículos; • Licenciamento de veículos;

• 2ª via de licenciamento de veículos; • 2ª via de transferência de veículos; • 1º emplacamento do veículo; • Débitos pendentes;

• IPVA; • DPVAT;

• Multas de Trânsito.

Todos os serviços acima foram padronizados no conceito de mensageria ISO8583. 5) Parcerias

Após a conclusão dos trabalhos de definição das mensagerias, a PRODESP começou a desenvolver o primeiro manual estadual de mensageira de pagamentos entre o Governo e Bancos. Manual amplamente difundido entre as Unidades da Federação e Bancos. A implantação dos Bancos seguiu a seguinte cronologia:

(5)

6) Conexão de Redes Prodesp x Bancos:

A solução adotada consistiu em negociar com duas operadoras de Redes Frame Relay do mercado e solicitar o fornecimento de “grandes tubos de Entrada de Links “ denominados ENTRANTES chegando no Data Center da PRODESP, e o mais importante de tudo, sem custo para o Estado. A questão do custo foi considerada estratégica, para que o Estado não ficasse refém das necessidades da Instituições Bancárias em querer aumentar ilimitadamente seus Links remotos para acessar as bases da Prodesp conforme os seus critérios e como conseqüencia o Estado precisasse investir nessas expansões dos acessos ENTRANTES do lado Prodesp. A forma como foi acertada com as concessionárias o Estado seria apenas como hospedeiro dos acessos ENTRANTES e estaria sempre aberto às expansões de velocidades dos

Links das Instituições Financeiras sem aumento de custo para si. Solução implementada: Foram firmados

acordos entre a Prodesp e a EMBRATEL e a Telefonica para atender as necessidades deste projeto. Definiu-se uma topologia de redundância de Links e os Bancos passaram a contratar acessos aos ENTRANTES de ambas concessionárias para acessar o Data Center da Prodesp. Todos os Bancos a princípio contrataram os dois Links. Todos os Bancos ( 15 ) contratatram links remotos da EMBRATEL e Telefonica originados no SITE do Banco até a chegada aos acessos ENTRANTES na Prodesp. Parceiros: EMBRATEL e Telefonica

(6)

(7)

7) Segurança VN e criptografia:

Definiu-se uma topologia e um padrão VPN com criptografia para implementar uma segurança de conexão e também na troca segura de mensagens entre a Prodesp e as Instituições Bancárias. Solução implementada: A Prodesp adotou o Produto VPN da Sonicwall .Foram homologados para implementação por parte dos Bancos as VPNs Sonicwall, CICSO PIX e Checkpoint que eram os produtos de maior utilização por parte dos Bancos.

INOVAÇÃO E INEDITISMO:

Tratava-se de uma iniciativa inédita, considerando-se a ordem de grandeza de tudo que se refere ao Estado de São Paulo do ponto de vista transacional com respostas em tempo real. O volume de transações que envolveria o processamento de pagamento em tempo real de 15 milhões de contribuintes de IPVA de janeiro a março de 2007 no estado de São Paulo. Este foi considerado o maior desafio para a Secretaria da Fazenda de São Paulo juntamente com a Prodesp, do lado da Gestão Pública e para a FEBRABAN com seus 15 maiores Bancos associados que se propuseram a encarar esse desafio. O serviço seria estruturado sobre uma arquitetura, sem dúvida, com as dimensões de uma das maiores redes interligadas acessando uma única base de dados, no caso a Prodesp, representando a figura do estado. Na visão da Gestão Pública Estadual, o Estado passaria ter o controle em tempo real dos pagamentos de tributos ( IPVA, licenciamento, etc ) realizados pelos contribuintes nos Bancos conveniados com a SEFAZ, possibilitando refinamento dos valores de repasse a serem creditados pelas instituições bancárias na conta do estado. Em resumo tratava-se de um desafio ao estado em implementar uma solução ousada pela sua magnitude e que fosse aderente às mais avançadas soluções de TI disponíveis no mercado e em uso pelas Instituições Financeiras. Para viabilizar o pagamento em 3 meses de 15 milhões de contribuintes de IPVA do estado de

(8)

São Paulo distribuídos em 10 dias úteis mês a mês chegaria a uma concentração de pagamentos que culminou na necessidade mínima de performance de 165 transações por segundo.

• Vários testes pilotos foram realizados na Prodesp até o refinamento final da solução como um todo do lado da Prodesp tais como:

o Expansão de CPU (processadores centrais) do Mainframe

o Adequação das quantidades de servidores/licenças de softwares onde seria inserida a camada que controlaria o ISO8583

o Expansão inicial dos acessos Frame Relay Entrantes na EMBRATEL e da Telefonica para poder comportar o upgrade dos Links dos Bancos.

Desta forma, o resultado das projeções do Projeto IPVA online pôde ser comprovado após a implementação em Janeiro de 2007 com os pareceres colhidos junto à opinião pública e da própria FEBRABAN que pode auferir na boca do caixa a resposta das transações de pagamento desses tributos. A aplicação com pagamento em tempo real em qualquer dos Bancos conveniados, possibilitou ao cidadão, a liberação imediata para emissão dos CRLV (Certificado de Registro e Licenciamento de Veículo) nos Poupatempos, DETRAN-SP e CIRETRANS. Da mesma forma será possível a partir da implementação desta infra-estrutura já implementada desde 2007 inserir outros tipos de pagamentos de tributos desde que devidamente readequados para o novo contexto. Os resultados mostraram que a solução do software, hardware e segurança mostrou consistente e adequado para o atendimento ao publico. A solução mostrou ineditismo para o ambiente para o qual ele se insere e para o serviço público em geral. Trouxe para o estado uma nova forma de pagamentos entre a área púbica com a iniciativa privada.

PÚBLICO-ALVO:

O público beneficiados pelo projeto seriam:

• CONTRIBUINTES – facilidade de pagamento do tributo diretamente na rede bancária; • BANCOS – facilidade na prestação de contas e no desenvolvimento do projeto;

• SEFAZ – Avaliação imediata sobre os pagamentos dos tributos, redução das tarifas bancárias; • DETRAN – recebimentos e liberação dos certificados de registros;

• FENASEG – Seguro obrigatório pago e repasse financeiro;

• MUNICÍPIOS – Repasse financeiro dos tributos para os municípios paulistas;

• VEÍCULOS – bloqueios de veículos que estiverem inadimplentes com o estado, problemas cadastrais e legais;

RELEVÂNCIA PARA O INTERESSE PÚBLICO:

Relevância do projeto foi à vantagem dos pagamentos serem automáticos com a liberação e emissão imediata do CRLV (Certificado de Registro e Licenciamento de Veículo) no ato do pagamento na rede bancária. Beneficiando o contribuinte retirar o seu certificado nos postos de atendimento do Estado de São Paulo (DETRAN /SP e CIRETRANS), POUPATEMPO ou o seu recebimento na sua residência através do CORREIOS na modalidade SEDEX. Melhorias no atendimento e prestação dos serviços para o contribuinte. Transparência nas informações quanto aos tributos cobrados, informando os débitos que estão pendentes com o Estado e multas que o contribuinte recebeu no período do licenciamento vigente. Possibilitando ao contribuinte elaborar contestação de multas incluídas indevidamente. Possibilidade de pagamento numa ampla rede bancária conveniadas com a Secretaria da Fazenda de São Paulo em todo território nacional. Beneficiando o contribuinte obter informações sobre o veículo quando ele estiver transferindo o seu veículo.

Tudo isso, considerando que a base de dados para acesso no ato da pesquisa e pagamento é única e centralizada no Estado e não como era anteriormente com a sua replicação em bases locais nos Bancos.

Beneficio na prestação de contas e transferência do repasse financeiro para a Secretaria da Fazenda de São Paulo. A Secretaria da Fazenda de São Paulo passou a controlar melhorar os seus

(9)

pagamentos, pois de agente recebedor de informações de pagamentos (agente passivo) para agente cobrador dos tributos (agente ativo).

EFETIVIDADE

Com a implantação do online a Secretaria da Fazenda de São Paulo pode economizar nas transações bancárias entre os Bancos afiliados no projeto. No processo anterior os Bancos cobravam por registro de pagamentos efetuados pelos contribuintes. Na nova modalidade online definida pela Secretaria da Fazenda de São Paulo, os registros puderam ser agrupados numa única placa do veículo as transações de pagamentos, com isso diminuindo os custos das tarifas bancárias. Esta diminuição estaria em torno de 30% com relação à modalidade anterior. Com esta redução de custo de tarifa, o Estado estaria revertendo para o desenvolvimento inicial do projeto e na sua melhoria de prestação de serviço para o cidadão. O sistema hoje pôde ser utilizado por todos os contribuintes paulista que precisam efetuar com comodidade os pagamentos dos tributos dos seus veículos, atualmente a frota de veículos do estado está em torno de 15 milhões, distribuída na proporção de 40% na capital paulista e o restante no interior do estado.

Em 2007 as emissões de CRLV´s postalizadas e enviadas pelo CORREIO chegaram a seguintes quantidades conforme distribuição bancária:

Có

digo

Nome

Total

42

2 BANCO SAFRA

7.819

39

9 HSBC-BAMERINDUS

80.05

8

23

7 BRADESCO

865.7

27

34

7 SUDAMERIS

30.57

2

38

9 BANCO MERCANTIL

3.822

35

6 BANCO REAL

191.4

60

62

3 BANCO PANAMERICANO

3.319

34

1 BANCO ITAU

858.6

63

25

0 BANCO SCHAHIN

25.66

8

33 BANESPA

471.7

68

10

4 CAIXA ECONOMICA FEDERAL

276.0

46

15

1 BANCO NOSSA CAIXA

704.5

11

(10)

40

9 UNIBANCO

216.4

92

1 BANCO DO BRASIL

173.0

36

74

5 CITIBANK S.A.

5.533 Total no Período

3.914.

494

Houve um acréscimo de 30% comparando-se o ano anterior do projeto quando o sistema não estava efetivamente no processo online de pagamentos. Os contribuintes passaram a utilizar melhor a postalização e envio das informações nas residências.

FACILIDADE DE REPRODUÇÃO:

Considerando a arquitetura como foi desenvolvido o Projeto com a separação de camadas de negócios da camada de mensageria possibilitou um alto grau de facilidade tecnológica e financeira em implementar novos serviços para a Secretaria da Fazenda de São Paulo além dos 10 tipos já implementados. Mesmo que sejam de outra classificação de negócios dentro da área tributária, há possibilidade de implementar novas camadas de Padrão ISO8583 no WBI – Message Broker segundo novos critérios de formato de mensagens (seja em tamanho de campo, tipo de caráter alfa ou numéricos) ou por tipo de consistência necessária conforme a definição das regras de negócio. A necessidade de expansão do hardware e

software dependerá do resultado de um Projeto Piloto a ser testado para dimensionamento dos recursos

adicionais. Cabe ressaltar que nesse dimensionamento devem-se incluir os de Rede e Segurança também. AMBIENTE DE HARDWARE E SOFTWARE

Serão descritas abaixo, as arquiteturas que compõe o Projeto: Arquitetura de hardware:

• Alta plataforma - Mainframe IBM

• Baixa Plataforma – Servidores ( HP, IBM e ITAUTEC ) – Brokers e Cluster MQ Arquitetura de Rede:

• Switch CORE – Layer 7

• Redes Frame Relays EMBRATEL e Telefonica Arquitetura de Segurança de Rede:

• VPN da Sonicwall do lado Prodesp e do lados Bancos, Cisco PIX, Checkpoint e Sonicwall. • Criptografia

Arquitetura de Software:

• MQSERIES da IBM ( Mensageria de Filas ) • WBI-Message Broker da IBM (

• CTG – CICS Transaction Gateway da IBM para acesso do Broker para o Mainframe no Ambiente CICS

(11)