Embed Size (px)
Citation preview
UNIVERSIDADE DE SÃO PAULO
ESCOLA POLITÉCNICA
THYAGO ALBANI PRADO SUMARES
Sistema de informação para banco de varejo
São Paulo
2012
UNIVERSIDADE DE SÃO PAULO
ESCOLA POLITÉCNICA
THYAGO ALBANI PRADO SUMARES
Sistema de informação para banco de varejo
Trabalho de Formatura apresentado à
Escola Politécnica da Universidade de
São Paulo para a obtenção do diploma
de Engenheiro de Produção.
São Paulo
2012
THYAGO ALBANI PRADO SUMARES
Sistema de informação para banco de varejo
Trabalho de Formatura apresentado à
Escola Politécnica da Universidade de
São Paulo para a obtenção do diploma
de Engenheiro de Produção.
Orientador: Prof. Dr. Mauro de Mesquita
Spinola
São Paulo
2012
FICHA CATALOGRÁFICA
Sumares, Thyago Albani Prado
Sistema de informação para banco de varejo / T.A.P.
Sumares. -- São Paulo, 2012.
118p.
Trabalho de Formatura - Escola Politécnica da Universidade
de São Paulo. Departamento de Engenharia de Produção.
1. Softwares 2. Mercado financeiro I. Universidade de São
Paulo. Escola Politécnica. Departamento de Engenharia de
Produção II. t.
DEDICATÓRIA
Dedico esse trabalho aos meus pais, meus exemplos de dedicação e altruísmo. Sem
eles, chegar até aqui não seria possível.
AGRADECIMENTO
Aos meus pais, Marcelo e Lucia, pelo apoio incondicional que me deram ao longo da
vida. Pela educação proporcionada e pelos exemplos de bondade e ética. Pela paciência nos
momentos complicados e pelos sorrisos em todas as vitórias.
À minha irmã, Julia, que mesmo nos momentos em que estava mais distante, sempre
esteve (e vai estar) presente em nossas lembranças.
Ao professor Mauro, pela orientação durante todo o desenvolvimento do trabalho.
A todos os meus colegas de trabalho, por toda a confiança e pelos ensinamentos que
me deram e ainda dão.
RESUMO
Quando bancos realizam o processo de intermediação financeira acabam expostos a diversos
riscos inerentes ao negócio, podendo-se destacar dentre eles o risco de mercado, ligado à
possibilidade de oscilações das taxas de mercado que indexam as operações das instituições
financeiras. Para realizar a centralização desse risco em uma única área, responsável pelo seu
gerenciamento, os bancos utilizam uma metodologia denominada funds trasfer pricing,
baseada em uma ferramenta, a Taxa de Transferência Interna. Por falha na modelagem desse
processo, o banco analisado no presente trabalho não possui etapa de controle que garanta que
essa taxa sempre siga a metodologia proposta em todas as operações. Para atingir esse
objetivo, desenvolveu-se o projeto de um sistema de informação capaz de calcular essas taxas
e compará-las com as registradas nas bases de dados da organização, contribuindo para a
melhoria do processo estudado e garantindo o respeito à metodologia inicialmente proposta.
Palavras-Chave: Sistema de Informação, Taxa de Transferência Interna.
ABSTRACT
When banks do financial mediation process, they end up exposed to several risks inherent to
business, being the market risk the most prominent, as it is linked to the possibilities of
market rates oscillations that index the financial institutions operations. To centralize this risk
in one big managing area, banks use a methodology called "funds transfer pricing", based on a
tool, the intern transfer rate. Due to a process modeling flaw, the bank analyzed in this work
do not have a control stage able to guarantee that these rates always follows the proposed
methodology in all operations. To achieve this objective, an information system has been
developed, capable of calculate these rates and compare them to those registered in the
organization data bases, contributing to the improvement of the studied process and ensuring
the respect to the first proposed methodology.
Key words: Information system, Intern transference taxes
LISTA DE FIGURAS
Figura 1 - Transferência de riscos de mercado para Gestão Financeira/ALM ............... 21
Figura 2 - Exemplo de fluxo de caixa ................................................................................ 26
Figura 3 - Fluxo de caixa para cálculo da TTI para ativos .............................................. 32
Figura 4 - Representação de caso de uso e ator ................................................................ 42
Figura 5 - Ciclo PDCA para o atual modelo de funds transfer pricing ............................ 52
Figura 6 - Diagrama de contexto do sistema de informação ............................................ 70
Figura 7 - Esboço da interface inicial do sistema .............................................................. 71
Figura 8 - Esboço da interface principal do sistema ......................................................... 73
Figura 9 - Esboço da interface de análise por produto ..................................................... 73
Figura 10 - Interface principal definitiva do sistema........................................................ 93
Figura 11 - Interface inicial definitiva do sistema ............................................................ 97
Figura 12 - Atual processo de geração de ativos ............................................................... 98
Figura 13 - Processo de geração de ativos com a introdução do novo sistema ................ 99
LISTA DE FLUXOGRAMAS
Fluxograma 1 - Atividades da Análise de Requisitos........................................................ 40
Fluxograma 2 - Descrição de atividades em caso de fluxo de pagamento regular .......... 78
Fluxograma 3 - Descrição de atividades em caso de fluxo de pagamento irregular ........ 78
Fluxograma 4 - Processo básico software ......................................................................... 80
Fluxograma 5 - Cálculo da Taxa de Transferência Interna em fluxo regulares ............. 83
Fluxograma 6 - Cálculo da Taxa de Transferência Interna em fluxos irregulares ......... 89
LISTA DE QUADROS
Quadro 1 - Informações mais relevantes das bases de dados de contratos ...................... 60
Quadro 2 - Informações mais relevantes das bases de dados de parcelas ....................... 61
Quadro 3 - Benefícios do sistema de informação .............................................................. 68
Quadro 4 - Definição das características da interface principal do sistema .................... 72
Quadro 5 - Definição das características da interface de análise por produto ................ 74
Quadro 6 - Classificação do caso de uso ............................................................................ 76
Quadro 7 - Classificação das interfaces ............................................................................ 76
Quadro 8 - Classificação dos requisitos não funcionais .................................................... 76
Quadro 9 - Percentual de erros encontrados em cada base de dados ............................ 102
LISTA DE ABREVIATURAS E SIGLAS
ALM Asset and Liability Management
BIS Bank for International Settlements
CDB Certificado de Depósito Bancário
CDI Certificado de Depósito Interbancário
CETIP Central de Custódia e Liquidação Financeira de Títulos
DPGE Depósito a Prazo com Garantia Especial
FGC Fundo Garantidor de Crédito
FTP Funds Transfer Pricing
IGP-M Índice Geral de Preços do Mercado
IPCA Índice Nacional de Preços ao Consumidor Amplo
LCR Liquidity Coverage Ratio
LTP Liquidity Transfer Pricing
NSFR Net Stable Funding Ratio
SELIC Sistema Especial de Liquidação e Custódia
SQL Structured Query Language
TEC Taxa Efetiva de Custo
TIR Taxa Interna de Retorno
TR Taxa de Referência
TTI Taxa de Transferência Interna
VBA Visual Basic for Applications
SUMÁRIO
1. Introdução .................................................................................................................................... 16
1.1. Contexto ............................................................................................................................... 16
1.1.1. Riscos da Atividade ..................................................................................................... 17
1.1.2. Taxa de Transferência Interna (TTI) ........................................................................ 19
1.2. Política de Funds Transfer Pricing (FTP).......................................................................... 21
1.3. Problemas Encontrados ...................................................................................................... 22
1.3.1. Resultado da área de Gestão Financeira/ALM......................................................... 23
1.3.2. Desrespeito às políticas de Taxa de Transferência Interna ..................................... 23
1.4. Objetivo do Trabalho .......................................................................................................... 23
2. Fundamentação Teórica ............................................................................................................. 25
2.1. Taxa interna de retorno ...................................................................................................... 25
2.2. DI-Futuro ............................................................................................................................. 28
2.3. Descrição do cálculo das Taxas de Transferência Interna .............................................. 29
2.4. Políticas de Taxa de Transferência – Matched-maturity marginal cost of funds ............ 34
2.5. Ciclo PDCA .......................................................................................................................... 36
2.6. Análise de Requisitos .......................................................................................................... 37
2.6.1. Determinação do contexto .......................................................................................... 40
2.6.2. Definição do escopo ..................................................................................................... 41
2.6.3. Definição dos requisitos .............................................................................................. 41
2.6.4. Detalhamento dos requisitos de interface ................................................................. 42
2.6.5. Detalhamento dos requisitos funcionais .................................................................... 43
2.6.6. Detalhamento dos requisitos não-funcionais ............................................................ 43
2.6.7. Classificação dos requisitos ........................................................................................ 44
2.6.8. Revisão dos Requisitos ................................................................................................ 44
2.7. Requisitos de interfaces de usuário de software ................................................................ 44
2.7.1. Modelo mental ............................................................................................................. 45
2.7.2. Consistência e simplicidade ........................................................................................ 45
2.7.3. Questões de memorização ........................................................................................... 46
2.7.4. Questões cognitivas ..................................................................................................... 47
2.7.5. Realimentação .............................................................................................................. 47
2.7.6. Mensagens do sistema ................................................................................................. 48
2.7.7. Modalidade .................................................................................................................. 48
2.7.8. Reversibilidade ............................................................................................................ 48
2.7.9. Atração da atenção ...................................................................................................... 49
2.7.10. Exibição ........................................................................................................................ 49
2.7.11. Diferenças individuais ................................................................................................. 50
3. Metodologia ................................................................................................................................. 51
4. Solução Técnica ........................................................................................................................... 55
4.1. Triagem Inicial .................................................................................................................... 55
4.1.1. Escopo inicial do projeto ............................................................................................. 56
4.1.2. Tipos de contrato ......................................................................................................... 57
4.1.3. Tipos de Base de Dados ............................................................................................... 58
4.1.4. Informações armazenadas nos bancos de dados....................................................... 59
4.1.5. Limitações das bases de dados ................................................................................... 61
4.1.6. Tipos de convenção de contabilização de dias de contrato ...................................... 63
4.1.7. Resultados da triagem inicial ..................................................................................... 64
4.2. Análise de requisitos............................................................................................................ 65
4.2.1. Determinação do contexto .......................................................................................... 67
4.2.2. Definição do escopo ..................................................................................................... 67
4.2.3. Definição dos requisitos .............................................................................................. 69
4.2.4. Detalhamento dos requisitos da interface ................................................................. 70
4.2.5. Detalhamento dos requisitos funcionais .................................................................... 74
4.2.6. Detalhamento dos requisitos não funcionais ............................................................. 75
4.2.7. Classificação dos requisitos ........................................................................................ 76
4.2.8. Revisão dos requisitos ................................................................................................. 77
4.2.9. Resumo das principais necessidades do sistema ....................................................... 77
4.3. Desenvolvimento do sistema de cálculo mensal ................................................................ 79
4.3.1. Ligação entre bancos de dados e planilha ................................................................. 81
4.3.2. Realização dos cálculos de Taxa de Transferência Interna do contrato ................ 82
4.3.3. Cálculo para contratos de fluxo regular .................................................................... 82
4.3.4. Cálculo para contratos de fluxo irregular ................................................................. 88
4.3.5. Apresentação das interfaces ....................................................................................... 92
4.4. Impacto da introdução do sistema no processo ................................................................ 98
5. Análise crítica do projeto .......................................................................................................... 101
6. Referências ................................................................................................................................. 104
APÊNDICE A – Código básico do sistema para a base de dados VS ........................................... 107
APÊNDICE B – Código de consulta à uma base de dados de Microsoft SQL ............................ 108
APÊNDICE C – Código para cálculo de operações com fluxo regular ........................................ 111
APÊNDICE D – Código para cálculo da Taxa de Transferência Interna ................................... 115
APÊNDICE E – Código específico para o cálculo de fluxos irregulares ...................................... 118
16
1. Introdução
O presente trabalho tem como objetivo descrever todo o processo de desenvolvimento
de um software que calcula Taxas de Transferência Interna de todas as operações de crédito
realizadas durante um mês por um banco de varejo. Após esses cálculos, o sistema
confecciona relatórios gerenciais mostrando quais operações não possuem a Taxa de
Transferência Interna condizente com a calculada pelo sistema e que volume elas representam
do total de operações.
O primeiro capítulo do trabalho tem como objetivo contextualizar o leitor a respeito do
ambiente que envolveu o desenvolvimento do projeto, detalhando as atividades realizadas
durante o estágio e relacionando-as com alguns conceitos básicos do funcionamento da
atividade bancária. Dessa forma, é possível mostrar a relevância que o sistema, cujo
desenvolvimento está descrito ao longo do trabalho, possui para as atividades do setor do
banco em que foi feito o estágio e também para a instituição financeira como um todo.
1.1. Contexto
O estágio foi realizado em 2012 num banco de varejo de grande porte no mercado
brasileiro, na área de Gestão Financeira/ALM (Asset and Liability Management), que é o setor
responsável por gerenciar os riscos financeiros do balanço patrimonial da instituição, com o
intuito de maximizar o seu resultado.
A área possui uma abordagem de banking, ou seja, tem como objetivo posicionar o
banco nos mercados com uma visão estrutural de longo prazo, sem a preocupação de
aproveitar oscilações no mercado de curto prazo que abririam espaço para se obter lucro,
abordagem esta denominada de trading.
A razão para a adoção dessa estratégia nessa área do banco diz respeito ao fato de ela
ser responsável pela gestão de posições estruturais da organização, como por exemplo, o caixa
do banco. Dessa forma, há enorme necessidade de controle dos riscos das posições assumidas
pela Gestão Financeira/ALM.
Dentro dessa área podem ser identificadas três questões fundamentais a serem
gerenciadas: capital, portfólio e liquidez.
17
De modo simplificado, o capital pode ser entendido como o patrimônio líquido do
banco. Para cada tipo de atividade que a organização realiza, desde empréstimos, a compras
de ações de outras empresas ou operações com derivativos, os diversos órgãos reguladores do
sistema bancário desenvolveram métricas de exigência de uma quantidade de capital
proporcional a cada tipo de atividade, dependendo do risco inerente a ela, para que a
instituição apresente solidez em diferentes cenários, mesmo nos mais desafiadores para a
atividade bancária, e não ponha em risco todo o sistema financeiro. Cabe à gestão do capital
otimizar a alocação dele a partir dessas exigências regulatórias, tornando o balanço
patrimonial do banco o mais rentável possível a partir dessa ótica.
A gestão do portfólio do banco está ligada ao acompanhamento da sua posição no que
diz respeito às suas carteiras de ativos e passivos, ou seja, como essas carteiras possuem, de
modo geral, remunerações atreladas a diversos índices de mercado, como taxa de juros ou
inflação, o resultado do banco pode ser impactado (tanto positiva como negativamente) em
caso de oscilações no mercado. A gestão do portfólio analisa essas posições das carteiras
juntamente com as suas expectativas para o mercado (aumento ou queda dessas taxas) e
define se continuará assumindo esse risco ou se realizará um hedge para eliminá-lo.
A gestão da liquidez diz respeito principalmente à manutenção do caixa da instituição
em patamares que garantam não somente que qualquer resgate de aplicação possa ser feita
pelos clientes como também respeite as exigências regulamentares sobre o nível do caixa. Em
termos estruturais pode-se analisar que o caixa do banco aumenta se a quantidade de ativos
gerados for menor que a de passivos e, diminui caso o contrário ocorra. Como será detalhado
nos próximos capítulos do trabalho, o incentivo à geração de ativos ou passivos está ligado
intimamente à Taxa de Transferência Interna definida pela Gestão Financeira/ALM, que é o
objeto da análise do sistema desenvolvido. A atividade principal do autor como estagiário era
o cálculo dessa taxa para as operações de grande porte.
1.1.1. Riscos da Atividade
No ambiente de um banco existem diversos riscos inerentes ao negócio e compreendê-
los é fundamental para entender a essência da função da Gestão Financeira/ALM. São
notadamente importantes para a atividade bancária três deles: o risco de crédito, o risco de
mercado e o risco de liquidez.
18
O risco de crédito é o mais simples de ser entendido e está ligado à possibilidade de
ativos gerados pelo banco não serem pagos pelo cliente da operação (MANKIW, 2009).
Assim, quando se empresta recursos a um cliente, o banco assume o risco de crédito desse
tomador dos recursos, cobrando uma taxa por conta disso. Esse tipo de risco não é gerenciado
pela área de Gestão Financeira/ALM.
O risco de mercado está relacionado com a possibilidade de oscilações nas taxas às
quais os contratos estão indexados (CHOUDHRY, 2007). Esse risco não existiria caso todos
os contratos, tanto de passivos como de ativos, fossem indexados à mesma taxa, pois, no caso
de um aumento dela, os passivos e os ativos seriam elevados na mesma proporção, o que não
causaria impacto no resultado para o banco. O problema consiste no fato de que o banco
oferece ativos e passivos atrelados a diversos indexadores, como taxa Selic, taxa DI, IPCA,
IGP-M, TR ou Prefixados, que não tem indexação a taxa alguma.
Sendo assim, num caso hipotético, se todos os ativos estivessem indexados à Selic e
todos os passivos ao IGP-M, uma variação positiva na Selic, sem variação do IGP-M,
acarretaria um aumento do resultado para o banco, e no caso da queda da Selic, sem variação
do IGP-M, o resultado do banco seria menor.
Bancos brasileiros, de maneira geral, possuem um descasamento entre os indexadores
de seus ativos e passivos da seguinte maneira: seus ativos são prefixados e seus passivos
indexados à taxa DI. Isso ocorre, pois quem toma recursos do banco, em geral quer saber
quanto estará devendo a qualquer momento e a captação dos bancos em geral é feita indexada
à Taxa DI, que é a taxa média diária das operações de overnight entre instituições financeiras.
Essa taxa é a mais utilizada no mercado de capitais e representa o custo de oportunidade dos
bancos. Dessa forma quando um banco capta recursos indexados à Taxa DI, ele estará
captando à taxa válida no mercado interbancário, que é o custo mínimo que bancos
conseguem obter recursos.
Numa visão geral de um banco, como descrito anteriormente, a área de Gestão
Financeira/ALM tem como um de seus papéis assumir para si os riscos de mercado existentes
nas operações de captação e de empréstimo realizadas por todas as áreas comerciais do banco.
Dessa forma, as áreas comerciais, responsáveis pelo contato direto com o cliente (tomador ou
doador de recursos), concretizam os negócios e, por meio de um mecanismo conhecido como
Taxa de Transferência Interna (TTI), transferem os riscos de mercado dessas operações para
uma única área, a Gestão Financeira/ALM.
19
O risco de liquidez está ligado ao descasamento de prazos entre ativos e passivos do
banco e à possibilidade de o banco não possuir capital para honrar seus passivos nas datas
acordadas em contrato. Esse risco também é conhecido como gap risk ou gap de liquidez
(CHOUDHRY, 2007). Por exemplo, supondo que um banco que não possua patrimônio
próprio e tenha apenas dois passivos, no valor de R$1000,00 cada e que devam ser devolvidos
aos proprietários daqui a um ano (o primeiro passivo) e dois anos (o segundo passivo). O
banco poderia emprestar esses R$2000,00 que captou para apenas uma pessoa, mas esse
empréstimo poderia durar no máximo um ano, pois, caso contrário, o banco não teria recursos
para pagar o passivo com duração mais curta.
Esse raciocínio é muito simples no exemplo, porém em um caso real, um banco lida
com milhares de ativos e passivos em seu Balanço Patrimonial, e essa relação torna-se muito
mais complexa.
A liquidez é de extrema importância para um banco, pois é ela que garante a confiança
da instituição perante o mercado. Ninguém aplicaria seus recursos em uma instituição na qual
há desconfiança sobre sua liquidez, da mesma forma, seus clientes sacariam seus depósitos, o
que seria fatal para o negócio da empresa. Assim, a liquidez e o controle do seu risco devem
ser temas de alta importância na gestão de uma instituição financeira.
Tamanha importância se reflete também nas métricas exigidas para seu controle. O
Bank for International Settlements (BIS) criou para sua nova regulamentação, conhecida
como Basel III, duas medidas para esse controle. São elas o Liquidity Coverage Ratio (LCR)
e o Net Stable Funding Ratio (NSFR), para assegurar que os bancos possuam liquidez tanto
no curto como no longo prazo, mesmo em cenários de stress. (BANK FOR
INTERNATIONAL SETTLEMENTS, 2010).
1.1.2. Taxa de Transferência Interna (TTI)
A Taxa de Transferência Interna pode ser entendida simplificadamente como a taxa
mínima com que o banco pode gerar ativos ou passivos, incorporando nela as condições do
mercado e regulamentações do governo, sem que haja prejuízo para o banco (CHOUDHRY,
2007).
20
Essa taxa é definida pela Gestão Financeira/ALM e é enviada às áreas comerciais
como diretriz a ser seguida. Para operações pequenas, como a maioria dos empréstimos para
pessoa física em agências bancárias, as áreas comerciais recebem o valor da Taxa de
Transferência Interna por tabelas válidas por um período de tempo pré-determinado. Com
base nessa taxa, as áreas comerciais somam o spread, que pode ser entendido como diferença
entre a taxa de captação e a de empréstimo da operação, refletindo principalmente o risco de
crédito do cliente e o lucro que o banco espera obter com uma dada operação. Dessa forma,
para cliente cujo risco de crédito é mais alto, como uma pessoa física, o spread será mais
elevado do que outro para o qual esse risco seja menor.
Para operações de grande porte, como empréstimos para empresas multinacionais, essa
taxa é calculada no momento da operação, com base nas condições daquele instante do
mercado e o fluxo do processo é o seguinte:
a. O cliente entra em contato com a área comercial do banco para saber qual a
taxa cobrada ou oferecida pelo banco.
b. A área comercial entra em contato com a Gestão Financeira/ALM e pergunta
qual a Taxa de Transferência Interna para aquela operação, informando os
prazos e volumes dela.
c. A Gestão Financeira/ALM realiza o cálculo e passa o valor da Taxa de
Transferência Interna.
d. A área comercial, sabendo a Taxa de Transferência Interna, acrescenta a ela o
spread bancário, com base no perfil do tomador de recursos, e passa o valor
total (Taxa de Transferência Interna somada ao spread) para o cliente.
e. O cliente decide se aceita ou não as condições da operação.
O mecanismo da transferência do risco de mercado para a Gestão Financeira/ALM
pode ser melhor compreendido com o esquema de razonetes da Figura 1:
21
Por outro lado, as áreas comerciais devem arcar com o risco de crédito, proveniente da
inadimplência dos clientes. Nesse caso, esse risco está embutido no spread definido para a
operação de tal forma que, no caso do cliente não honrar sua dívida perante o banco, o spread
pelo risco de crédito das operações que foram pagas ressarcirão a instituição pelo cliente
inadimplente. A ideia nesse caso não é obter lucro por conta de uma taxa cobrada a mais, e
sim garantir que na média de todas as operações haverá pagamento para o banco.
Como conclusão desse raciocínio, percebe-se que a área de Gestão Financeira/ALM
tem como objetivo principal ser uma intermediária financeira, para garantir a estabilidade
estrutural do balanço da organização, posicionando-o no mercado da maneira mais adequada
possível, para que o processo como um todo gere resultado.
1.2. Política de Funds Transfer Pricing (FTP)
Entendido o conceito inicial de Taxa de Transferência Interna, existe outro conceito,
ligado dessa vez a liquidez, que pode ser incorporado a essa taxa para um melhor
funcionamento do banco.
Como explicitado anteriormente, a liquidez de um banco é um dos temas centrais de
sua gestão. É intuitivo perceber que ela é mais impactada quando se concede empréstimos de
prazo mais longo do que ao realiza-los por um prazo menor, já que o banco ficará sem esses
recursos em seu caixa por um período maior. Assim, conforme o prazo dos empréstimos se
estende, as taxas de juros cobradas se tornam mais elevadas. Inversamente, para captações, o
banco remunera melhor operações de duração maior (CHOUDHRY, 2007). Dessa forma,
aplicações como a poupança, que possui liquidez diária (os recursos podem ser sacados a
Figura 1 - Transferência de riscos de mercado para Gestão Financeira/ALM
(Elaborado pelo autor)
22
qualquer momento), tem rendimento menor quando comparado a um Certificado de Depósito
Bancário (CDB) cuja duração seja um ano sem liquidez, por exemplo.
Essa taxa cobrada a mais para empréstimos concedidos que apresentem prazo mais
longo pode ser entendida como um custo proveniente do impacto que esse empréstimo causa
na liquidez do banco.
Essa política de cobrança de taxas maiores para empréstimos mais longos e pagamento
de taxas maiores para captações mais longas é um conceito de grande valor para a atividade
bancária, uma vez que inibe a geração de empréstimos de longo prazo e incentiva a captação
de empréstimos mais longos, protegendo uma das partes mais importantes de uma instituição
financeira, sua liquidez (CHOUDHRY, 2007).
Além disso, para garantir a liquidez diária de um banco, este precisa ter certeza de que
sempre que algum cliente desejar reaver seus recursos, a instituição financeira terá condições
de fazê-lo. Para tanto, ela não pode emprestar todo o caixa que tem disponível, proveniente
das captações e de seu patrimônio líquido. Parte desses recursos deve ser separado e servir
como um coeficiente de segurança para garantir a liquidez da empresa (buffer de liquidez). É
evidente que existe um custo em relação a esses recursos não emprestados (GRANT, 2011).
Dessa forma, a Gestão Financeira/ALM, ao realizar o cálculo das Taxas de
Transferência Interna, inclui na conta mais duas taxas além do valor mínimo de mercado de
captação/empréstimo. A primeira, que diz respeito ao impacto da liquidez, dependendo do
prazo da operação em questão, e a segunda, que corresponde ao custo de oportunidade
proveniente da existência de um buffer de liquidez.
1.3. Problemas Encontrados
Dessa estrutura para a centralização dos riscos de mercado descrita anteriormente,
surgem dois problemas notadamente importantes. O primeiro diz respeito a como é calculado
o resultado financeiro da área de Gestão Financeira/ALM, e como erros nesse processo o
impactam, em geral, negativamente. O segundo trata do fato de que o fluxo desenhado para o
processo não apresenta etapa de controle, impossibilitando a constatação de desvios. Dessa
forma, não há garantia de que a metodologia que está por trás do processo está sendo
respeitada.
23
1.3.1. Resultado da área de Gestão Financeira/ALM
O resultado da área está ligado basicamente à relação entre as Taxas de Transferência
Interna (TTI) de captação e empréstimos, o valor utilizado para calcular o resultado é o que se
encontra nos contratos, que são assinados pelas áreas comerciais, e não pela Gestão
Financeira/ALM. Como não há um sistema que integre as funções do banco como um todo,
não há maneira de se garantir que as TTI passadas pela Gestão Financeira/ALM sejam
respeitadas no momento do preenchimento dos contratos pelas áreas comerciais.
Quando existe divergência entre a Taxa de Transferência Interna do contrato e a
passada pela Gestão Financeira/ALM, o prejuízo ou lucro é direcionado para o resultado da
última, e o spread das áreas comerciais também é afetado no sentido contrário, pois a relação
TTI somada ao spread da figura 1 é constante. Evidentemente, quando ocorrem erros no valor
dessas taxas, na maioria dos casos elas estão subestimadas, e o prejuízo recai para a Gestão
Financeira/ALM.
1.3.2. Desrespeito às políticas de Taxa de Transferência Interna
Desrespeitadas as taxas previamente definidas pela Gestão Financeira/ALM, as áreas
comerciais não estão respeitando a política de FTP definida. Essa política é fundamental para
a estratégia do banco na medida em que ela é uma das formas de garantir a solidez do balanço
da instituição.
O problema relacionado com o resultado das áreas tem impacto apenas para a Gestão
Financeira/ALM e para os setores comerciais. Entretanto, o problema em relação ao
desrespeito às políticas de Taxa de Transferência Interna impacta a estabilidade do balanço do
banco como um todo, sendo assim um tema de grande relevância para a organização.
1.4. Objetivo do Trabalho
O banco possui diversas bases de dados que armazenam as informações referentes a
cada contrato realizado. Dentre essas informações consta a Taxa de Transferência Interna
24
dessas operações. Assim, é possível desenvolver um sistema que calcula quais foram as TTI
passadas pela Gestão Financeira no momento do fechamento de cada contrato.
Para tanto, como será detalhado nos capítulos adiante, esse não é um cálculo simples.
O sistema deve ser capaz de buscar as diversas características dessas operações nas bases de
dados da instituição, como datas de pagamento das parcelas e seus respectivos montantes,
buscar também a curva de taxa de juros correspondente a cada data que possui fluxo de
pagamento, para em seguida obter, por meio de interpolação, o valor da taxa de juros de
mercado válida para cada fluxo de pagamento de cada contrato. A partir disso, o sistema deve
definir qual taxa deveria ter sido cobrada para cada fluxo de pagamento e, portanto, qual
seriam seus valores futuros. Com esses dados, é possível realizar a estimação da taxa interna
de retorno desse contrato, que é equivalente à sua Taxa de Transferência Interna.
Além disso, por se tratar da análise das bases de dados de um grande banco de varejo,
a quantidade de informação a ser estudada é imensa. Portanto, faz-se necessário o uso de
métodos de desenvolvimento de sistemas de informação, com o objetivo de buscar uma forma
estruturada de organizar o problema, principalmente no que diz respeito ao seu escopo.
Outra dificuldade proveniente do grande volume de dados a serem verificados é a
quantidade de informações retornadas pelo sistema, que, dependendo do tipo de ocorrência de
erro em determinado mês, pode ser muito elevada, comprometendo a análise das respostas do
sistema. Dessa maneira, para que a geração de relatórios periódicos realizada pelo sistema
garanta bons resultados, o estudo da metodologia de design de interfaces é relevante
permitindo que a interação entre usuário e software seja satisfatória.
Sob uma perspectiva mais ampliada, esse sistema pode ser considerado uma
ferramenta de controle de qualidade da atividade de centralização dos riscos de mercado do
banco, pois garante que essa etapa do serviço prestado pela instituição está respeitando a
metodologia de FTP previamente definida. Assim, o sistema seria inserido no atual processo,
a fim de acrescentar a ele mais um ponto de contato entre a Gestão Financeira/ALM e as áreas
comerciais, no qual ocorre a correção das operações cuja taxa não está correta, havendo
consenso entre as partes envolvidas.
25
2. Fundamentação Teórica
Esse capítulo tem como objetivo descrever os conceitos, técnicas e métodos já
estudados anteriormente por outros autores a respeito de temas que apoiam o
desenvolvimento do presente trabalho.
São buscados tanto novos conhecimentos que enriquecem o conteúdo do projeto e
apoiam seu desenvolvimento, como também explicados alguns conceitos não triviais que
podem ser citados ao longo do trabalho, para facilitar sua compreensão.
Pelo fato de se tratar do projeto de desenvolvimento de um sistema de informação, os
conceitos referentes ao processo de Análise de Requisitos são úteis para a obtenção de um
enunciado completo para um projeto desse tipo.
Como o sistema realiza cálculos de Taxa de Transferência Interna de operações, dois
conceitos devem ser explicados a respeito desses cálculos. O primeiro é a taxa interna de
retorno de um fluxo de caixa uma vez que a TTI, se analisada sem o modelo de gestão do
banco que a envolve, é um cálculo de uma TIR. O segundo refere-se ao modelo adotado pelo
banco para definir suas Taxas de Transferência Interna, o Matched-maturity marginal cost of
funds, já que a adoção desse modelo impacta a forma como os cálculos são feitos.
Outros conceitos detalhados para apoiar o entendimento da descrição do cálculo da
TTI são o do funcionamento do Fundo Garantidor de Crédito (FGC), do depósito compulsório
exigido pelo Banco Central do Brasil e do derivativo DI-Futuro.
Além disso, pelo fato do projeto se tratar do desenvolvimento de um sistema utilizado
para aprimorar um processo, no caso o de centralização dos riscos de mercado em uma área
única de um banco, outro conceito útil para o melhor entendimento é o da gestão de processos
com base no ciclo PDCA, metodologia de gestão que se enquadra no processo analisado nesse
trabalho e facilita a compreensão do ambiente em que o ele está inserido.
2.1. Taxa interna de retorno
Segundo Lawrence J. Gitman (2004), a taxa interna de retorno (TIR) é uma forma se
de analisar o retorno de investimentos. Essa metodologia de análise busca encontrar uma taxa
26
de juros única que, aplicada a um dado fluxo de caixa, faça o valor presente do mesmo ser
nulo.
Podemos entender como fluxo de caixa, assim como definiu Securato et al. (1999),
pelo conjunto de entradas e saídas dos recursos ao longo do intervalo de tempo que
compreende o período do projeto ou investimento.
Assim, considerando-se que um projeto em que é necessário um investimento em
01/01/2011 de R$ 20.000,00, mas que dá um retorno de R$5.000,00 pelos próximos cinco
anos, o fluxo de caixa seria representado como mostra a Figura 2:
Figura 2 - Exemplo de fluxo de caixa
(Adaptado de GITMAN, 2004)
Nesse caso, a taxa interna de retorno seria a taxa com a qual se trouxesse a valor
presente (presente nesse caso é jan/2011) todos os fluxos dos anos seguintes, e a soma de
todos esses valores presentes fosse igual ao seu desembolso inicial, ou seja, R$20.000,00. A
fórmula que calcula essa taxa é a seguinte:
A resolução da equação acima, de maneira geral, envolve cálculos complexos e
matemática sofisticada, como o método Newton-Raphson de solução numérica de equações
(ARENALES; DAREZZO, 2008).
27
No caso da resolução dessa equação, encontra-se i = 7,93%.
Para um caso genérico de fluxo de caixa, a fórmula utilizada para calcular a taxa de
retorno i é a seguinte:
Uma dificuldade maior ao avaliar empréstimos no mercado financeiro diz respeito ao
fato de que a taxa interna de retorno de um investimento, depende do prazo do mesmo, ou
seja, para o caso de um banco emprestando uma quantia para um cidadão, a taxa de retorno
que o banco exigirá para realizar o negócio irá depender de como todo o mercado está
exigindo de retorno para cada período de tempo, chamada de taxa de juros do mercado. No
Brasil, a taxa de juros mais utilizada é a taxa DI. Como exposto anteriormente, ela é o valor
da média diária das operações de overnight (ou seja, cuja duração do contrato é de apenas um
dia) entre instituições financeiras, que é feita a partir de um produto bancário chamado CDI
(Certificado de Depósito Interbancário), que só existe para negócios entre instituições
financeiras (SECURATO et al., 1999).
Esse índice é divulgado diariamente pela CETIP (Central de Custódia e Liquidação
Financeira de Títulos), que é uma clearing house, ou casa de custódia, que, entre outros
serviços, funciona como um banco de dados onde todas as operações de CDI são armazenadas
(CENTRAL DE CUSTÓDIA E LIQUIDAÇÃO FINANCEIRA DE TÍTULOS, 2012). A
partir dele é que se ajustam os prêmios que serão pagos aos contratos indexados à taxa DI.
Entretanto, existe outro mercado, o de derivativos, mais especificamente o DI-Futuro,
que negocia contratos do valor da taxa DI em alguma data futura. Esse contrato será explicado
no próximo item, mas é interessante dizer que a partir das taxas negociadas desse contrato de
DI-Futuro, que são definidos os retornos exigidos pelos bancos para empréstimos até
diferentes datas, pois elas representam a crença do valor da taxa DI média desde a data de
início a até a data de vencimento do contrato de DI-Futuro (SECURATO et al., 1999).
28
2.2. DI-Futuro
Segundo a BM&F Bovespa (2012), o contrato de DI-Futuro é um derivativo, que
opera a variação da taxa DI divulgada pela CETIP, do início do contrato até o seu
vencimento. Seu resultado é obtido da diferença entre a taxa que foi negociada e a taxa
efetivamente realizada durante seu período de vigência.
Esses derivativos são negociados com uma contraparte central, a própria BM&F
Bovespa e são muito líquidos, ou seja, existem diariamente milhares de negociações nesse
mercado.
Esses contratos são padronizados no que diz respeito à data de vencimento, o que
significa dizer que existe uma regra para determinação dessas datas para as operações
realizadas a cada dia. Diariamente são negociadas operações cuja data de vencimento é o
primeiro dia útil dos quatro meses subsequentes à data em que a operação foi realizada, além
daqueles cuja data de vencimento é o primeiro dia útil dos meses que configuram virada de
trimestre (BM & F BOVESPA, 2012).
Dessa forma, como esse derivativo possui muita liquidez no mercado e possui datas de
vencimento com certo padrão, as taxas pelas quais essas operações são negociadas revelam as
expectativas do mercado financeiro com relação à taxa juros da data de inicio à sua data de
vencimento (SECURATO et al., 1999).
Os bancos usam essa informação para precificar suas operações de empréstimo, e essa
função que relaciona o vencimento do contrato com a expectativa da taxa DI média até essa
data é conhecida como Curva Pré, pois ela indica o custo de um empréstimo prefixado feito
naquele instante a uma taxa de 100% da taxa DI. A partir dos diversos vencimentos de DI-
Futuro é possível interpolar os vértices desses vencimentos para poder encontrar a taxas de
juros, justas para o mercado, para qualquer prazo de operação (SECURATO et al., 1999).
Como a taxa de negociação dos contratos de DI-Futuro muda constantemente ao longo
do dia, é possível que se obtenham taxas de juros diferentes para operações exatamente iguais
caso sejam feitos em momentos distintos do dia.
Como comentado no item anterior, uma dificuldade ainda maior na modelagem de
problemas que envolvam operações do mercado financeiro diz respeito exatamente a essa
questão. A taxa interna de retorno exigida por operações com prazos diferentes são distintas,
29
pois o mercado tem expectativas em relação ao que acontecerá com a taxa DI ao longo do
tempo (SECURATO et al., 1999).
2.3. Descrição do cálculo das Taxas de Transferência Interna
O objetivo desse item é detalhar o funcionamento de alguns mecanismos existentes no
mercado financeiro brasileiro, notadamente o depósito compulsório do Banco Central do
Brasil e o Fundo Garantidor de Crédito. Esses dois mecanismos tem impacto direto no cálculo
da Taxa de Transferência Interna e a sua compreensão é fundamental para o entendimento do
processo de centralização dos riscos de mercado de um banco em uma área única.
Depósito compulsório
O Depósito Compulsório é um mecanismo do governo, mais especificamente do
Banco Central do Brasil, para controle e direcionamento da política econômica do país.
A ideia do Depósito Compulsório, segundo o próprio Banco Central do Brasil (2012) é
que parte das captações dos bancos seja depositada com o governo. A alíquota exigida pode
variar, dependendo da situação econômica do país ou do tamanho da instituição financeira.
Esse mecanismo pode servir tanto para o governo retirar quanto injetar recursos na economia,
incentivando-a ou não. É importante ressaltar que o governo remunera os recursos exigidos
pelo compulsório.
Essa é também uma forma de o governo reduzir alavancagens excessivas por parte dos
bancos, evitando que eles emprestem todos os recursos que captaram, aumentando seus riscos.
Todavia, esse mecanismo de controle não deve sofrer mudanças bruscas, uma vez que isso
pode desorganizar a atividade bancária (MANKIW, 2009).
Outra utilização para o Depósito Compulsório é como forma de incentivo de setores
específicos da economia. Por exemplo, o governo brasileiro já liberou os bancos de grande
porte de recolhimento de parte do compulsório caso essa verba fosse destinada a empréstimos
para bancos pequenos e médios. Outra medida do governo, essa durante o ano de 2012,
destinou parte do compulsório dos bancos para o crédito de veículos, para incentivar a venda
30
desses bens e aquecer o setor automotivo, que estava passando por dificuldades pelo excesso
de estoque das montadoras (BANCO CENTRAL DO BRASIL, 2012).
FGC
O Fundo Garantidor de Crédito (FGC) é uma instituição privada, sem fins lucrativos,
que tem como objetivo proteger contrapartes de instituições financeiras em contratos que o
banco captou recursos, no caso dele não possuir condições de arcar com essa dívida.
(BANCO CENTRAL DO BRASIL, 2012).
Esse fundo tem como finalidade, além de proteger os investidores do mercado
financeiro até o limite estipulado, contribuir para a estabilidade do Sistema Financeiro
Nacional, e evitar uma crise financeira sistêmica (BANCO CENTRAL DO BRASIL, 2012).
O fundo garante até R$70.000,00 aos credores do banco em caso de impossibilidade
da instituição devedora pagar a dívida, ou seja, caso o credor possua um contrato de até
R$70.000,00, esse fundo garante o pagamento caso o banco não a pague. Caso o volume dela
seja maior, o fundo ressarce o investidor no valor de R$70.000,00 (FUNDO GARANTIDOR
DE CRÉDITO, 2012).
Em contrapartida, os bancos que fazem parte desse fundo devem realizar depósitos
mensais correspondentes a 0,0125% do saldo garantido pelo fundo. Dessa forma, caso o
banco capte recursos por meio de algum instrumento garantido pelo FGC, como um CDB
(Certificado de Depósito Bancário), 0,0125% desse valor mais os juros correspondentes ao
período que os recursos já ficaram em poder do banco deverão ser pagos mensalmente ao
fundo como forma de contribuição (FUNDO GARANTIDOR DE CRÉDITO, 2012).
Segundo o próprio FGC (2012), os tipos de depósito que são objeto de garantia do
fundo garantidor de crédito para as contrapartes dos bancos são os seguintes: depósitos à vista
(como depósitos em conta corrente), depósitos de poupança, depósitos à prazo (como o CDB),
letras de câmbio, letras imobiliárias, letras hipotecárias, letras de crédito imobiliário e
operações compromissadas cujo título de que é objeto de recompra no prazo de vencimento
da operação tenha sido emitido após o dia 8 de março de 2012.
Esse fato claramente impacta a Taxa de Transferência Interna de um banco, pois esse
custo que deve ser pago ao FGC necessita ser incorporado ao custo dos empréstimos que a
instituição financeira realiza à aos clientes.
31
Ainda de acordo com o Fundo Garantidor de Crédito (2012), existe também outra
modalidade de garantia de crédito chamada de Garantia Especial. Essa garantia está ligada a
um tipo de dívida emitida por bancos chamada de Depósito a Prazo com Garantia Especial
(DPGE), que é um instrumento muito parecido com um CDB, porém a garantia dada pelo
FGC a esse tipo de dívida é de R$20.000.000,00. Esse tipo de instrumento é utilizado
principalmente por bancos pequenos e médios, que apresentam risco de crédito mais elevado,
como forma de emitir dívidas sem que essas incorporem um prêmio de risco muito alto em
suas taxas, captando recursos a um custo mais baixo. Os bancos de grande porte do país,
entretanto, não emitem esse tipo de dívida, pois seu risco de crédito é baixo.
Na realidade, bancos de grande porte do país fazem uso de outro mecanismo para
captar recursos, as chamadas Letras Financeiras. Esse instrumento, cujo valor mínimo de
emissão é de R$300.000,00, não possui garantia do FGC, o que barateia o custo de captação
desses bancos. Eles somente são capazes de fazer isso, pois seu risco de crédito é baixo.
Cálculo da Taxa de Transferência Interna para ativos
Segundo a modelagem proposta pelo Banco Central de Brasil (2000) no seu relatório
Juros e Spread Bancário no Brasil, mais especificamente em, A Cunha Fiscal Sobre a
Intermediação Financeira (CARDOSO; KOYAMA, 1999), o spread bancário geral no
mercado brasileiro é composto por sete itens:
o Redutor do custo de captação por conta a existência do depósito à vista.
o Custo do Fundo Garantidor de Crédito.
o Custo do depósito compulsório.
o Despesas administrativas dos bancos.
o Tributos.
o Despesa de Inadimplência, proveniente do risco de crédito que os bancos
assumem ao realizar empréstimos.
o A própria margem de lucro líquida que o banco deve realizar.
Nesse caso, o Banco Central do Brasil está analisando o sistema financeiro como um
todo. Entretanto, a TTI corresponde apenas ao mecanismo de centralização dos riscos de
oscilações no mercado financeiro e não do risco de crédito ou de variação das alíquotas de
impostos, cujos riscos são gerenciados por outras áreas. Assim, para o cálculo da TTI, é
necessário considerar apenas os três primeiros itens definidos acima. Como simplificação,
32
ainda pode-se adotar que o redutor de custo por conta dos depósitos à vista não são relevantes
na medida em que a parcela dessa captação que apresenta funding livre, ou seja, não tem
destinação específica definida pelo governo, é muito pequena.
Dessa forma, pode-se simplificar o cálculo do Banco Central do Brasil (2000) e
considerar apenas os custos provenientes da contribuição ao FGC e do depósito compulsório
na captação, para encontrar-se o valor para a TTI de um ativo.
Supondo que o governo federal tenha exigido uma alíquota de 32% de depósito
compulsório, que é um valor muito próximo aos exigidos atualmente para CDB (Certificado
de Depósito Bancário) para bancos de grande porte. Além disso, ainda existe a alíquota de
0,0125% por mês, sobre o volume da captação, para o Fundo Garantidor de Crédito (FGC).
Assumindo ainda que a taxa DI, que pode ser entendida como o custo de captação para
bancos grandes, se mantenha em 9% ao ano durante um ano e que não exista diferença entre a
taxa Selic (que remunera os recursos do compulsório) e a taxa DI, qual seria o custo mínimo
de um ativo de um ano?
O problema proposto acima é a maneira como se calcula a Taxa de Transferência
Interna para ativos, uma vez que o custo dos passivos é um dado de mercado, que é
influenciado pela situação econômica do país, a política fiscal do governo, entre outros
aspectos. A modelagem em um diagrama de fluxos de caixa seria a apresentada na Figura 3:
Figura 3 - Fluxo de caixa para cálculo da TTI para ativos
(Adaptado de BANCO CENTRAL DO BRASIL, 2000)
33
As flechas vermelhas representam o passivo que o banco gerou a uma taxa de 9% ao
ano. As flechas verdes e azuis representam os ativos que serão gerados com os recursos
provenientes da captação. A flecha azul representa o percentual que foi depositado como
Depósito Compulsório no Banco Central e teve remuneração igual à Selic, enquanto a flecha
verde foi remunerada à taxa que queremos descobrir. As flechas pretas são os desembolsos
realizados pelo banco para o Fundo Garantidor de Crédito.
Como as entradas e saídas de capital na data de início são iguais, a equação que nos
leva à Taxa de Transferência Interna para os ativos é a seguinte:
∑
Onde,
∑ = Somatória dos valores futuros (data 12) de cada um dos fluxos do FGC.
Esses valores usam como custo de oportunidade a taxa de captação, ou seja, os 9% ao
ano da taxa DI.
= Valor futuro do passivo do banco, ajustado pela taxa DI de 9% ao ano.
Valor futuro do Depósito Compulsório (32% do total captado)
ajustado pela Selic, de 9% ao ano.
Valor futuro do ativo gerado (68% do total captado) pelo banco,
ajustado pela taxa que se está procurando saber.
Realizando-se as contas, obtém-se o resultado de TTI dos ativos em 9,23% ao ano.
Essa taxa representa aproximadamente 102,5% da taxa DI estipulado para o período (de 9%
ao ano).
É interessante ressaltar que os bancos em geral definem suas taxas como um
percentual da taxa DI. Essa metodologia faz sentido na medida em que a taxa DI varia
diariamente e os contratos de DI-Futuro variam inclusive ao longo de um dia. Assim, ao se
precificar operações em um percentual da taxa DI, esse valor se manterá constante, mesmo
que a taxa DI varie (GRANT, 2011).
34
2.4. Políticas de Taxa de Transferência – Matched-maturity marginal cost of funds
Como exposto no início do trabalho, a função básica de um banco é realizar um
processo conhecido como intermediação financeira. Esse processo busca encontrar, no
mercado, agentes superavitários, para que esses emprestem recursos ao banco, em troca de
alguma remuneração futura. Depois disso, a instituição busca, também no mercado, agentes
deficitários que demandam recursos, e os obtém em troca de alguma remuneração futura paga
ao banco. Dessa forma, o que o banco faz é uma ligação entre esses doadores e tomadores
presentes no mercado, buscando obter lucro ao realizar essa ligação.
Esse processo seria facilmente controlável caso todas as operações de captação e
empréstimo fossem casadas, ou seja, para cada captação houvesse um empréstimo que
possuísse o mesmo prazo e o mesmo volume. Assim, o único trabalho para o banco seria
realizar a ligação entre os dois agentes do mercado. Entretanto, evidentemente um banco
capta recursos em diversos prazos e volumes e doa também em diversos prazos e volumes,
causando descasamento entre esses parâmetros.
O banco deve encontrar uma maneira então de conseguir captar doá-los numa
proporção, incluindo prazos e volumes, que sustente a capacidade de pagamento de suas
captações. A quantidade de recursos que o banco capta ou empresta evidentemente está
intimamente ligada aos preços pagos pela captação e aos recebidos pelos empréstimos, assim,
o banco deve construir uma tabela que precifique o custo de ativos e passivos que sustente o
equilíbrio entre os prazos e volumes de recursos que entram e saem do banco.
Uma metodologia para se fazer isso é a sugerida pelo Bank for International
Settlements (2011) denominada de Matched-maturity marginal cost of funds.
Essa metodologia se baseia em determinar uma curva de referência para a captação de
recursos no mercado, baseada em uma taxa flutuante, ou seja, a intenção é definir, para
diversos prazos, quais são as taxas que o banco deve praticar para conseguir captar recursos e
transformar esse conjunto de taxas prefixadas em taxas que estejam explicitas em um
percentual da taxa DI, no caso de instituições financeiras que estejam operando no mercado
brasileiro (GRANT, 2011).
Essa abordagem traz duas vantagens claras, que são a independência em relação às
oscilações do mercado e o estabelecimento de um patamar para as taxas nas quais as
operações, tanto de captação como de empréstimo, devam ser realizadas.
35
A primeira vantagem diz respeito ao fato de, como explicado anteriormente, a taxa DI
utilizada pelo mercado para precificar suas operações possuir certa volatilidade, uma vez que
os contratos de DI-Futuro são negociados constantemente ao longo do dia na BM&F
Bovespa, e as taxas nas quais eles são feitos variam de acordo com as expectativas do
mercado naquele momento. Assim, caso um banco definisse uma taxa prefixada, ela deveria
ser atualizada várias vezes ao longo do dia pelo fato da taxa DI variar constantemente
(GRANT, 2011).
Portanto, quando um banco define a sua curva de captação com base em taxas
expressas em um percentual da taxa DI, ele não necessita atualizá-la com tanta frequência,
uma vez que os valores de sua curva devem ser determinados com base nas taxas que o
mercado exige para doar recursos para a tal instituição, taxas essas que são influenciadas
principalmente pela confiança que ela apresenta perante o mercado, ou seja, qual o risco de
crédito que o mercado acredita que o banco possua e pelas condições macroeconômicas do
ambiente. Esses dois elementos, a menos que haja um raro acontecimento de ruptura de
mercado, mudam muito lentamente, o que permite à instituição financeira manter sua curva de
captação por períodos mais longos de tempo caso ela seja expressa em um percentual da taxa
DI (GRANT, 2011).
A segunda vantagem trata-se do estabelecimento de um patamar, tanto para a captação
como para os empréstimos. Isso significa que, a partir do momento em que um banco define
essa curva, ele sabe que não deve tomar recursos em taxas maiores do que a especificada para
o prazo da operação, pois estaria pagando mais por um recurso que poderia conseguir por um
preço melhor, nem dar recursos a uma taxa menor do que a definida pela captação, pois
estaria tendo prejuízo caso se analise que os recursos dessa operação são provenientes de uma
captação cujo preço é maior do que o recebido pelo empréstimo. Seria como uma indústria
produzir bens e vende-los a um preço abaixo do custo de fabricação (GRANT, 2011).
No caso do Brasil, ainda há outro complicador, que é a presença do Fundo Garantidor
de Crédito e do depósito compulsório no Banco Central. Como explicado, esses dois fatores
aumentam ainda mais o custo de geração de ativos, o que na prática leva à formação de outra
curva, que se baseia na de captação no mercado. Então, complementando o raciocínio do
parágrafo anterior, é abaixo dessa curva de geração de ativos que não faz sentido para a
instituição financeira fazer um empréstimo (BANCO CENTRAL DO BRASIL, 2000).
36
O que se percebe ao construir a curva de captação no mercado, é que as taxas exigidas
para se conseguir captar recursos crescem conforme o prazo da captação aumenta, ou seja,
operações que durarão, por exemplo, três meses apresentam taxas de remuneração menores
que operações de prazo de um ano, que por sua vez têm taxas menores que contratos de cinco
anos. Esse fato pode ser explicado pelo risco de liquidez dos bancos. Quanto mais longo o
empréstimo que um banco oferece, seus recursos ficarão fora do caixa por mais tempo e,
consequentemente, sua condição de honrar dívidas ficará diminuída por um período mais
prolongado. Então, é natural que se exija uma taxa mais elevada por operações mais longas, o
que acarreta em uma curva de captação inclinada positivamente (BANCO CENTRAL DO
BRASIL, 2000).
2.5. Ciclo PDCA
Dos diversos “modelos de melhoria” existentes atualmente, a maioria deles se moldou
a partir dos conceitos inicialmente propostos por William Edwards Deming, e denominados
pelo último como Ciclo de Shewhart, que é mais conhecido como ciclo PDCA (PANDE;
NEWMAN; CAVANAGH, 2001).
Além de um processo de melhoria, o PDCA também pode ser usado como um modelo
de gestão dos processos existentes em uma determinada organização, como forma de
manutenção da qualidade (CAMPOS, 1998).
O significado da abreviação PDCA é plan, do, check, act. Cada um dos atributos desse
ciclo pode variar um pouco de acordo com a finalidade para qual foi adotado. Dessa forma,
abaixo está descrito cada um dos atributos para o caso de um modelo de manutenção da
qualidade:
Plan: Definição de um modelo de trabalho padronizado, conhecido como
procedimento operacional padrão.
Do: Execução do procedimento operacional padrão.
Check: Verificação da efetividade do procedimento operacional padrão
Act: Correção de sintoma de falha ou ação na causa da falha.
Para o caso do gerenciamento para manter a qualidade de um processo usando o ciclo
PDCA, algumas vezes a sigla é mudada para ciclo SDCA, no qual o S corresponderia a
37
Standard, ou seja, padronizar, dado que muitas vezes o grande objetivo a ser atingido é
desenhar um procedimento uniformizado que apresente efetividade (CAMPOS, 1998).
2.6. Análise de Requisitos
Para o desenvolvimento de um software, existem diversas metodologias que visam
padronizar as etapas de desenvolvimento, com o objetivo de que o modelo possa ser replicado
em diversos casos.
Ralph M. Stair (1996) propõe uma subdivisão ampla para a construção de um software
em Projeto Lógico, que corresponde à concepção de seus requisitos funcionais e propósitos, e
Projeto Físico, no qual se especifica as características dos recursos necessários para
implementar o Projeto Lógico.
Outro modelo com é o Praxis, criado por Wilson de Pádua Paula Filho (2003). Essa
sigla significa Processo para Aplicativos Extensíveis Interativos, ou seja, é um modelo de
processo padronizado que tem como objetivo dar suporte ao desenvolvimento de softwares.
Uma característica recorrente desses modelos é a existência de uma etapa conhecida
como análise de requisitos, na qual se busca definir em detalhes qual o escopo do projeto que
está sendo elaborado. Essa é uma etapa de grande utilidade, pois proporciona a equipe de
trabalho uma visão abrangente de todo o projeto, de modo que, quando este se encontra em
fase de desenvolvimento propriamente dito, como a programação das interfaces ou o
desenvolvimento dos bancos de dados, tudo o que realmente deve ser feito já está definido.
Esses modelos, de maneira geral, podem ser divididos em quatro grandes estruturas,
chamadas de fases, descritas a seguir (PAULA FILHO, 2003):
Concepção
Etapa em que se busca conhecer as necessidades existentes para usuários que
justifiquem o desenvolvimento de um software.
Elaboração
38
A partir do momento em que está definido que será desenvolvido o software, busca-se
detalhar as características do produto que será oferecido, para se obter um modelo conceitual
do projeto.
Construção
Esta fase consiste no desenvolvimento efetivo de um sistema com base nas
características que foram definidas anteriormente.
Transição
Esta etapa põe o produto desenvolvido em contato com os usuários, de modo que se
possa realizar testes e treinamentos.
Uma constante nesses modelos de desenvolvimento de software é a existência de uma
etapa muito importante dentro das fases de concepção e de elaboração chamada de Análise de
Requisitos, que será mais bem descrita a seguir.
A análise de requisitos pode ser entendida como uma maneira de obter uma descrição
completa quanto às características que um determinado software em desenvolvimento
possuirá. Dessa forma, é possível de se documentar e validar todas as características que o
cliente terá acesso quando o software estiver pronto (PAULA FILHO, 2003).
Esse documento possui grande utilidade para o desenvolvimento do sistema na medida
em que a partir dele é possível definir com clareza qual o seu objetivo, sua necessidade de
desempenho, como será a interação com os usuários e com outros sistemas e quais são os seus
limites de atuação. Assim, o desenvolvedor do software tem a capacidade de enxergar de
maneira ampla todos os requisitos que devem ser atingidos, e a partir daí, pode desenvolver
uma estratégia para a sua construção (PAULA FILHO, 2003).
Os requisitos de um sistema devem possuir algumas características que garantam sua
qualidade, para que o projeto como um todo não seja afetado negativamente. Dessa forma,
eles devem ser completos e corretos, descritos de maneira precisa, possíveis de serem
atingidos, realmente necessários, únicos, não havendo ambiguidade em sua definição e cujo
atingimento do objetivo seja verificável (WIEGERS, 2003).
39
Outra importância da análise de requisitos é que, ao se documentar todo o escopo do
projeto e se validar com os clientes do software, ocorre um alinhamento entre as expectativas
dos clientes e a proposta real do software. É fundamental, então, que exista a participação dos
clientes durante essa análise.
O grande risco ao qual se está exposto na elaboração do levantamento de requisitos é
não alinhar totalmente as expectativas do cliente com o conteúdo do software que está sendo
desenvolvido. Esse risco é grande por dois motivos: causará insatisfação do cliente caso o
sistema seja entregue sem todas as características que ele esperava que obtivesse e pode
causar retrabalho (e consequente perda de eficiência do projeto), caso algum requisito seja
incluído ou excluído do escopo do projeto em alguma etapa mais avançada (WIEGERS,
2003).
Ainda segundo Paula Filho (2003), a Análise de Requisitos possui oito atividades que
apresentam uma ordem a ser respeitada, como é mostrado no Fluxograma 1:
40
Como se pode notar pela figura, esse é um processo iterativo, então, caso não se tenha
chegado a requisitos satisfatórios na primeira rodada, ou seja, que descrevam com precisão
todo o escopo do projeto, deve-se reiniciar o processo partindo-se da solução até o momento
encontrada, e percorre-lo até que o projeto esteja bem descrito.
2.6.1. Determinação do contexto
É a atividade na qual tenta se entender o contexto no qual o software se inserirá, com o
intuito de se conhecer as características de onde atuará. É uma atividade muito importante
para se ter um primeiro contato com todo o ambiente que envolverá o desenvolvimento do
Fluxograma 1 - Atividades da Análise de Requisitos
(PAULA FILHO, 2003)
41
software, as particularidades da situação, as quais poderão ter influência durante todo o
processo de desenvolvimento do sistema (PAULA FILHO, 2003).
Segundo Feliciano Neto (1996), os subsistemas que devem ser analisados são o
institucional, que engloba as crenças e valores das empresas, o físico, composto pelos
recursos físicos que ela possui, como terrenos ou equipamentos, o social, representado pelo
conjunto das pessoas que formam a organização, o formal, determinado pela estrutura
organizacional da empresa, o de informação, define como é feito o fluxo de informações
dentro da organização e o de gestão, responsável pelo planejamento, execução e controle na
organização.
2.6.2. Definição do escopo
Atividade na qual se define o escopo do projeto em termos de missão, limites,
benefícios, referências e aspectos gerenciais.
A missão diz respeito ao valor acrescentado pelo software para quem o utiliza. É
interessante que seja expressa em um parágrafo curto e direto. Os limites, como o próprio
nome diz, determina até onde o sistema atuará, ou seja, mostra que tipo de atividades que o
sistema não fará. Os benefícios são o conjunto de aspectos que trazem vantagem ao cliente e
que justificariam o investimento no desenvolvimento de um software. As referências são o
conjunto de materiais que podem ser consultados para que haja uma melhor compreensão dos
requisitos. Aspectos gerenciais são condições externas, como custos e prazos, que devem ser
respeitadas durante o desenvolvimento do projeto (PAULA FILHO, 2003).
Quando se define o escopo, estabelece-se um alinhamento entre as expectativas dos
clientes e o que será o resultado final do produto. Essa delimitação contribui para que pedidos
irrealistas sejam descartados, a menos que haja mudanças em parâmetros como orçamento,
tamanho e capacidade da equipe ou tempo de duração do projeto (WIEGERS, 2003).
2.6.3. Definição dos requisitos
O que se busca nessa atividade é identificar os casos de uso e como é feito o
relacionamento entre eles e os atores.
42
Caso de uso é uma representação de uma função do produto. Desse modo, o conjunto
de casos de uso de um produto define completamente quais são as funções do produto
(PAULA FILHO, 2003). Pode-se entender também que um caso de uso é a descrição da
interação dos atores externos com o sistema (WIEGERS, 2003).
Atores são os papéis que cada usuário assume ao utilizar o sistema. Um usuário pode
ser representado por vários atores, caso utilize o sistema com diversos intuitos e um ator pode
ser representação de vários usuários, se diversas pessoas realizarem a mesma tarefa com o
sistema. (PAULA FILHO, 2003).
A relação entre atores e casos de uso é expressa por meio de um diagrama conhecido
como Diagrama de Contexto. Nesse diagrama, eles são representados pelos símbolos da
Figura 4:
O Diagrama de Contexto pode também ser entendido como um modelo que representa
como o novo sistema se encaixa no contexto em que está sendo inserido. Assim, define certos
limites em relação ao que é externo a ele, como os usuários e os outros sistemas. (WIEGERS,
2003).
2.6.4. Detalhamento dos requisitos de interface
A atividade comtempla o detalhamento de cada tipo de interface do produto com
sistemas os usuários. Nesse momento, é muito importante que se detalhe as interfaces gráficas
do produto. Esboços são muito importantes para que o cliente possa ter um primeiro contato,
e uma ideia de como será sua interação com o produto final. Esse esboço serve para a
validação por parte do cliente (PAULA FILHO, 2003).
Figura 4 - Representação de caso de uso e ator
(PAULA FILHO, 2003)
43
2.6.5. Detalhamento dos requisitos funcionais
O que se entende por requisito funcional é uma tarefa que o produto realiza para
beneficiar o usuário, ou seja, cada um desses requisitos pode ser descrito como um caso de
uso do sistema. Para detalhar os requisitos funcionais então, é necessário detalhar cada caso
de uso. Uma forma de fazê-lo é, a partir de cada um deles, definir Fluxos de Casos de Uso,
que correspondem a uma descrição de cada etapa de sua realização no sistema.
Segundo Paula Filho (2003), esse fluxo deve definir inicialmente as chamadas
precondições, que correspondem ao estado que o sistema deve estar para que determinado
caso de uso seja realizado. Depois disso, define-se a sequência natural de passos para a
realização dele. Finalmente, podem ser definidos os sub-fluxos, que são os caminhos
alternativos para cada caso de uso.
2.6.6. Detalhamento dos requisitos não-funcionais
Requisitos não-funcionais são condições de contorno que devem ser respeitadas ao se
desenvolver o sistema, tanto no que diz respeito a desempenho, quanto no que tange as
características de qualidade.
No detalhamento desses requisitos, é imprescindível que haja uma análise quantitativa
deles, mesmo que não muito precisa na primeira versão do software, para que seja possível
definir reais condições de contorno. Por exemplo, a velocidade de resposta ao usuário de um
sistema pode ser considerada um desses requisitos no caso de um sistema de cadastramento de
clientes de uma loja, devendo ser limitada a poucos segundos nesse caso, uma vez que o
cliente da loja, objeto do cadastramento, não deve ser submetido ao transtorno de esperar o
funcionamento de um software para tal atividade (PAULA FILHO, 2003).
A importância do detalhamento dos requisitos funcionais e não-funcionais consiste no
fato de que a simples adoção do caso de uso como parâmetro para o desenvolvimento de
software é uma abordagem muito simplificada, na medida em que o caso de uso possui um
enfoque bastante voltado à visão do cliente. Assim, ao detalhá-los, a equipe de projeto
consegue ter uma visão maior das necessidades do sistema como um todo, não somente do
ponto de vista do usuário (WIEGERS, 2003).
44
2.6.7. Classificação dos requisitos
A última atividade da análise de requisitos é a classificação dos mesmos, que nada
mais é do que um cadastramento de todos os casos de uso segundo seu tipo (se é um fluxo
principal ou subfluxo), sua prioridade, que é a necessidade ou não da existência do caso de
uso para os propósitos do sistema e estabilidade que determina a probabilidade de o caso de
uso ser alterado ao longo do projeto (PAULA FILHO, 2003).
A priorização tem papel fundamental na gestão do projeto, uma vez que é muito
complicado gerenciar diversos parâmetros que possuam o mesmo peso. Por exemplo, um
gestor teria grande dificuldade em definir cortes no orçamento de um projeto em que todos os
requisitos possuam a mesma importância. (WIEGERS, 2003).
2.6.8. Revisão dos Requisitos
O propósito dessa atividade é que se assegure que os requisitos construídos estejam de
acordo com os critérios de qualidade estabelecidos inicialmente e que as informações contidas
nesse documento sejam suficientes para que o projeto continue, sem interrupções por falta de
informação a respeito do sistema a ser desenvolvido (PAULA FILHO, 2003).
É intuitivo perceber que nessa etapa o cliente deve ter presença, como forma de
validação de todos os requisitos que foram determinados para o sistema que ele futuramente
utilizará.
2.7. Requisitos de interfaces de usuário de software
Durante a realização de um projeto de desenvolvimento de um software, uma questão
de grande relevância é o foco nas necessidades do cliente e do usuário. Capturar o que eles
realmente buscam é uma tarefa fundamental para o bom andamento do projeto. Para se
capturar essas necessidades é realizada a análise de requisitos do sistema. Entretanto, não
basta apenas um sistema que contenha todas as funções buscadas pelos clientes, caso a forma
de obtenção dessas funções seja confusa e pouco intuitiva.
Assim, é muito importante que as interfaces do sistema tenham características que
facilitem seu uso, intensificando o desenvolvimento do projeto com foco no cliente e no
45
usuário. Nessa perspectiva, existem diretrizes que podem ser seguidas para orientar o rumo do
projeto (PAULA FILHO, 2003).
2.7.1. Modelo mental
A ideia básica do desenho de interfaces é que os usuários consigam formular um
modelo mental do funcionamento do sistema como um todo, ou seja, que consigam ter em
suas mentes uma forma de funcionamento que seja aplicável em todas as interfaces. O
objetivo seria encontrar uma forma de funcionamento que fosse aplicável a qualquer interação
do usuário com o sistema, reduzindo ao máximo a necessidade de memorização de comandos
e consequentemente reduzindo o risco de erros operacionais por parte do usuário (PAULA
FILHO, 2003).
Evidentemente, é muito complicado, para não dizer impossível, de se atingir um
modelo no qual todas as interações respeitem a mesma forma de funcionamento. Sendo assim,
a busca é por um sistema que tenha a maior aderência possível de suas aplicações ao modelo
mental, reduzindo ao máximo suas inconsistências.
2.7.2. Consistência e simplicidade
Duas características essenciais das interfaces de um software são sua simplicidade e
consistência.
A simplicidade não necessita de grandes explicações, basta dizer que quanto mais fácil
para o usuário operar o sistema, melhor será sua interação e consequentemente sua satisfação
ao usá-lo. Dessa forma, funções que contenham algum grau de complexidade devem ser
subdivididas até o ponto em que o usuário entenda o que está sendo realizado. Assim, as
interfaces principais devem conter apenas os itens mais usados, deixando para interfaces
secundárias as funções menos frequentes (PAULA FILHO, 2003).
A consistência está ligada diretamente à busca por um modelo mental intuitivo, ou
seja, um conjunto de interfaces consistentes são aquelas cujo modo de interação com o
usuário é muito similar, facilitando e agilizando o aprendizado de novas funções do sistema.
46
Diversos fatores influenciam a consistência e a simplicidade se um conjunto de interfaces,
dentre eles, de acordo com Roger S. Pressman (1992), destacam-se:
Uso da terminologia condizente com o ambiente no qual o sistema será utilizado.
Padronização dos aspectos visuais dos elementos do sistema. Por exemplo,
características semelhantes devem apresentar leiaute semelhante.
Consistência no comportamento das funções. Qualquer tipo de função genérica do
sistema deve apresentar o mesmo funcionamento em todas as interfaces em que
está disponível.
A consistência também tem como beneficio o aumento da produtividade dos usuários,
na medida em que, como o sistema apresenta uma maneira bem estruturada de interação com
o usuário, o número de erros cometidos pelo operador é muito menor (NIELSEN, 1993).
A simplicidade também está ligada ao tipo de informação fornecida ao usuário durante
sua interação com o sistema. De maneira geral, fornecer ao cliente dados já trabalhados ao
invés de um grande número de informações sem análise torna o uso do software menos
estafante e mais produtivo (STAIR, 1998).
2.7.3. Questões de memorização
A capacidade humana de memorização deve ser levada em conta no projeto de
interfaces. É conhecido que a memória de curto prazo dos seres humanos tem a capacidade de
armazenar de cinco a nove elementos de cada vez, ou seja, é importante que as interfaces
contemplem essa questão de modo que não sejam muito longas e assim ultrapassem esse
limite (PAULA FILHO, 2003).
Outra questão é utilizar uma linguagem que seja a mais direta possível, reduzindo
assim a necessidade de memorização. Bons exemplos de linguagens pouco diretas são as de
programação, uma vez que para a execução de qualquer comando é necessário lembrar séries
de comandos específicos (PAULA FILHO, 2003).
Linguagens baseadas em símbolos facilmente reconhecíveis são altamente
recomendáveis na medida em que não só facilitam o aprendizado para os novos usuários
como também simplificam o armazenamento de informações por parte dos operadores menos
frequentes.
47
Não somente na linguagem está o problema da memorização. A quantidade de
informação a ser recordada entre etapas do processo do software levada ao mínimo possível.
Não se espera que o usuário deva memorizar uma sequencia de números para usa-los em uma
função seguinte (PRESSMAN, 1992).
2.7.4. Questões cognitivas
Outro aspecto que pode ser explorado no desenvolvimento de interfaces para um
software são os mecanismos de associação mental. Dessa forma, analogias com objetos e
formas presentes no dia-a-dia podem ser muito úteis. Um exemplo bom é a utilização de
figuras de disquetes como metáfora para um botão de salvamento (PAULA FILHO, 2003).
Ao utilizar esse tipo de analogia, entretanto, é necessário que haja cuidado em relação
à escolha do ícone colocado. Culturas diferentes podem dar significados distintos aos mesmos
símbolos, o que pode causar uso errado do sistema (NIELSEN, 1993).
2.7.5. Realimentação
No contexto de desenvolvimento de interfaces de softwares a realimentação diz
respeito ao sistema sempre dar uma resposta a seu usuário após o último executar alguma
ação nele.
Esse tipo de feedback é essencial durante a interação de usuário com o sistema na
medida em que possibilita a quem usa saber que o software está funcionando corretamente,
principalmente para aquelas funções que demandam tempo para serem realizadas. É ainda
melhor para o usuário que o sistema apresente algum tipo de estimativa de tempo para o final
da execução do comando feito por ele (PAULA FILHO, 2003). O tipo de realimentação dado
não necessariamente precisa ser visual, como uma mensagem de texto, podendo ser, por
exemplo, auditiva (PRESSMAN, 1992).
De acordo com Paula Filho (2003), outra questão que dá importância à realimentação
é que ela também indica ao usuário se ele está percorrendo corretamente o caminho que
deseja trilhar ao longo do uso do sistema. Quando um ele faz uso de um botão sem ter certeza
de que é aquilo que procura, uma mensagem de realimentação pode tanto indicar que seu
48
caminho está certo como também mostrar que não, poupando o tempo do usuário, que
demoraria mais para perceber seu erro caso não fosse avisado pelo sistema que a ação que
acabara de executar não é a desejada.
2.7.6. Mensagens do sistema
O tipo de linguagem usada nas mensagens do sistema também é um ponto que deve
ser estudado. As mensagens devem apresentar linguagem que seja própria do meio do usuário,
ou seja, com a qual ele esteja acostumado (PAULA FILHO, 2003).
Mensagens de erro não devem apresentar detalhes muito complexos sobre o tipo de
erro ou outras características irrelevantes para o operador. Outra questão é que esse tipo de
mensagem deve ser escrita da maneira mais direta em impessoal possível, sem que se use
mensagens alarmistas ou antropomorfizar o computador (PRESSMAN, 1992).
2.7.7. Modalidade
O termo modalidade diz respeito a uma interface possuir modos diferentes, ou seja,
possuir dois ou mais estados diferentes que, dependendo do que está ativo, pode gerar
resultados diferentes para o mesmo tipo de ação do usuário. Esse tipo de estrutura é confusa e
pouco intuitiva, dessa forma, preferencialmente interfaces com diferentes modos devem ser
evitadas. Para os casos em que não é possível evitar a utilização dessas estruturas, uma forma
de diminuir a ocorrência de erros operacionais é fornecer realimentação aos usuários, de
modo a orientá-los sobre o modo em que estão operando (PAULA FILHO, 2003).
2.7.8. Reversibilidade
A reversibilidade é a possibilidade por parte do usuário de desfazer alguma ação feita
anteriormente, voltando para o estado anterior do sistema. Essa característica é muito
importante, pois previne que erros simples causem a necessidade de que todo o processo de
interação para a realização de uma determinada ação tenha que ser reiniciado (PRESSMAN,
1992).
49
A reversibilidade também ajuda o usuário a aprender mais rápido a respeito do
software que está utilizando, na medida em que explora o produto com menor receio de
cometer erros e não poder desfazê-los, e assim se acostuma mais rapidamente com as
características do produto (PAULA FILHO, 2003).
2.7.9. Atração da atenção
Uma interface bem feita deve apresentar destaque para as características mais
relevantes contidas nela (PRESSMAN, 1992). Entretanto, um erro comum é o exagero no
destaque de características da interface, tornando-a confusa ao invés de encaminhar o usuário
para as escolhas corretas. Assim, segundo Paula Filho (2003), diversos pontos devem ser
respeitados:
Dois níveis de intensidade são o ideal para dar destaque às partes importantes
sem confundir o usuário.
Textos sublinhados e em negrito nem sempre são uma boa solução.
As regras da língua devem ser respeitadas, sem a utilização de todas as letras
maiúsculas para dar destaque.
Os tamanhos de fonte podem variar para dar destaque a títulos, por exemplo,
mas não utilizar mais do que três ou quatro tamanhos.
Dessa forma, é possível de se respeitar algum tipo de padronização do leiaute das
interfaces do sistema, tornando-o menos confuso e mais intuitivo para a utilização do usuário.
2.7.10. Exibição
A forma como os pontos de interação do usuário com o sistema são dispostos deve ser
bem localizado e respeitar algum tipo de padrão ao longo de todo o sistema. Um exemplo
disso são os botões de reversibilidade que devem sempre estar localizados na mesma posição
em todas as interfaces. A questão importante nessa diretriz é a manutenção de um padrão que
por todo o sistema de modo que ele seja o mais intuitivo possível, facilitando a interação com
o usuário (PAULA FILHO, 2003).
50
Pode-se acrescentar também a importância de se pensar o leiaute de uma interface
também priorizando a minimização da distância entre funções sequenciais, diminuindo o total
percorrido pelo mouse durante a interação (PRESSMAN, 1992).
2.7.11. Diferenças individuais
Uma importante característica dos usuários é que eles possuem diferentes níveis de
experiência e preferências individuais. Um erro muito comum da equipe de projeto de um
software é adotar que suas experiências e preferências podem representar as dos usuários.
Esse tipo de erro pode acarretar em dois tipos diferentes de problemas. O primeiro é tornar a
interface pouco intuitiva, na medida em que quem desenvolve o projeto tem muito mais
experiência em lidar com o sistema do que os novos usuários. O outro problema é adotar
características que agradem à equipe, mas não aos seus usuários, por diversas questões de
contexto. Para evitar isso o sistema deve apresentar características mais imparciais possíveis
(PAULA FILHO, 2003).
Nesse ponto devem ser levadas em consideração as diferenças existentes entre o
contexto no qual a equipe de projeto está inserida e o dos usuários, que podem, por exemplo,
ser de diferentes nacionalidades, interpretando as mesmas informações de maneiras distintas
(NIELSEN, 1993).
51
3. Metodologia
A atividade bancária, que consiste basicamente em tomar recursos de agentes
superavitários e emprestá-los aos agentes deficitários, buscando obter lucro nessa
intermediação, possui semelhanças em muitos aspectos com a atividade dos mais diversos
setores industriais. Embora não haja num banco materiais circulando fisicamente por diversos
setores como em uma fábrica, existem muitas semelhanças na forma como todo o processo,
tanto no setor industrial quanto em um banco, deve ser desenhado.
De maneira simplificada, pode-se entender uma fábrica como um conjunto de
processos cujas atividades são previamente planejadas e definidas, em seguida executadas,
depois controladas e aperfeiçoadas para se garantir um produto final de acordo com o
planejado inicialmente. Conforme estudado na fundamentação teórica, a esse ciclo pode-se
dar o nome de PDCA (Plan / Do / Control / Act).
Quando se observa a maneira como o banco objeto de estudo do trabalho realiza sua
atividade de centralização dos riscos de mercado para uma área única, percebe-se que ele é
um processo que pode ser comparado com os que ocorrem nas mais tradicionais indústrias.
Inicialmente, por trás de todo o processo existe uma metodologia que o embasa. Nesse
caso específico, a metodologia é o Matched-maturity marginal cost of funds conforme
explicitado na fundamentação teórica. Com base nesse modelo, a área de Gestão
Financeira/ALM é capaz de efetivamente realizar os cálculos da Taxa de Transferência
Interna e passá-la às áreas comerciais. A partir daí encontra-se o problema no desenho do
processo do banco, ou seja, ele não possui controle nem mecanismo de atuação frente a
eventuais erros encontrados, conforme ilustrado na Figura 5:
52
De maneira ainda bem superficial, é possível perceber pela figura anterior que tanto a
atividade de controle quanto a de atuação não existem no fluxo atual no processo analisado.
Entretanto, nota-se que é o sistema entraria nesse fluxo como a função de controle do
processo, enquanto o contato com as áreas comerciais para o ajuste das Taxas de
Transferência Interna equivocadas entraria no ciclo como a atividade de atuação.
A partir desse momento está definida a fonte mais básica do problema, o que
possibilita que se dê início ao processo de análise mais aprofundada de cada característica do
contexto com o intuito de obter uma descrição completa do cenário em que se está
trabalhando para posteriormente desenvolver o sistema que resolva o problema proposto.
Então, para o desenvolvimento desse sistema, foi utilizada a seguinte metodologia básica para
se alcançar os resultados, na seguinte ordem:
Triagem inicial
Análise de requisitos
Desenvolvimento do sistema de cálculo mensal
Talvez se possa pensar que a ordem mais intuitiva para a realização do
desenvolvimento do sistema fosse começar pela análise de requisitos dele. Como já descrito
na fundamentação teórica, essa etapa tem como objetivo criar um enunciado completo do
sistema que se deseja construir. Assim, para que se pudesse ter certeza do tipo de problema
Figura 5 - Ciclo PDCA para o atual modelo de funds transfer pricing
(Adaptado de CAMPOS, 1998)
53
que se estava enfrentando e qual a ideia inicial do sistema feito posteriormente, realizou-se
uma triagem inicial ao longo das bases de dados, para um primeiro contato. Em seguida foi
feita a análise de requisitos do sistema proposto e finalmente o desenvolvimento propriamente
dito.
Triagem inicial
A primeira etapa para o desenvolvimento de um sistema que calcule as Taxas de
Transferência Interna de diversos tipos de bases de dados foi a realização de uma triagem
inicial por todas elas. A importância dessa etapa é que a partir desse ponto que se tomou
conhecimento de cada um dos detalhes existentes nelas, como por exemplo, que tipos de
campos cada uma possuía, que erro era mais comum, que tipo de aproximação deveria ser
feita por falta de dados precisos e quais eram os padrões existentes entre as bases, que
facilitariam o desenvolvimento do sistema.
A partir dessa triagem foi possível analisar de forma superficial cada uma das bases, e
assim facilitar a análise de requisitos, visto que ela permitiu a definição inicial de algumas
características do escopo do projeto, escopo esse efetivamente definido na próxima etapa do
trabalho.
Análise de requisitos
O passo seguinte para o desenvolvimento de um sistema de informação foi a
realização de uma análise de requisitos para o problema que se deseja resolver. Nessa etapa
do desenvolvimento do projeto, busca-se desenhar um plano completo que mostre a quem está
trabalhando nele todas as necessidades que o software necessita atender e todas que não deve
atender, delimitando um escopo para o projeto.
A definição do escopo é importante na medida em que a partir dele é possível haver
planejamento a respeito do projeto, no que tange não somente datas, mas também
características de qualidade de cada parte do projeto.
54
Desenvolvimento do sistema de cálculo mensal
A etapa seguinte à análise de requisitos foi o efetivo desenvolvimento do sistema de
cálculo mensal das novas operações das bases de dados. Essa etapa pode ser subdividida
simplificadamente em três outras fases: busca das operações nas bases de dados, cálculo e
comparação da taxa efetiva justa para o período da operação com a que efetivamente está
registrada no sistema e apresentação das operações com erro e análise dos erros por meio de
interfaces e relatórios.
55
4. Solução Técnica
A partir da metodologia para a resolução do problema definida no capítulo anterior,
partiu-se para o efetivo desenvolvimento do sistema, baseado nas três etapas nele
apresentadas.
4.1. Triagem Inicial
O trabalho se iniciou com a primeira intenção de verificar a existência de operações de
grande volume que possuíssem Taxas de Transferência Interna diferente da que seria
considerada justa para o mercado no dia em que a operação foi realizada. Para essas
operações a intenção é que a taxa fosse corrigida, pois taxas erradas causariam impacto no
resultado da área de Gestão Financeira/ALM e estariam desrespeitando a metodologia
utilizada pelo banco para centralizar os riscos de mercado.
Então, inicialmente foi feita uma triagem por todo estoque de operações do banco,
analisando cada uma das bases de dados que estavam presentes no escopo inicial, ou seja, as
bases de ativos do banco, que estivessem indexadas à taxa DI ou que fossem prefixadas. Essa
primeira etapa foi importante para a obtenção do primeiro contato com as diferentes bases,
percebendo suas particularidades, o que facilitou a modelagem do processo posteriormente
realizado de cálculo da Taxa de Transferência Interna justa para as operações e comparação
com a efetivamente registrada nas bases de dados para um determinado mês, que era o intuito
do projeto.
O sistema que a instituição financeira utiliza para armazenar as informações a respeito
dos contratos que possui, tanto de ativos quanto de passivos, é constituída por vários bancos
de dados separados. Essa separação foi motivada por duas razões:
A empresa cresceu seu volume de negócios no Brasil baseada em um modelo de
aquisição de outras instituições financeiras, que por sua vez, possuíam bancos de
dados próprios. Assim, para integrá-los, acabou-se optando por bases de dados
separadas.
Embora alguns desses bancos de dados possuam informações parecidas, outros tratam
os dados de maneira única, principalmente para o caso de operações de grande porte,
56
que em geral são muito particulares quanto à data e o volume de cada pagamento de
suas parcelas, diferentemente dos sistemas que tratam de operações mais simples,
como o que armazena o crédito pessoal, no qual em quase todos os casos existe
pagamento mensal de parcelas com o mesmo valor, conhecida como tabela price.
4.1.1. Escopo inicial do projeto
Para delimitar a triagem dos bancos de dados, definiu-se um escopo preliminar para o
projeto. Os clientes avaliaram que o software deveria cobrir todas as operações de geração de
ativos denominadas em reais que apresentassem funding livre, ou seja, que a Taxa de
Transferência Interna não seja atrelada a algum mecanismo de captação que tenha taxa fixa. O
caso mais claro de operações sem funding livre é o crédito imobiliário. A captação para esse
tipo de crédito é em sua maioria proveniente da poupança, cuja taxa de captação é fixa em
0,5% ao mês mais a Taxa de Referência (TR), para o caso da taxa Selic Meta estar acima de
8,5% ao ano, ou 70% da Selic diária somada à TR, para o caso da taxa Selic Meta estar abaixo
ou igual a 8,5% ao ano (BRASIL, 2012).
Dessa forma, de modo geral, as operações que ficaram no escopo do projeto são as de
empréstimos para empresas (que podem ser de vários tipos, como financiamento de capital de
giro ou financiamento para exportação), empréstimos pessoais (como os fornecidos pelas
financeiras, de modo geral), empréstimo consignado (ou seja, com desconto direto na folha de
pagamento), descontos de duplicatas e operações de leasing.
Evidentemente, esse escopo preliminar deve ser mais bem definido, para se obter um
panorama completo do sistema a ser desenvolvido. Esse detalhamento ocorreu, todavia,
durante a segunda etapa do projeto, na análise de requisitos. Essa definição preliminar
objetivava retirar da triagem inicial alguns contratos menos relevantes para um primeiro
projeto de análise. Isso não significa que os contratos retirados logo de início não tem
importância e não serão objetos de análise em nenhum momento. Na realidade, a ideia da área
é criar diversos sistemas que cuidem de todos esses tipos de contrato, tanto ativos como
passivos, em qualquer moeda, e indexados aos mais diversos índices. Então, o presente
trabalho pode ser entendido como uma primeira parte de um projeto maior.
57
4.1.2. Tipos de contrato
A partir dessa análise preliminar, percebeu-se a existência de dois tipos distintos de
contratos armazenados nos bancos de dados, os que possuem fluxos regulares e os de fluxos
irregulares.
1. Contratos com Fluxos regulares
Os contratos com fluxos regulares são aqueles que possuem fluxos de pagamentos da
dívida que respeitem algum tipo de regra. Essas regras podem ser de três tipos: sistema price,
sistema SAC ou bullet.
O sistema price, que já foi discutido anteriormente, é aquele no qual as parcelas pagas
para o credor ao longo do contrato são constantes. Nesse caso, no início do contrato, as
amortizações são menores e os juros pagos maiores, pois o saldo devedor ainda é alto.
Conforme as amortizações são realizadas, os juros pagos vão diminuindo e as amortizações
ficam maiores, uma vez que o valor da parcela (juros mais amortização) é constante. Esse é o
tipo de contrato de empréstimo mais comum realizado pelos bancos, uma vez que o devedor
paga sempre o mesmo montante todos os períodos, o que facilita seu encaixe no orçamento do
cliente (SECURATO, 1999).
O Sistema de Amortização Constante (SAC) é aquele, como o próprio nome já
descreve, em que as amortizações da dívida são constantes, e os juros pagos ao longo do
contrato vão caindo, pois o saldo devedor vai diminuindo conforme as amortizações são
feitas.
Um contrato bullet é aquele no qual todo o pagamento da dívida (juros e amortização)
é realizado na data final de vencimento. Na prática ele pode ser encaixado como um sistema
price ou sistema SAC com apenas um fluxo de pagamento, mas sua identificação facilita os
cálculos (SECURATO, 1999).
Caso seja possível identificar contratos que pertençam a uma dessas categorias eles
podem ser calculados mais facilmente. É possível de se definir completamente as
características de um contrato que se encaixe em um dos três perfis acima, apenas fixando a
taxa de juros dos períodos, o valor original do contrato (volume inicialmente emprestado no
contrato) e as datas de amortização, que para esses casos são períodos de tamanho igual (por
exemplo, pagamento mensal).
58
2. Contratos com fluxos irregulares
Esse tipo de contrato não pode ser definido apenas pelas três características acima,
pelo fato de não possuírem periodicidade constante ou volumes dos pagamentos em cada uma
das datas de pagamento.
Assim, para defini-lo, é preciso do fluxo completo com cada uma das datas de
pagamento, os volumes de pagamento para as respectivas datas e as taxas de juros cobradas
até cada uma das datas.
4.1.3. Tipos de Base de Dados
Depois de conseguir separar os contratos em duas categorias (fluxos regulares e fluxos
irregulares), foi necessário avaliar como os mesmos estavam dispostos nas diversas bases.
Nesse momento foi formalizado que tipos de contratos seriam estudados no processo do
software.
O que pode ser percebido é que existem dois bancos de dados (cujos nomes são VS e
V2) dedicados às operações com empresas de grande porte, em geral empresas com atuação
em diversos mercados ao redor do planeta. Um desses bancos de dados (VS) possui uma
descrição do contrato, com suas informações mais abrangentes, como a data de início, a data
de vencimento, a Taxa de Transferência Interna, a taxa efetivamente passada ao cliente, o
volume do contrato, o saldo devedor entre outras. O outro banco de dados (V2) contém
informações detalhadas dos contratos, como a data de vencimento de cada uma das parcelas e
seus respectivos volumes. Isso acontece porque esse tipo de operação costumeiramente
apresenta fluxos irregulares, uma vez que o fluxo de caixa de empresas de grande porte não é
muito constante e, por se tratarem de operações de volumes expressivos, o banco dedica essas
duas bases de dados para armazenar essas informações.
Outros dois bancos de dados que chamam a atenção são as bases mais antigas do
banco. Esses dois (cujos nomes são UG e U2) possuem diversos tipos de operações, e neles
estão presentes contratos com fluxos regulares e irregulares. Todos eles estão armazenados no
sistema UG, entretanto, apenas os contratos com fluxos irregulares têm suas parcelas
registradas no banco de dados U2, que contém somente parcelas, assim como o V2.
59
Além desses quatro bancos de dados, existem ainda mais cinco (YD, GC, S8, HE e
OZ), que contém apenas operações de fluxos regulares e, portanto, nenhum deles apresenta
descrição de parcelas.
4.1.4. Informações armazenadas nos bancos de dados
Para dar prosseguimento ao desenvolvimento do sistema, foi essencial que se
conhecesse detalhadamente os bancos de dados com os quais se estava trabalhando, para
poder saber que tipo de informações estavam disponíveis para a realização do cálculo de
conferência das Taxas de Transferência Interna.
Outra questão importante nessa análise diz respeito à confiabilidade das informações
disponíveis, ou seja, a garantia de que estejam corretas. Isso é relevante uma vez que, por se
tratarem de bancos de dados gerenciais cujas informações são utilizadas para análises internas
e não possuindo fins contábeis, as informações contidas não necessariamente apresentarão
total coerência.
Evidentemente, os erros existentes não se tratam de informações essenciais dos
contratos, como sua data de início, data de vencimento ou valor emprestado, mas informações
menos importantes, mas que podem ter certa relevância nessa análise. Vale ressaltar que a
descrição a respeito de cada operação está armazenada em cada um dos contratos
isoladamente, ou seja, qualquer informação necessária para definir as características dos
contratos é arquivada pelo banco, mas nem todas elas estão compiladas nas bases de dados.
Então, listou-se abaixo os campos mais relevantes armazenados pelas bases de dados,
juntamente com uma descrição do que se trata cada num deles. É intuitivo perceber que as
bases de dados que contém contratos possuem informações diferentes das que têm as
descrições dos contratos com fluxos irregulares, logo são necessários dois quadros para
descrever as informações mais relevantes.
Descrição das informações mais importantes das bases de dados que armazenam
informações dos contratos, apresentada no Quadro 1:
60
Campos bases de dados Descrição
Centro Código referente à área onde foi originada a operação.
Contrato Número de contrato. Funciona como chave para identificação
de contratos que possuem o mesmo código e subproduto.
Subproduto É um código referente ao tipo de produto que foi oferecido ao
cliente, como capital de giro ou crédito pessoal.
Data de Início Data de início do contrato, ou seja, data em que o banco
desembolsou os recursos para o cliente.
Data de Fim Data final do contrato, ou seja, data em que o cliente efetuará o
último pagamento ao banco, finalizando-se o contrato.
TTI Taxa de Transferência Interna válida para o contrato.
Taxa Cliente Taxa de juros que o cliente deve pagar ao banco durante o
contrato.
Saldo Devedor É o saldo devedor da operação na data da análise dos dados.
Valor Original Valor inicial desembolsado pelo banco para o cliente.
Tipo de Operação
Código que define o fluxo de pagamentos do contrato. Pode
definir pagamentos do tipo bullet, price, SAC, ou fluxo
irregular.
Base Código que define se a contabilização dos juros será feita em
dias úteis (base 252) ou em dias corridos (base 360).
Descrição do produto Descrição detalhada do tipo de produto que corresponde ao
contrato.
Segmento Define o segmento comercial do banco responsável pela
operação, por exemplo, varejo ou grandes empresas.
Quadro 1 - Informações mais relevantes das bases de dados de contratos
(Elaborado pelo autor)
O modo de definir completamente um contrato nas bases de dados é pela combinação
de centro, contrato e subproduto. Assim, as colunas centro, contrato e subproduto podem ser
concatenadas e formar uma chave que distingue completamente um contrato do outro dentro
de uma mesma base de dados.
Outro detalhe importante de se explicar é a diferença entre o número armazenado na
coluna subproduto e a descrição do produto. Embora o primeiro seja um dado numérico e o
outro seja uma palavra, suas funções seriam aparentemente as mesmas, ou seja, armazenar o
produto bancário correspondente ao contrato. Porém, há uma leve distinção entre as duas
colunas, que é o fato de o subproduto ser mais genérico que a descrição do produto em termos
61
de detalhes a respeito do produto. Além disso, o número subproduto, como explicitado
anteriormente, também tem a função de servir como parte da chave que define os contratos.
Descrição das informações mais importantes das bases de dados que armazenam
informações das parcelas dos contratos
Para que seja possível relacionar as bases de dados que contém a descrição dos contratos
com as que contêm a descrição das respectivas parcelas é necessário que em ambas haja
uma chave que as ligue. Como exposto anteriormente, a chave corresponde ao conjunto de
centro, contrato e subproduto. Então, evidentemente esses campos também aparecem nas
bases de dados das parcelas e não serão descritos novamente no Quadro 2:
Campos bases de dados Descrição
Data do fluxo Corresponde à data de pagamento de uma determinada parcela
do contrato.
Valor do fluxo Corresponde ao valor de pagamento de uma determinada
parcela do contrato.
Quadro 2 - Informações mais relevantes das bases de dados de parcelas
(Elaborado pelo autor)
4.1.5. Limitações das bases de dados
As bases de dados analisadas possuem campos que caracterizam a maioria dos
contratos de empréstimo do banco, entretanto existem algumas características de certos
contratos que não são armazenadas nas bases, impossibilitando um cálculo preciso da Taxa de
Transferência Interna nesses casos.
As condições especiais mais relevantes são as de operações com desembolso a termo
por parte do banco, operações cuja recompra possa ser feita sem marcação a mercado e
renegociação de contratos, que são operações que foram recompradas pelo banco e lançadas
novamente com outro fluxo.
3. Desembolso a termo
Operações com desembolso a termo por parte do banco são aquelas que a data de
início não é igual à data em que o contrato foi fechado. Assim, no momento da precificação
62
da operação, as condições do mercado não são as mesmas das da data de início do contrato.
Como as bases de dados não contém a data de precificação da operação, não é possível
realizar esse cálculo com muita precisão, pois se deve adotar a condição de que não existem
operações a termo.
Os outros dois casos dizem respeito ao conceito de marcação a mercado, que nada
mais é do que definir o valor de um contrato pelo seu preço de mercado. Como as condições
do mercado mudam ao longo do período do contrato, o valor do contrato no mercado muda,
ou seja, caso ele seja vendido a um terceiro ele seria comprado pelo preço de mercado. Esse
valor em uma determinada data é calculado trazendo o valor das parcelas de pagamento
restantes a valor presente pela taxa de juros do mercado na data determinada. Assim, caso um
cliente queira quitar um contrato com o banco, esse contrato será recomprado pelo banco à
taxa de mercado (SECURATO et al., 1999).
4. Recompra sem marcação a mercado
Alguns clientes do banco, entretanto, não querem estar suscetíveis às oscilações do
mercado, então o banco oferece uma opção ao cliente de pagar uma taxa de juros um pouco
mais elevada, mas caso queira quitar antecipadamente sua dívida ele o fará sem ajuste às
condições do mercado, portanto nesse caso o banco assume esse risco do cliente. Como as
bases de dados não possuem essa informação, não se pode saber quais contratos possuem essa
condição.
5. Renegociação de contratos
A terceira dificuldade surge quando o cliente quer renegociar suas dívidas, mudando
seus fluxos de pagamento. Nesse caso, o banco recompraria a operação antiga pelo valor de
mercado, e lançaria a nova operação com os custos de mercado de hoje e embutindo nesses
custos a diferença proveniente da recompra da operação antiga. Essa é outra informação
inexistente nas bases de dados e, portanto, contratos que possuem essa característica não
podem ser identificados para terem seu cálculo feito corretamente.
Um quarto limite não trata exatamente de falta de informação nas bases de dados, mais
sim de falta de confiabilidade da informação presente no campo, que é a questão da
contabilização de dias de contrato, melhor explicada a seguir.
63
4.1.6. Tipos de convenção de contabilização de dias de contrato
Um detalhe importante a respeito de como os cálculos de taxas de juros são realizados
no mercado brasileiro é a convenção do número de dias do contrato que serão considerados
para a realização dos cálculos de juros.
No mercado brasileiro, existem duas convenções mais utilizadas, a base 252, com
contabilização apenas de dias úteis, e a base 360, com contabilização de dias corridos. Em
nosso mercado, é importante também ressaltar, as taxas de juros são contabilizadas de
maneira exponencial, ou seja, havendo incidência de juros sobre os juros do período anterior.
Na base 252, o cálculo do valor futuro de um empréstimo feito hoje é feito da seguinte
maneira:
Onde,
é o valor futuro do empréstimo..
é o valor inicial do empréstimo.
é a taxa de juros considerada no período, expresso em taxas anuais.
é o número de dias úteis entre o início e o fim do contrato.
Observe que nesse caso supõe-se, a termo de simplificação, que cada mês tem 21 dias
úteis, somando-se 252 em um ano. Já a base 360, o cálculo do valor futuro de um empréstimo
feito hoje é realizado da seguinte maneira:
Onde,
é o valor futuro do empréstimo.
é o valor inicial do empréstimo.
64
é a taxa de juros considerada no período, expresso em taxas anuais.
é o número de dias corridos entre o início e o fim do contrato.
Observe que nesse caso supõe-se, a termo de simplificação, que cada mês tem 30 dias
corridos, somando-se 360 em um ano.
Para um determinado contrato, o valor futuro pago ao se contabilizar os juros em uma
base 252 ou 360 deve ser o mesmo então os valores de e devem ser diferentes. A
diferença entre os dois valores pode ser calculada admitindo-se que o valor inicial, valor final,
data de início e data de fim nos dois casos é o mesmo. Assim, vale-se da seguinte igualdade:
O desafio é definir quais contratos dentro dos bancos de dados são calculados com
base 252 e quais utilizam base 360. Em tese, esta informação está contida nos bancos de
dados, entretanto, ela não é confiável. Foi possível constatar isso ao se analisar a base VS, que
contém as operações de grandes empresas, na qual esse campo estava preenchido como base
de cálculo em dias corridos para todas as operações. Porém, esse fato certamente não é o que
realmente ocorre no contrato, visto que muitas das operações ali contidas tiveram suas Taxas
de Transferência Interna calculadas individualmente pela área de Gestão Financeira/ALM, e
nem sempre a base de cálculo usada era a de dias corridos.
4.1.7. Resultados da triagem inicial
O maior resultado obtido com a triagem inicial foi a aproximação com o contexto do
qual faz parte o sistema. Com ela, pode-se saber que tipo de informação estava disponível
para a realização dos cálculos, quais informações faltavam, e quais eram as informações
confiáveis das bases de dados.
Essa primeira etapa tem um caráter facilitador para a etapa seguinte, de análise de
requisitos, na medida em que ela começou o processo de definição de escopo do projeto, que
é um dos objetivos presentes na análise de requisitos.
65
4.2. Análise de requisitos
Como exposto no capítulo de Fundamentação Teórica, a Análise de Requisitos é uma
maneira de se formalizar um enunciado completo do sistema que será desenvolvido, a fim de
conseguir enxergar claramente suas características e seus limites, além de poder compartilhar
a proposta do sistema com os clientes, alinhando as expectativas deles com o projeto que está
sendo desenvolvido.
Antes de partir para a metodologia proposta em Engenharia de Software (PAULA
FILHO, 2003), livro no qual o autor afirma que uma boa análise de requisitos deve
comtemplar os itens, funcionalidade, interfaces externas, desempenho esperado, outros
atributos relevantes e restrições. Assim, essas questões foram brevemente respondidas para
um contato inicial com o problema, e depois a Análise de Requisitos foi desenvolvida.
Funcionalidade
O software desenvolvido tem como objetivo calcular a Taxa de Transferência Interna
das operações financeiras realizadas pelo banco em cada mês. Dessa forma, o software seria
utilizado periodicamente, ao final de cada mês, para verificar se a Taxa de Transferência
Interna que está registrada no banco de dados da instituição financeira é realmente a taxa justa
para a data na qual foi feita a operação.
A partir desse cálculo, as operações que não apresentem taxa coerente poderão ser
corrigidas, garantindo assim boas práticas de política de Funds Transfer Pricing, cuja
importância já foi descrita na Fundamentação Teórica.
Interfaces externas
O sistema apresenta pouca interação com os usuários, na medida em que tem como
objetivo gerar relatórios gerenciais. A maior interação acontece no momento em que há o
contato do relatório desenvolvido pelo sistema com o usuário que o interpreta.
66
Desempenho esperado
Como o sistema será utilizado periodicamente, a sua velocidade de resposta deve ser
maior do que a frequência que se pretende utilizar o sistema. Como ele será utilizado
mensalmente, deverá ter a capacidade de realizar os cálculos das Taxas de Transferência
Interna de todas as operações do mês anterior, num período menor do que o mês seguinte.
Evidentemente, quanto mais rápido ele for, mais rápido poderão ser feitos os ajustes nas bases
de dados, mas prioritariamente ele deve de ser capaz de obedecer à condição de cálculo
mensal das taxas.
Outros atributos
Uma característica muito importante para esse sistema é que seus cálculos sejam
confiáveis. O programa seria completamente inútil caso não fosse capaz de dar respostas
confiáveis, para que elas sejam confrontadas com as informações que estão presentes nas
bases de dados.
Dessa forma, é melhor ter um programa que demore a fazer seus cálculos (dentro do
limite estabelecido pela sua periodicidade de utilização), mas que apresente alto grau de
confiabilidade dos resultados, do que outro que forneça respostas rápidas, porém que não
transmita segurança em relação às informações produzidas.
Restrições
A maior restrição encontrada nesse sistema diz respeito à linguagem de programação
na qual ele foi desenvolvido. Uma característica importante desse software é que ele possa ser
modificado durante seu uso, para que seja aperfeiçoado, com base nas experiências dos
usuários anteriores.
Assim, a linguagem de programação deve ser conhecida pelos usuários do software.
Ao se realizar uma pesquisa com os usuários do programa, percebeu-se que o Visual Basic for
Applications (VBA) é a linguagem mais conhecida por eles. Então, essa foi a linguagem
escolhida. Quanto ao banco de dados, a empresa já utiliza o SQL da Microsoft para guardar as
67
informações necessárias para o programa. Logo, não faria sentido escolher de outro banco de
dados se não o Microsoft SQL.
Seguindo a metodologia da Fundamentação Teórica, foi realizada a Análise de
Requisitos adotando a ordem estabelecida em Engenharia de Software (PAULA FILHO,
2003) para as atividades presentes nesse fluxo.
4.2.1. Determinação do contexto
O contexto no qual o sistema será inserido é a área de Gestão Financeira/ALM de um
banco de varejo de grande porte no Brasil. A área é responsável pela gestão do balanço
patrimonial do banco, tanto no que diz respeito à rentabilidade e liquidez do caixa, gestão dos
portfolios de ativos e passivos, como com relação ao capital próprio do banco.
O sistema seria responsável pela verificação das Taxas de Transferência Interna do
banco, como já explicitado no capítulo de introdução, e teria papel de ferramenta gerencial de
controle para a área.
4.2.2. Definição do escopo
Uma boa definição de escopo engloba não somente tudo aquilo que um projeto se
propõe a fazer, mas também impõe claramente os limites daquilo que não se tem o objetivo
realizar. Para tanto, uma maneira sistemática de alcançar isso é tentar definir três parâmetros
do seu projeto, ou seja, a missão, que é aquilo que se deseja alcançar, limites, que são todas as
características que delineiam o espaço entre o que é englobado pela missão e o que não é e,
finalmente, os benefícios, caracterizados como os resultados positivos do atingimento da
missão. A seguir, esse escopo é definido para o projeto do sistema desenvolvido, com base
nesses três parâmetros.
Missão
Verificação da Taxa de Transferência Interna de todas as operações de geração de
ativos, prefixados indexados à taxa DI, para a área de Gestão Financeira/ALM de um banco
de varejo de grande porte no Brasil.
68
Limites
O sistema faz análise de operações de ativos do banco, que estejam denominadas em
moeda local (reais), que apresentem funding livre, ou seja, a captação que provém os recursos
dessas operações não exige algum tipo de específico de ativo (por exemplo, crédito
imobiliário cujos recursos vêm da poupança).
As operações que apresentam desembolso a termo por parte do banco, operações que
não sejam marcadas a mercado para a recompra pelo banco e renegociações de contratos com
novos fluxo de pagamento não tem forma de serem diferenciadas das demais operações no
sistema e são tratadas da mesma maneira que as demais.
A base de cálculo de dias da operação é a de dias corridos para todas as operações,
uma vez que, mesmo que as bases de dados possuam a informação a respeito da base
utilizada, essa informação não é confiável. Assim, sendo necessário optar por um tipo de base,
escolhe-se a de dias corridos.
O sistema não corrige automaticamente as Taxas de Transferência Interna, uma vez
que esse processo deve ser feito em conjunto com a participação das áreas comerciais, para
que eles possam avaliar se realmente existe erro no valor da taxa presente no contrato, já que
uma mudança na Taxa de Transferência Interna tem impacto no resultado da operação da área
comercial.
Benefícios
Benefícios da implantação do sistema apresentados no Quadro 3:
Benefício Valor para o Cliente
Possibilidade de correção dos valores das Taxas de
Transferência Interna. Essencial
Rastreabilidade das áreas comerciais que cometem mais erros. Desejável
Diminuição do número de erros. Desejável
Maior confiabilidade do processo de geração de ativos do
banco. Essencial
Quadro 3 - Benefícios do sistema de informação
(Adaptado de PAULA FILHO, 2003)
69
4.2.3. Definição dos requisitos
O sistema desenvolvido possui uma função principal que é a análise mensal de quais
operações não possuem taxa boletada condizente com o cálculo realizado pelo sistema.
Casos de Uso
o Análise mensal das operações: O sistema possui apenas um caso de uso,
que é exatamente o cálculo mensal para verificação das Taxas de
Transferência Interna das novas operações, realizadas no último mês, do
banco.
Atores
o Analista financeiro: Esse ator é responsável por realizar o cálculo das
cotações da Taxa de Transferência Interna das operações de volume
relevante que não possuem fluxo regular, ou seja, aquelas cujas datas e
valores de pagamento das parcelas não respeitam algum tipo de
padronização repetida ao longo do tempo, por exemplo, pagamento
segundo uma tabela price com fluxos mensais.
Essas cotações, caso efetivamente se realizem como operações do banco,
são registradas nas bases de dados e no próximo mês serão verificadas pelo
sistema. Cabe ao analista financeiro fazer a verificação das novas
operações do mês e confeccionar os relatórios sobre as características dos
erros encontrados.
o Superintendente Financeiro: Em posição hierárquica superior aos analistas,
esse ator tem condição para argumentar com as áreas comerciais a respeito
da correção das TTI que devem ser corrigidas. A correção depende de um
acordo entre as áreas, na medida em que envolve redefiniçao de resultados
de cada uma delas.
o Áreas comerciais: Responsáveis pela efetiva assinatura das operações
juntamente aos clientes, o valor da Taxa de Transferência Interna impacta
diretamente o resultado dessas áreas. Como muitas das operações de
volume relevante possuem suas TTI formalizadas por e-mail entre a Gestão
Financeira/ALM e as áreas comerciais, a operação de colocar o valor da
70
TTI nos contratos é feita pelas áreas comerciais e o acordo para mudança
nesse valor deve envolvê-los.
Diagrama de Contexto
Definidos os casos de uso e os atores que participam dele, é possível desenhar
o diagrama de contexto, que contempla a relação entre os casos de uso e os atores em
uma estrutura única, como mostrado na Figura 6:
4.2.4. Detalhamento dos requisitos da interface
A primeira interface do sistema deve ser uma tela para o contato inicial com o usuário,
para que ele defina quais características a análise das bases deve ter. As três que são
relevantes para o sistema são: data de início das operações que serão analisadas, que define o
mês analisado, qual base de dados será analisada, podendo-se escolher uma base em especial
ou uma análise de todas em conjunto, e qual o limite de erro que se deseja considerar, a partir
do qual as operações serão definidas como erradas para o sistema. Um primeiro desenho dessa
interface pode ser visto na Figura 7:
Figura 6 - Diagrama de contexto do sistema de informação
(Adaptado de PAULA FILHO, 2003)
71
A interface principal do sistema deve conter o detalhamento das características das
operações que não possuem Taxa de Transferência Interna condizente com a calculada pelo
sistema. Dessa forma, a ideia inicial para essa interface é que essa se apresente como uma
tabela que tenha nas colunas cada uma das características da operação e nas linhas as
operações.
Para o sistema projetado, as características escolhidas para definir cada uma das
operações estão explicadas no Quadro 4:
Característica Definição
Chave do
Contrato Sequência de números que define um determinado contrato.
Data de
Início Data de início da operação.
Data de Fim Data de fim da operação, definida como a data de vencimento da última
Início da última verificação Fim da última verificação
dd/mm/aaaa hh:mm:ss dd/mm/aaaa hh:mm:ss
Mês das operações
verificadasLimite Erro Qual Base?
dd/mm/aaaa x,xx% VS
Executar Cálculos
Figura 7 - Esboço da interface inicial do sistema
(Elaborado pelo autor)
72
Característica Definição
parcela do contrato.
Taxa TTI Taxa de Transferência Interna registrada na base de dados.
Taxa do
Cliente
Taxa de juros realmente acordada com o cliente, entendida como a soma
da TTI somada ao spread das áreas comerciais.
Saldo
Devedor
Saldo que o cliente ainda necessita quitar com o banco. É o valor que ainda
falta ser amortizado somado aos juros ainda devidos ao banco.
Valor
Original Valor inicialmente emprestado pelo banco ao cliente.
Descrição do
Produto
Definição de que tipo de produto foi oferecido ao cliente, por exemplo,
capital de giro ou empréstimo pessoal.
Taxa
Calculada
pelo Sistema
Valor da Taxa de Transferência Interna calculada pelo sistema.
Diferença
Entre as
Taxas
Diferença entre a coluna Taxa TTI e a coluna Taxa Calculada pelo
Sistema.
Quadro 4 - Definição das características da interface principal do sistema
(Elaborado pelo autor)
Outra função interessante nessa interface seria algum tipo de informação compilada
dos dados mostrados, como, por exemplo, qual o total do valor das operações analisadas e
qual o total não está condizente com o valor calculado. Um esboço para essa interface pode
ser visto na Figura 8:
73
Outra interface importante é a que apresente um tipo de análise de como os erros
encontrados estão distribuídos pelo banco, ou seja, que tipo de produtos possui mais erros.
Isso facilita para a rastreabilidade dos erros, tornando mais simples a detecção de suas
origens. A interface pode ser esboçada como a imagem da Figura 9:
Descrição do ProdutoTotal em Saldo
Devedor
Total com Erro em
Saldo Devedor
Percentual
com Erro
Erros Encontrados Limite de Erro
Saldo Devedor c/ Erro
Saldo Devedor Total
Percentual correto
Chave do
ContratoData de Início Data de Fim Taxa TTI
Taxa do
Cliente
Saldo
Devedor
Valor
Original
Descrição do
Produto
Taxa
Calculada
pelo Sistema
Diferença
Entre as
Taxas
Figura 8 - Esboço da interface principal do sistema
(Elaborado pelo autor)
Figura 9 - Esboço da interface de análise por produto
(Elaborado pelo autor)
74
As características dessa interface estão descritas no Quadro 5:
Característica Definição
Descrição do
Produto
Definição de que tipo de produto foi oferecido ao cliente, por exemplo,
capital de giro ou empréstimo pessoal.
Total em
Saldo Devedor
Soma do saldo devedor de todos os contratos que são do determinado
produto.
Total com
Erro em Saldo
Devedor
Soma do saldo devedor de todos os contratos que são do determinado
produto e contém diferença acima da estipulada na tela inicial.
Percentual
com Erro
Divisão da coluna Total com Erro em Saldo devedor pela coluna Total
em Saldo Devedor.
Quadro 5 - Definição das características da interface de análise por produto
(Elaborado pelo autor)
4.2.5. Detalhamento dos requisitos funcionais
Por se tratar de um sistema cuja função é única, ou seja, cálculo de Taxa de
Transferência Interna de operações já efetuadas e armazenadas nas bases de dados, existe
apenas um caso de uso. Entretanto, esse caso de uso pode ser subdividido em outros dois, para
uma análise de requisitos mais completa: cálculo para operações com fluxo irregular e cálculo
para operações com fluxo regular.
Essa divisão é útil na medida em que os fluxos de operações internas do sistema são
diferentes para esses dois casos.
Fluxo principal para operações com fluxo de pagamento regular
1. Sistema exibe interface inicial.
2. Analista financeiro define características da verificação. São elas: data de início das
operações que serão verificadas, limite aceitável de erro e quais bases serão
analisadas.
3. Sistema busca na base de dados os contratos definidos.
4. Sistema calcula a TTI justa para o contrato.
5. Sistema compara a taxa calculada com a taxa registrada no banco de dados.
6. Sistema confecciona relatórios.
Fluxo principal para operações com fluxo de pagamento irregular
1. Sistema exibe interface inicial.
75
2. Analista financeiro define características da verificação. São elas: data de início das
operações que serão verificadas, limite aceitável de erro e quais bases serão
analisadas.
3. Sistema busca na base de dados os contratos definidos.
4. Sistema busca na base de dados as parcelas dos contratos previamente definidos.
5. Sistema calcula a TTI justa para o contrato.
6. Sistema compara a taxa calculada com a taxa registrada no banco de dados.
7. Sistema confecciona relatórios.
Nesse fluxo, existe um subfluxo de verificação da existência de parcelas para todos os
contratos. Caso não existam as parcelas referentes ao contrato no banco de dados analisado, o
sistema não será capaz de calcular a Taxa de Transferência Interna justa para o contrato, então
nesse campo o sistema atribuirá o valor “erro”, e esse contrato será considerado como errado.
4.2.6. Detalhamento dos requisitos não funcionais
O requisito não funcional mais evidente desse sistema é a velocidade de cálculo de
cada operação. Como cada cálculo de TTI é feito com base em muitas iterações e existem
centenas de milhares de operações que serão objeto de verificação mensalmente, o tempo para
que o sistema execute todas as operações é muito longo. Entretanto, o sistema só será
executado uma vez por mês, havendo muito tempo para toda a execução.
O cálculo, entretanto, é apenas uma parte do fluxo completo de correção das bases de
dados. A segunda parte, de efetiva discussão com as áreas comerciais sobre a mudança no
valor das Taxas de Transferência Interna nas bases de dados exige uma quantidade de tempo
muito maior. Assim seria justo pensar que, num mês de trinta dias, vinte e cinco desses devem
ser reservados para a discussão com as áreas comerciais, sobrando cinco dias para que os
cálculos sejam realizados.
Outro requisito não funcional é a necessidade que o sistema seja desenvolvido em
linguagem de programação conhecida pelos integrantes da área de Gestão Financeira/ALM,
para que o projeto possa ser alterado no futuro caso necessário, sem que haja dependência de
um indivíduo em especial que conheça a linguagem do sistema. Dessa forma, a decisão é de
utilizar como base para as interfaces do sistema o Microsoft Excel com a linguagem de
programação VBA. Quanto aos bancos de dados, eles já estavam montados em Microsoft
76
SQL, que apresentam facilidade de interação com o Microsoft Excel, portanto não havia
necessidade de mudança.
4.2.7. Classificação dos requisitos
Nessa fase, o caso de uso, as interfaces e os requisitos não funcionais foram
classificados por seu grau de prioridade e pela sua estabilidade, ou seja, possibilidade de que
haja mudança neles ao longo do desenvolvimento do sistema. A seguir, os quadros de
classificação:
Caso de uso:
Caso de Uso Prioridade Estabilidade
Análise mensal das operações Essencial Alta
Quadro 6 - Classificação do caso de uso
(Adaptado de PAULA FILHO, 2003)
Interfaces:
Interface Prioridade Estabilidade
Interface inicial do sistema Essencial Baixa
Interface principal do sistema Essencial Alta
Interface de análise por produto Desejável Média
Quadro 7 - Classificação das interfaces
(Adaptado de PAULA FILHO, 2003)
Requisitos não funcionais:
Requisitos não funcionais Prioridade Estabilidade
Velocidade de cálculo do sistema Essencial Alta
Uso de linguagem de programação
conhecida pela Gestão Financeira/ALM
(VBA)
Essencial Alta
Quadro 8 - Classificação dos requisitos não funcionais
(Adaptado de PAULA FILHO, 2003)
77
4.2.8. Revisão dos requisitos
Após a definição, detalhamento e classificação dos requisitos do sistema, a última fase
necessária foi revisá-los. Para tanto, foi marcada uma reunião com os clientes do sistema, de
modo que esses pudessem validar os requisitos e alinhar as expectativas deles com o que
efetivamente estava sendo desenvolvido.
4.2.9. Resumo das principais necessidades do sistema
Após realizar as duas primeiras etapas propostas, triagem inicial e análise de
requisitos, é possível ter uma visão do que o sistema efetivamente necessita em relação ao seu
propósito, quais as aproximações serão feitas por falta de informação nas bases de dados,
quais as características fundamentais de suas interfaces e qual a necessidade de velocidade de
cálculo para que todo o processo seja realizado.
Então, para que essa visão global do projeto fique facilitada, as principais
características do sistema foram compiladas em um único documento com o intuito de que a
qualquer momento ao longo do processo de desenvolvimento do sistema de cálculo mensal
que houvesse dúvida a respeito de suas características esse resumo estivesse disponível. Essas
principais características são mostradas a seguir:
Escopo
Análise de ativos do banco, denominados em reais, que apresentem funding livre e
tenham taxa de juros prefixados ou indexados à taxa DI.
Caso de Uso
Análise mensal das operações definidas no escopo.
Interfaces
o Inicial: Na qual se determina o mês da análise, quais bases se deseja verificar e
o limite entre a taxa boletada e taxa calculada que será definido como erro.
o Principal: Retorna quais operações contém erro, segundo a definição na tela
inicial, e quais as características dessas operações.
78
o Análise por produto: Agrupa os dados errados segundo seu tipo de produto,
facilitando a análise.
Requisitos funcionais
o Fluxo para operações com fluxo de pagamento regular (Fluxograma 2)
o Fluxo para operações com fluxo de pagamento irregular (Fluxograma 3)
Requisitos não funcionais
o Todos os cálculos do sistema devem ser feitos em, no máximo, cinco dias, para
haver tempo hábil para discussão de alterações com as áreas comerciais.
o O sistema deve ser desenvolvido em linguagem de programação compreensível
aos usuários. Assim, a linguagem escolhida foi o VBA.
Fluxograma 2 - Descrição de atividades em caso de fluxo de pagamento regular
(Elaborado pelo autor)
Fluxograma 3 - Descrição de atividades em caso de fluxo de pagamento irregular
(Adaptado de PAULA FILHO, 2003)
79
4.3. Desenvolvimento do sistema de cálculo mensal
Durante a triagem inicial, foi possível de se ter contato com as bases de dados,
conhecer suas peculiaridades e definir um modelo inicial de como desenvolver o software.
Em seguida, formalizou-se um esquema completo das características do sistema a ser
construído, resultado da análise de requisitos. Então, como proposto na metodologia de
trabalho, a próxima fase foi o desenvolvimento propriamente dito do sistema de cálculo
mensal das operações.
A primeira consideração a ser feita diz respeito às ferramentas utilizadas para a
implementação do sistema. Como definido no detalhamento dos requisitos não-funcionais, as
duas principais ferramentas utilizadas foram o Microsoft SQL para o armazenamento das
informações referentes aos contratos e Microsoft Excel para os cálculos e apresentação dos
resultados.
Com base no detalhamento dos requisitos funcionais da análise de requisitos do
sistema, existem três principais etapas de desenvolvimento: realização da busca dos contratos
nos bancos de dados do Microsoft SQL por meio do Microsoft Excel, realização dos cálculos
da Taxa de Transferência Interna para as operações e apresentação dos dados em uma
interface simples.
Então, a forma escolhida para a efetiva programação do sistema foi dividir o trabalho
nessas três etapas. Vale lembrar também da outra segmentação feita, durante as análises
iniciais do projeto, entre os contratos de fluxo regular e os de fluxo irregular. Pelo fato de que
os irregulares possuem parcelas para descrevê-los detalhadamente, existem algumas
peculiaridades no que diz respeito à sua programação. Sendo assim, para cada uma das três
etapas anteriormente descritas, haverá mais uma divisão, referente ao tipo de fluxo do
contrato.
80
O que se repete em termos estruturais é a forma como as iterações para os cálculos de
todos os contratos são realizados. Assim, o fluxograma que representaria a ideia básica do
sistema desenvolvido é mostrado no Fluxograma 4:
Analisando-se o fluxograma acima, é possível notar que para cada uma das ações,
representadas pelos retângulos, pode haver particularidades entre cada tipo de contrato, porém
a estrutura básica do fluxograma continua a mesma. Então, a seguir, para cada uma das ações,
haverá um melhor detalhamento de como serão implementadas para cada caso particular.
Fluxograma 4 - Processo básico software
(Elaborado pelo autor)
81
O código base do sistema representa a visão mais ampla que se pode ter dos objetivos
do projeto, na medida em que é o responsável por chamar outras funções desenvolvidas, que
realizarão as três principais partes definidas anteriormente, ou seja, ligação com as bases de
dados, cálculo das Taxas de Transferência Interna dos contratos e apresentação das interfaces.
Um dos principais aspectos do sistema desenvolvido é a possibilidade do usuário
escolher qual base de dados ele quer analisar, ou então analisar todas simultaneamente. Dessa
forma, o sistema seria capaz tanto de verificar mensalmente toda a base de novas operações
do banco para checar se essas possuem as taxas corretas, como também analisar apenas um
dos sistemas, em busca de alguma irregularidade particular dele. A ideia para a
implementação disso foi criar funções separadas para baixar as operações e para calcular cada
um dos contratos. Assim, quando o cliente desejasse calcular apenas uma base, somente as
funções de baixar e calcular a definida base deveriam ser chamadas. As linhas de comando
que representam essa estrutura no código base do sistema estão mostradas no Apêndice A,
somente para a função que calcula a base VS, uma vez que os códigos referentes às demais
seriam meras repetições do usado para VS.
4.3.1. Ligação entre bancos de dados e planilha
Nesse momento busca-se detalhar como foi feita a ligação entre as bases de dados
Microsoft SQL que contém a descrição dos contratos válidos do banco com as planilhas do
Microsoft Excel, ambiente no qual foram realizadas os cálculos efetivos de verificação de
cada um dos contratos.
Existem dois tipos de busca que podem ser executadas pelo sistema, busca por
contratos e busca por parcelas, distinção proveniente da segmentação proposta de contratos
com fluxo regular e irregular.
Como descrito durante a triagem inicial, apenas a base VS e a base UG contém
contratos com fluxo irregular, cujas parcelas estão armazenadas nas bases V2 e U2
respectivamente. Portanto para exemplificar os comandos de busca usados para contratos
irregulares, escolheu-se a base VS, pelo simples fato de ter sido a primeira cujos comandos
foram desenvolvidos e posteriormente adaptados à base UG. Os comandos utilizados estão
mostrados e comentados no Apêndice B. Optou-se por mostrar apenas uma das pesquisas,
82
feitas no banco de dados por meio do Microsoft Excel, no caso a consulta para busca das
informações relevantes dos contratos.
O código mostrado no Apêndice B pode facilmente ser adaptado a qualquer outra base
de dados do sistema que estamos tratando, tanto para buscar os contratos de fluxo regular,
como também para buscar as parcelas. Para tanto, apenas duas mudanças são necessárias:
mudar os nomes das colunas que deseja selecionar na função SELECT e o nome da tabela
SQL que deseja consultar, que no exemplo do Apêndice B foi omitida por questão de sigilo.
Com essa etapa realizada, o sistema já possui as informações que deseja analisar no
próprio Microsoft Excel, podendo agora realizar os cálculos para verificação da Taxa de
Transferência Interna.
4.3.2. Realização dos cálculos de Taxa de Transferência Interna do contrato
Esta etapa visa detalhar como é feito o cálculo da TTI do contrato pelo sistema que
será considerada como a taxa correta. Realizado o cálculo desse valor é possível, em seguida,
confronta-lo com o que efetivamente foi registrado no contrato para saber se ambos os
cálculos estão condizentes.
A primeira observação a ser feita para que se possa fazer os cálculos é a necessidade
de se fazer uma diferenciação entre o cálculo das taxas para operações que apresentam fluxos
regulares das que apresentam fluxos irregulares, pelo fato de que o método de cálculo no caso
dos fluxos regulares é mais simples.
Então, optou-se por separar o cálculo das operações nesses dois tipos: fluxos regulares
e irregulares.
4.3.3. Cálculo para contratos de fluxo regular
O fluxo das operações necessárias para se calcular a TTI das operações com fluxo
regular é mostrado a seguir por meio do Fluxograma 5:
83
Fluxograma 5 - Cálculo da Taxa de Transferência Interna em fluxo regulares
(Elaborado pelo autor)
A seguir, descreve-se cada uma das etapas do Fluxograma 5:
1. Calcula número de parcelas do contrato
As bases de dados analisadas não possuem o número de parcelas do contrato, apenas
as datas de início e de vencimento deles. Porém, praticamente todos os de fluxo regular
84
possuem pagamento mensal das parcelas, o que nos possibilita estimar o número de meses do
contrato por meio da seguinte fórmula:
Onde,
= Ano da data de vencimento
= Ano da data de início
= Mês da data de vencimento
= Mês da data de início
Esse valor encontrado para o número de meses do contrato é utilizado no código como
o limite para as iterações no cálculo da TIR aproximada do contrato.
2. Coloca a data da parcela no vetor
Foram criados vetores para armazenar as informações necessárias para o cálculo
aproximado da taxa interna de retorno de um fluxo. Dessa forma, existe um vetor que
armazena o número de dias corridos entre a data de início e a data da parcela, outro para as
taxas Pré para cada uma dessas datas, e um terceiro que armazena o valor presente das
parcelas de um contrato em sistema price.
Assim, no código existe um loop, que termina quando o número de parcelas do
contrato for alcançado, responsável por colocar no vetor designado esse número de dias
corridos. Para fazê-lo, o programa insere na próxima posição do vetor o valor referente à
posição anterior acrescida de um mês, ou seja, 30 dias já que foi adotado o cálculo com base
em dias corridos, conforme a fórmula a seguir:
3. Busca a taxa Pré para a data da parcela
Com o número de dias corridos da parcela, é possível buscar, em outro banco de
dados, qual a taxa DI de fechamento do mercado desde a data de início do contrato até a data
de pagamento dessa parcela. Esse valor é armazenado em outro vetor, para uso posterior.
85
4. Calcula a Taxa de Transferência Interna da parcela
Com a taxa Pré do período, pode-se acrescentar a ela um valor correspondente ao
custo proveniente do FGC e do Depósito Compulsório. Esse custo pode ser entendido como a
Taxa de Transferência Interna de uma operação bullet que comece na data de início do
contrato e será paga na data de vencimento da parcela.
Como exposto na análise do modelo de FTP adotado pela instituição financeira, o
Matched-maturity marginal cost of funds, ele propõe a adoção de uma tabela para geração de
ativos cuja taxa de juros cobrada seja crescente conforme o prazo do empréstimo aumenta e
expressa em função de alguma taxa flutuante, no caso do Brasil, em função de um percentual
da taxa DI. Assim, com base nessa tabela e na taxa Pré, pode-se calcular a TTI dessa parcela
pela seguinte fórmula:
Onde,
= Taxa de Transferência Interna da parcela da data i.
= Taxa Pré da data de início até a data do pagamento i.
= Taxa da tabela de geração de ativos, expressa em um percentual da taxa DI, para um
fluxo da data de início do contrato.
5. Calcula o valor presente da parcela
O próximo passo é calcular o valor presente do pagamento da parcela. Como se trata
de um fluxo em sistema price, os valores futuros dos pagamentos são todos iguais por isso é
possível parametrizar esse cálculo, fazendo com que esse valor presente seja calculado sem o
valor efetivo da parcela, como será mais bem explicado no próximo passo.
6. Realiza o cálculo aproximado da TIR do contrato
O cálculo aproximado da taxa interna de retorno pode ser expresso como uma média
ponderada entre da taxa Pré, ponderando-a com relação ao valor presente dos fluxos de
pagamento e do número de dias entre as datas de início e as datas de pagamento. Assim a
fórmula da TIR aproximada é:
86
∑
∑
Onde,
= Valor presente do fluxo de pagamento da data i
= número de dias corridos entre a data do pagamento i e a data de início do contrato
= taxa Pré da data de início até a data do pagamento i.
n = número de parcelas
É importante notar que, como os valores futuros das parcelas são todos iguais, eles se
tornam constantes quando é feita a aproximação da TIR, e assim podem ser retirados de
dentro do somatório. Como eles estão presentes tanto no numerador como no denominador
(pela expressão do valor presente que será vista abaixo), eles podem ser simplificados. Por
isso, quando é guardado o valor presente no vetor, ele é independente do valor da parcela a ser
paga. Isso pode ser percebido nas expressões a seguir:
Onde,
= Valor futuro do fluxo de pagamento da data i, ou seja, o valor da parcela nessa data.
= Taxa de Transferência Interna da parcela da data i, que está armazenada em um dos
vetores.
= Número de dias corridos entre a data do pagamento i e a data de início do contrato.
Por ser tratar de um fluxo regular, ou seja, cujo valor das parcelas e as datas de
pagamentos são padronizados, o valor de todas as parcelas dos contratos é igual. Dessa forma,
não é necessário se referir a um valor futuro do fluxo como VFi, no qual o índice i é usado
para distinguir um valor futuro do outro, podendo se referir ao valor futuro apenas como VF,
e a expressão da taxa interna de retorno aproximada para o fluxo pode ser escrita da seguinte
forma:
87
∑
∑
Como o valor futuro (VF) é uma constante em ambos os somatórios, ele pode ser
colocado em evidência. Como está presente tanto no numerador como no denominador, pode
ser simplificado, resultando na expressão a seguir:
∑
∑
Como todas as variáveis da expressão estão armazenadas em vetores do sistema, é
possível calcular o valor da TIR aproximado para cada um dos contratos regulares.
Diversas bases de dados seguem esse padrão de cálculo no sistema, sendo elas: OZ,
HE, GC, YD e S8. Para exemplificar esse cálculo e registrar todo o desenvolvimento do
sistema, optou-se por mostrar os comandos executados para esse cálculo no caso da base de
dados HE. A razão é a mesma do código mostrado anteriormente (busca nas bases de dados
do sistema VS), ou seja, foi o primeiro a ser efetivamente implementado e testado.
No Apêndice C encontra-se o código comentado e relacionado com as explicações
dadas anteriormente sobre os cálculos. Para entendê-los com propriedade é necessário
complementar com os códigos existentes no Apêndice D, que correspondem a algumas
funções que são chamadas pelos código do cálculo dos fluxos irregulares. Essas funções são a
descrição completa do cálculo da Taxa de Transferência Interna para o caso de fluxos
regulares.
A partir desse ponto o sistema já calcula a Taxa de Transferência Interna e a compara
com a existente no registro das bases de dados (para o caso dos fluxos regulares).
88
4.3.4. Cálculo para contratos de fluxo irregular
Para a realização do cálculo da taxa interna de retorno aproximada para esse tipo de
contrato é necessário ter o valor e a data de pagamento de cada uma das parcelas. Assim, para
os contratos que apresentam fluxo irregular é necessário buscar no banco de dados SQL a
descrição de cada uma das parcelas, e não somente sua data de início, como no caso dos
contratos com fluxo de pagamento regular.
Enquadram-se nesse tipo de cálculo, como descrito anteriormente, os contratos do
banco de dados VS e alguns contratos do banco de dados UG.
Sendo assim, o Fluxograma 6 representa o cálculo a taxa interna de retorno
aproximada para cada contrato:
89
Fluxograma 6 - Cálculo da Taxa de Transferência Interna em fluxos irregulares
(Elaborado pelo autor)
1. Conta o número de parcelas no contrato
Por se tratar do cálculo de operações com fluxo de pagamento irregular, e que
portanto, existe a descrição de cada uma das parcelas, não há a necessidade de estimar o
número de pagamentos do contrato, basta contar quantos foram armazenados nas bases de
dados que os descrevem e então se obtém esse valor.
90
2. Coloca a data da parcela no vetor
Diferentemente do caso dos fluxos regulares, nesse caso a data de pagamento das
parcelas não é padronizada, e assim é necessário guardar cada uma delas no vetor destinado a
isso. Esses dados são provenientes do banco de dados V2, quando o contrato analisado está
armazenado no sistema VS, e do banco de dados U2 quando o contrato analisado está contido
no banco de dados UG. Lembrando que os bancos de dados V2 e U2 são os que armazenam
as informações detalhas de cada parcela dos contratos, quando o fluxo do contrato é irregular.
Na prática, armazena-se o valor realmente usado pelos cálculos, que é o número de dias
corridos entre a data de pagamento da parcela e a de início, realizando a subtração entre as
duas datas.
3. Coloca o valor da parcela no vetor
Assim como para o caso anterior da data da parcela, o valor do pagamento de cada
uma delas pode variar ao longo do contrato, por isso, para que o cálculo seja feito
apropriadamente, é necessário armazenar o valor do pagamento de cada parcela em outro
vetor apropriado. Esses dados também são encontrados nos bancos de dados V2 e U2, assim
como a data de pagamento das parcelas dos contratos de fluxo irregular.
4. Busca a taxa Pré para a data da parcela
Da mesma forma como é feito para o caso dos fluxos regulares, busca-se em outro
banco de dados a taxa Pré desde a data de início do contrato até a da parcela em questão.
5. Calcula a Taxa de Transferência Interna da parcela
Assim como no caso feito nos fluxos regulares, acresce-se à taxa Pré os custos
relativos à contribuição feita ao FGC e o depósito compulsório no Banco Central, por meio do
uso da mesma tabela expressa em percentual da taxa DI e da expressão usada no caso dos
fluxos regulares, chegando-se à Taxa de Transferência Interna do fluxo relativo à parcela que
deve ser paga na data de vencimento analisada nessa iteração.
6. Calcula o valor presente da parcela
Para se calcular o valor presente da parcela, é possível de se utilizar a expressão a
seguir:
91
Onde,
= Valor futuro do fluxo de pagamento da data i, ou seja, o valor da parcela na data
analisada, armazenado em um dos vetores.
= Taxa de Transferência Interna da parcela da data i, que está armazenada em um dos
vetores.
= número de dias corridos entre a data do pagamento i e a data de início do contrato.
Esse valor presente é armazenado em um vetor, assim como os demais.
7. Realiza o cálculo aproximado da TIR do contrato
O cálculo da taxa interna de retorno aproximada para esse tipo de fluxo é feito baseado
na mesma fórmula inicial que foi utilizada para o cálculo dos pagamentos regulares.
Entretanto, nesse caso os fluxos de pagamento não são regulares, então não é possível realizar
a simplificação que elimina o valor futuro da parcela da expressão. Assim, a fórmula utilizada
é a mostrada a seguir:
∑
∑
Onde,
= Valor presente do fluxo de pagamento da data i
= número de dias corridos entre a data do pagamento i e a data de início do contrato
= taxa Pré da data de início até a data do pagamento i.
n = número de parcelas
92
É intuitivo perceber que cada um dos termos da expressão acima está armazenado em
algum dos vetores utilizados nos itens anteriores, assim basta substituir os valores na
expressão para obter a taxa interna de retorno aproximada do contrato analisado.
No que diz respeito à programação, as únicas diferenças claras são a verificação no
início da rotina, para saber se as bases de dados possuem as parcelas referentes ao contrato
analisado e a função de cálculo da Taxa de Transferência Interna que não é a calctec_360
(detalhada no Apêndice D). A diferença entre as duas funções está no armazenamento de dias
corridos no vetor (que no caso de fluxo irregular é um dado fornecido pela parcela
armazenada no banco de dados) e no cálculo do valor presente da parcela. Então, os códigos
dessas duas etapas foram os únicos expostos no presente trabalho, a fim de evitar repetições
que não agregariam valor ao resultado final.
As linhas de comando comentadas dessas duas partes que diferem dos fluxos regulares
podem ser encontradas no Apêndice E.
A partir desse momento, o sistema já calculou as Taxas de Transferência Interna para
qualquer tipo de operação definida no escopo, as comparou com as taxas registradas nos
bancos de dados e tem condições de separar as operações com taxa fora do limite estipulado
pelo usuário. Então, a última etapa desse projeto é a forma como esses dados analisados serão
apresentados ao usuário, de forma que a interface seja intuitiva e clara.
4.3.5. Apresentação das interfaces
Para uma boa interação de um sistema com seus usuários é fundamental que as
interfaces apresentem boa qualidade. Na medida em que os softwares são desenvolvidos com
o foco principal em suprir as necessidades dos clientes, não basta apenas que o sistema realize
o que foi definido em seus casos de uso, ele precisa fazê-lo de forma que o usuário interaja
com facilidade, podendo repetir o processo sem dificuldade, além de obter resultados cuja
compreensão seja feita da maneira mais simplificada o possível.
Nessa etapa do trabalho, buscou-se aprimorar todo o desenvolvimento anterior,
principalmente no que diz respeito aos esboços das interfaces elaborados durante a Análise de
Requisitos desse projeto, apoiando-se em algumas das características pesquisadas em Paula
Filho (2003), conforme os itens abaixo.
93
Simplicidade e Memorização
O sistema desenvolvido se baseia em apenas um caso de uso, que, embora exija muitos
cálculos, não impõe grandes dificuldades ao usuário que operá-lo. Assim, o usuário, que inicia
a operação na interface inicial, só deve preencher os parâmetros da análise, clicar no botão de
início e aguardar até que as bases sejam totalmente calculadas. Portanto, o sistema é simples e
não exige grande esforço de memorização dos passos por parte do usuário. As únicas
intervenções realizadas sobre as interfaces previamente definidas na Análise de Requisitos
nesse ponto foram as inserções de botões para levar o usuário da interface principal (a que
possui todas as operações identificadas como erradas pelo sistema) às demais interfaces do
sistema após todos os cálculos já realizados, como mostrado na Figura 10:
Para a escolha de como seriam feitos os leiautes dos botões, optou-se por utilizar um
conceito ligado à cognição dos seres humanos. Dessa forma, segundo Paula Filho (2003),
símbolos usados como metáfora são úteis para facilitar o entendimento do usuário quanto ao
funcionamento de uma determinada função. Assim, decidiu-se colocar a imagem de uma
flecha voltada para a direita após da palavra “produtos”, para indicar que esse seria o caminho
usual de análise dos dados processados. Além disso, colocou-se outra flecha, voltada para a
Figura 10 - Interface principal definitiva do sistema
(Elaborado pelo autor)
Erros Encontrados Limite de Erro
Saldo Devedor c/ Erro
Saldo Devedor Total
Percentual correto
Chave do
ContratoData de Início Data de Fim Taxa TTI
Taxa do
Cliente
Saldo
Devedor
Valor
Original
Descrição do
Produto
Taxa
Calculada
pelo Sistema
Diferença
Entre as
Taxas
Produtos →
← Capa
94
esquerda anteriormente à palavra “Capa”, indicando que esse é o caminho de retorno do
sistema.
Modelo mental do funcionamento de software
Um software bem desenvolvido é capaz de produzir na mente de seus usuários um
modelo de funcionamento para ele que seja replicável à maioria das suas funções. Como
exposto anteriormente, no sistema desenvolvido o caso de uso é único, o que simplifica muito
o processo de navegação do usuário, uma vez que basta a ele definir os parâmetros de análise,
clicar no botão que inicia os cálculos e aguardar enquanto o sistema os processa.
Entretanto, não somente a navegação deve ser estudada em termos de modelo mental,
também a forma de interpretação dos dados retornados pelo sistema deve ser facilmente
compreendida pelo usuário. Assim, o modelo mental pode servir também para maneira como
o usuário deve interpretar as informações a ele transmitidas. No caso do sistema
desenvolvido, optou-se por sempre mostrar os dados do mesmo modo, ou seja, por meio de
tabelas que compilem as informações desejadas.
Exibição
Assim como no caso do modelo mental para análise dos dados provenientes do
sistema desenvolvido, para que a exibição das interfaces seja clara é altamente recomendável
que haja padronização na forma como elas são dispostas. Então, para cada uma das interfaces
de análise propostas, optou-se por posicionar as tabelas de exibição de dados sempre no
mesmo local.
Para que o sistema apresente boa exibição, também é muito importante que a
formatação das informações seja padronizada. Assim, todas as taxas, antes de dispostas aos
olhos do público foram formatadas como percentual com duas casas decimais. Além disso,
todos os volumes de operações apresentam também duas casas decimais e ponto separando os
milhares.
Todos os comandos para esse tipo de programação não foram exibidos nesse trabalho,
pois se tratam apenas de comandos simples de formatação do Microsoft Excel adaptados ao
VBA, portanto não acrescentam conteúdo relevante.
95
Atração da atenção
Uma questão muito importante quando se projeta uma interface em um software é
definir para que tipo de informação deve-se voltar a atenção do usuário e qual é a forma
utilizada para conseguir que ele foque no que se deseja colocar em evidência.
O número de informações que o usuário deve atentar precisa ser pequena, caso
contrário, não haverá foco em nada. Portanto, é importante selecionar com cuidado os pontos
de atenção. Para o sistema desenvolvido, as três interfaces mais relevantes tem seus pontos de
evidência, justificativas e forma de conseguir evidenciar o que se deseja, conforme abaixo:
o Interface inicial
Possui foco nas células que devem ser preenchidas, pois isso é essencial para que o
sistema possa buscar nas bases de dados do banco e realizar os cálculos. Para direcionar a
atenção do usuário nisso, optou-se por colorir essas células e coloca-las em forma de lista,
diferenciando-as das demais dessa interface.
o Interface principal
Essa interface, que possui todos os contratos com erro encontrados pelo sistema, tem
como foco sua tabela com a somatória dos volumes de operações analisado e do volume de
erro encontrado e qual é essa proporção. Esse é o dado mais relevante, pois indica qual o grau
de erros dessa base de dados. Para evidenciar essas informações buscou-se centraliza-las
horizontalmente e coloca-las na parte superior da interface, além de formatar as linhas de sua
tabela de maneira diferenciada.
o Interface de análise por produto bancário
Como os dados mais importantes dessa interface são as tabelas contendo o volume de
erro de cada tipo de produto bancário, optou-se por deixar apenas esses dados na interface, no
formato das tabelas padronizadas discutidas anteriormente, sendo assim o único objeto a ser
observado na interface.
96
Realimentação
É comum usuários ficarem confusos ao utilizarem um sistema que após um longo
período de tempo não fornece resposta alguma a eles. Nesses casos, em geral, o usuário não
sabe se ocorreu algum erro e o sistema não está mais funcionando ou se ele está apenas em
um processo demorado. Pode ocorrer então de, caso o sistema não proporcione algum tipo de
feedback informando que está em um processo demorado, o usuário acreditar que haja algum
problema no seu processo e o reinicie sem necessidade.
Esse é um problema que poderia ocorrer com o sistema desenvolvido, uma vez que,
por ter de realizar cálculos de muitas operações, pode ter seu tempo total de processo de
algumas horas.
Uma forma de orientar os usuários de que o processo é longo é mostrar a eles, na
interface inicial, as datas e horários de início e fim da última verificação realizada. Entretanto,
isso não é suficiente para convencer um usuário de que depois de algumas horas de processo,
o sistema não apresentou algum tipo de problema. Dessa forma, optou-se por inserir mais
algumas informações na interface inicial do sistema, mudando ligeiramente o esboço
desenhado para essa interface na análise de requisitos. As novas informações disponibilizadas
são o número de bases de dados que o sistema irá calcular (dependendo da escolha inicial do
usuário), qual base de dados o sistema está calculando no momento (não seu nome, mas sim
se é a primeira, a segunda ou a enésima), quantas operações essa base possui e em qual
operação o sistema está realizando os cálculos no momento (novamente, não o número do
contrato da operação, mas sim sua posição em relação ao total). Assim, a interface que se
chegou está mostrada na Figura 11:
97
Figura 11 - Interface inicial definitiva do sistema
(Elaborado pelo autor)
Com o desenvolvimento das interfaces terminado, a construção do produto proposto
no início do presente trabalho está concluído, podendo então se dar início à efetiva
implementação do mesmo no processo de centralização dos riscos de mercado na Gestão
Financeira/ALM.
Para tanto, uma etapa importante diz respeito à sessão de treinamento dos usuários, na
qual eles têm o primeiro contato com o sistema totalmente desenvolvido e pronto para
utilização. Pelo fato de o sistema ser simples e de que os usuários finais participaram de todo
o processo de desenvolvimento, principalmente para a definição do escopo e dos resultados
obtidos, essa etapa foi relativamente fácil. Houve apenas a necessidade de explicar quais eram
os parâmetros que deveriam ser inseridos no início da verificação (data de início das
operações analisadas, diferença aceita entre a taxa registrada e a taxa calculada e quais bases
de dados seriam verificadas) e apresentar as interfaces de análise, tanto a que mostra todas as
operações que apresentaram erro, como a que as agrupa por tipo de produto.
Início da última verificação Fim da última verificação
dd/mm/aaaa hh:mm:ss dd/mm/aaaa hh:mm:ss
Bases Operações
Atual x xxxxxx
Total x xxxxxx
Mês das operações
verificadasQual Base?
dd/mm/aaaa VS
Limite Erro
x,xx%
Executar Cálculos
98
4.4. Impacto da introdução do sistema no processo
O problema definido inicialmente pode ser analisado da perspectiva de que era
proveniente de um processo elaborado sem etapa de controle da atividade de centralização dos
riscos de mercado. Dessa forma, o processo de geração de ativos por parte da instituição era,
em uma visão bastante simplificada, composto internamente de três etapas mostradas na
Figura 12:
Figura 12 - Atual processo de geração de ativos
(Elaborado pelo autor)
1. Realização do cálculo da TTI por parte da Gestão Financeira/ALM que a
transmitia para a área comercial solicitante da cotação.
2. Registro da operação (caso concretizada com o cliente) nas bases de dados da
organização.
3. Cálculo do resultado financeiro de cada área baseado nos dados registrados
nessas bases.
99
Com essa estrutura para o processo, a Gestão Financeira/ALM, não possuía
mecanismos para garantir a qualidade da etapa 2 da figura acima, uma vez que a taxa
calculada era comunicada às áreas comerciais via e-mail, não havendo forma de assegurar que
foi utilizada a mesma no momento do registro do contrato nas bases de dados. Como
discutido ao longo do trabalho, essa falha, além de causar assimetria nos resultados internos
do banco, fere a metodologia utilizada como política de FTP.
Com a introdução do sistema desenvolvido nesse processo, uma etapa de controle é
incluída, conforme a Figura 13:
Figura 13 - Processo de geração de ativos com a introdução do novo sistema
(Elaborado pelo autor)
Com a inclusão dessa essa etapa de controle, o sistema retorna à Gestão
Financeira/ALM as operações do mês anterior que possuem TTI distinta do que seria o
esperado com base nas curvas de geração de ativos da instituição e taxas de juros de mercado.
Com essa informação, o processo pode ser expandido com mais duas etapas:
100
4. Gestão Financeira/ALM entra em contato com as áreas comerciais para discutir
a situação dessas operações.
5. Em caso de concordância entre as áreas, a Gestão Financeira/ALM aciona a
área de contabilidade para realizar os ajustes de resultado.
O maior desafio desse novo fluxo é a discussão com as áreas comerciais, cujo
resultado financeiro é impactado diretamente com a nova ferramenta. É importante ressaltar,
entretanto, que o ajuste de taxas ocorre em ambos os sentidos, ou seja, também há correção no
caso da Gestão Financeira/ALM ser impactada negativamente em seu resultado. Nesses casos
certamente a discussão com as áreas comerciais é mais simples, pois o resultado delas é
aumentado.
Embora o cálculo da Taxa de Transferência Interna pelo sistema esteja correto, e ele
aponte as operações cuja taxa não é condizente, isso não é prova irrefutável de que houve erro
por parte das áreas comerciais e que, portanto as taxas devem ser corrigidas. Existem casos de
operações estrategicamente importantes, como no caso de um cliente importante para o banco,
em que a área de Gestão Financeira/ALM subsidia a TTI da operação, arcando com o
prejuízo, para viabilizar o negócio. Essas ocorrências, embora não muito frequentes,
acontecem. Assim, nesse tipo de discussão entre as áreas, caso haja discordância sobre a taxa
registrada estar ou não correta, a única prova que garante a taxa efetivamente comunicada é o
e-mail trocado entre as partes, no qual ela foi formalizada e acordada inicialmente.
O melhor argumento para que haja ajuste nas taxas equivocadas, embora ocorram
prejuízos pontuais para algumas áreas em determinados momentos é, sem dúvida a busca pelo
completo alinhamento entre a metodologia de funds transfer pricing adotada pela organização
e a que realmente acontece que, como discutido ao longo de todo o projeto, sempre foi a
maior motivação para o desenvolvimento do sistema.
101
5. Análise crítica do projeto
No presente trabalho buscou-se desenvolver um sistema capaz de verificar a coerência
das Taxas de Transferência Interna das operações registradas nas bases de dados do banco em
que o autor realizou seu estágio. O principal objetivo do desenvolvimento dessa ferramenta é
utilizá-la como forma de controle do cumprimento das políticas internas de FTP da instituição
financeira, dado que esse controle era inexistente e é dessa política que se deriva a gestão de
liquidez da empresa.
Antes do início do projeto, houve a necessidade de apoio da literatura, tanto no que
tange o desenvolvimento de projetos de software, baseando-se principalmente nos livros que
tratam de levantamento de requisitos de sistemas de informação, como também as que
embasassem os modelos utilizados de funding trasfer pricing, ainda mais por se tratar de um
conceito um pouco distante dos que são costumeiramente tratados no curso de Engenharia de
Produção.
Ao longo de todo o projeto, um grande diferencial foi a presença e o respaldo contínuo
dos usuários finais do sistema criado, nas mais diversas etapas de desenvolvimento. Dessa
forma, do início ao fim do projeto, as expectativas dos clientes estavam alinhadas com o que
era efetivamente desenvolvido pelo autor. Esse alinhamento, que é uma das grandes
preocupações ao se realizar a análise de requisitos de um sistema de informação, portanto,
aconteceu naturalmente ao longo das etapas, pois a cada novo passo dado pelo autor, os
usuários acompanhavam o que estava sendo construído.
Entretanto, como ressaltado ao longo do trabalho, assim como todo modelo, esse
também necessitou de simplificações para poder ser implementado. Embora, em termos de
volume das operações, esse primeiro projeto tenha abrangido a maior parte dos ativos da
instituição financeira, ele deixou de lado alguns ativos. Além disso, também não analisou as
Taxas de Transferência Interna dos passivos do banco. Como objetivo de longo prazo busca-
se, portanto, a expansão desse primeiro sistema para novas versões, capazes de englobar um
número cada vez maior de operações.
Embora o sistema tenha a capacidade de identificar as operações que não respeitam as
políticas de FTP do banco, para que o sistema se insira completamente no processo de
centralização dos riscos de mercado, talvez a grande dificuldade ainda seja o contato com as
102
áreas comerciais para a correção das Taxas de Transferência Interna nas bases de dados do
banco, uma vez que essa mudança causa alteração nos resultados financeiros dessas áreas.
Embora o novo processo ainda não esteja instalado, o sistema já foi utilizado algumas
vezes pela Gestão Financeira/ALM. O próprio autor foi responsável pelas interações com o
sistema e assumiu o papel do analista financeiro no diagrama de contexto criado no trabalho.
O objetivo dessas utilizações era o mesmo que motivou a triagem inicial das bases de dados,
ou seja, buscar contratos de grande volume financeiro que contivessem erros nas TTI. Essas
operações, quando encontradas, serviriam como argumento a favor da implementação do
novo fluxo de atividades para o processo estudado.
Nessa etapa, que analisou todos os contratos do escopo do projeto que apresentam data
de início superior a 2 de janeiro de 2009, foram encontradas diversas operações com erro na
TTI em quase todas as bases de dados, como pode ser visto no
Quadro 9, que é um resumo de todos os contratos analisados:
Base de dados Percentual (em saldo
devedor) sem erro
VS 69%
UG 87%
OZ 94%
YD 82%
S8 100%
HE 97%
GC 81%
Quadro 9 - Percentual de erros encontrados em cada base de dados
(Elaborado pelo autor)
Ao observar o quadro acima, percebe-se claramente que a base VS possui o maior
volume percentual de operações erradas. Esta armazena as informações relativas aos maiores
contratos de empréstimo da instituição, que, portanto, devem respeitar o processo de cotação
da TTI diretamente com a Gestão Financeira/ALM no momento em que a operação é
realizada, pelo envio de e-mail, estando então suscetível à falta de controle destacada ao longo
do trabalho. Então, era esperado que essa fosse a base de dados com maior volume de erros,
enfatizando ainda mais a necessidade do uso do sistema produzido como parte de um
processo estruturado de correção.
103
Nessa análise, algumas operações apresentavam erros notadamente graves, com
destaque, por exemplo, para casos em que a base informava que o contrato comtemplava
pagamento de taxa de juros prefixada e, na realidade a que deveria ser cobrada era taxa DI
somada a uma taxa prefixada. Isso foi descoberto ao analisar o contrato propriamente dito,
após uma reunião com a área comercial responsável por essa operação, e a explicação para
esse erro foi que havia um descompasso entre a base de dados, que somente aceitava registros
de operações prefixadas, e o contrato, que era uma exceção, pois em geral aquele tipo de
produto não era indexado à taxa DI. A partir desse diagnóstico, esse tipo de produto passou a
ser alocado em outra base de dados.
Nesse sentido, percebeu-se uma função secundária para o sistema desenvolvido, a de
encontrar inconsistências nas bases de dados e contribuir para promover seu aprimoramento, a
partir desse tipo de feedback.
Finalizando, ao realizar o balanço do trabalho como um todo, o saldo foi positivo. O
cliente, a área de Gestão Financeira/ALM, obteve um primeiro mecanismo de controle
gerencial de suas operações, podendo garantir que sua política de Taxas de Transferência
Interna seja respeitada pelas áreas comerciais e preservando seu resultado financeiro dentro da
organização. Mas certamente o maior beneficiado pelo trabalho é seu autor que, por meio da
realização desse projeto, teve a oportunidade de aprimorar seus conhecimentos em diversas
áreas, como em relação à sistemática que envolve o desenvolvimento de um sistema de
informação e sobre as políticas de FTP, estando, ao final dessa jornada, mais bem preparado
para dar continuidade a seus estudos e ingressar na vida profissional.
104
6. Referências
ARENALES, S.; DAREZZO, A. Cálculo Numérico Aprendizagem com apoio de software.
São Paulo: Thomson Learning, 2008.
BANCO CENTRAL DO BRASIL. Depósitos Compulsórios. 2012. Disponível em:
<http://www4.bcb.gov.br/pec/gci/port/focus/FAQ%2012-
Dep%C3%B3sitos%20Compuls%C3%B3rios.pdf>. Acesso em: 22 de setembro de 2012.
______. FGC – Introdução. Disponível em: <http://www.bcb.gov.br/?FGCINTRO>. Acesso
em: 15 de maio de 2012.
BASEL COMMITTEE ON BANKING SUPERVISION. Basel III: International
framework for liquidity risk measurement, standards and monitoring. Bank for
International Settlements. 2010. Disponível em <http://www.bis.org/publ/bcbs188.pdf >.
Acesso em: 02 outubro 2012.
BM&F BOVESPA. Contrato Futuro de Taxa Média de Depósitos Interfinanceiros de Um
Dia. Disponível em:
<http://www.bmfbovespa.com.br/shared/iframe.aspx?altura=1400&idioma=pt-
br&url=www.bmf.com.br/bmfbovespa/pages/contratos1/contratosProdutosFinanceiros1.asp?
WT.ac=DerivativosFinanceiros>. Acesso em: 15 de maio de 2012.
BRASIL. Lei nº 12.703, de 7 de agosto de 2012. Altera o art. 12 da Lei no 8.177, de 1º de
março de 1991, que estabelece regras para a desindexação da economia e dá outras
providências, o art. 25 da Lei no 9.514, de 20 de novembro de 1997, que dispõe sobre o
Sistema de Financiamento Imobiliário, institui a alienação fiduciária de coisa imóvel e dá
outras providências, e o inciso II do art. 167 da Lei no 6.015, de 31 de dezembro de 1973, que
dispõe sobre os registros públicos e dá outras providências. Disponível em:
<http://www.planalto.gov.br/ccivil_03/_Ato2011-2014/2012/Lei/L12703.htm >. Acesso em:
20 de outubro de 2012.
CAMPOS, V. F. Gerenciamento da rotina do trabalho do dia-a-dia. Belo Horizonte:
Editora de Desenvolvimento Gerencial. 1998.
CARDOSO, R.F.; KOYAMA, S.M. Juro e Spread Bancário no Brasil, A Cunha Fiscal
Sobre a Intermediação Financeira. Apêndice A. 1999. Disponível em
<http://www.bcb.gov.br/ftp/juros-spread2.pdf>. Acesso em: 22 setembro de 2012.
105
CENTRAL DE CUSTÓDIA E LIQUIDAÇÃO FINANCEIRA DE TÍTULOS. Disponível
em: <http://www.cetip.com.br/Institucional/seguran%C3%A7a-que-move-o-mercado#!>.
Acesso em: 18 de abril de 2012.
CHOUDHRY, M. Bank Asset and Liability Management Strategy, Trading, Analysis.
Singapore: John Wiley & Sons (Asia) Pte Ltd. 2007.
FELICIANO NETO, A.; SHIMIZU, T. Sistemas Flexíveis de Informações. São Paulo:
Makron Books, 1996.
FUNDO GARANTIDOR DE CRÉDITO. Características. Disponível em:
<http://www.fgc.org.br/?conteudo=1&ci_menu=48>. Acesso em: 15 de maio de 2012.
______. Limite de cobertura ordinária. Disponível em:
<http://www.fgc.org.br/?conteudo=1&ci_menu=20>. Acesso em: 15 de maio de 2012.
______. Objetos de garantia. Disponível em:
<http://www.fgc.org.br/?conteudo=1&ci_menu=19>. Acesso em: 15 de maio de 2012.
GITMAN, L. J. Princípios de Administração Financeira. São Paulo: Pearson Addison
Wesley, 2004.
GRANT, J. Liquidity transfer pricing: a guide to better practice. (Occasional Paper n 10).
Australian Prudential Regulation. Financial Stability Institute. 2011. Bank for International
Settlements. 2011. Disponível em: <http://www.bis.org/fsi/fsipapers10.pdf>. Acesso em: 10
de abril de 2012.
MANKIW, N. G. Introdução à Economia. São Paulo: Cengage Learning, 2009.
NIELSEN, J. Usability Engineering. San Francisco: Morgan Kaufman, 1993.
PANDE, P. S.; NEUMAN, R. P.; CAVANAGH, R. R. Estratégia seis sigma: como a GE, a
Motorola e outras grandes empresas estão aguçando seu desempenho. Rio de Janeiro:
Qualitymark Ed., 2001.
106
PAULA FILHO, W. de P. Engenharia de Software: Fundamentos, Métodos e Padrões.
Rio de Janeiro: LTC, 2003.
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. [S.l.]:McGraw-Hill,
1992.
SECURATO, J. R. et al. Cálculo Financeiro das Tesourarias – Bancos e Empresas. São
Paulo: Saint Paul, 1999.
STAIR, R. M. Princípios de Sistemas de Informação Uma Abordagem Gerencial. Rio de
Janeiro: LTC, 1998.
WIEGERS, K. E. Software Requirements Practical techniques for gathering and
managing requirements throughout the product development cycle. Universidade de
Michigan: Microsoft Press, 2003.
107
APÊNDICE A – Código básico do sistema para a base de dados VS
' Início da rotina
Sub calculabase()
' Declaração de variáveis omitida
' A função Coloca_valores_VS somente é chamada pelo código caso o autor tenha definido na
interface inicial que a base de dados VS será calculada.
If _
ThisWorkbook.Sheets("Capa").Range("A14") = "VS" _
Or _
ThisWorkbook.Sheets("Capa").Range("A14") = "Todas" _
Then _
Call Coloca_valores_VS
' Coloca_valores_VS é a função que busca os contratos de VS nos bancos de dados e depois
calcula se a Taxa de Transferência Interna está correta.
' O código é muito mais extenso, porém é uma repetição da estrutura acima. Existe um
comando If igual a este para cada uma das bases de dados que podem ser calculadas pelo
sistema, definidas durante a análise de requisitos.
End If
End sub
' Como se pode perceber pelo código acima, ele só serve para chamar as funções necessárias
em determinado momento. Para descrever cada uma das ações que fazem parte do fluxograma
do processo básico do software, existem outras duas funções, que serão descritas adiante, uma
para buscar os contratos ou parcelas nos bancos de dados nos quais estão armazenados e outra
para efetivamente calcular a Taxa de Transferência Interna justa do tal contrato e compara-la
com a taxa registrada.
108
APÊNDICE B – Código de consulta à uma base de dados de Microsoft SQL
' Inicia rotina de busca na base VS do Microsoft SQL.
Public Sub Baixa_VS()
' Calcula a aba “Capa”, na qual o usuário imputa as definições de data de início das operações
que deseja analisar, tamanho do erro que deseja considerar e quais bases analisar. A aba
precisa ser calculada para que a partir da data de início imputada pelo usuário, se calcule o
último dia do mês, que é o escopo dos contratos analisados.
ThisWorkbook.Sheets("Capa").Calculate
' Declaração das variáveis omitida.
' Limpeza dos conteúdos das células que armazenarão a busca para dar lugar às novas
informações que serão buscadas.
ThisWorkbook.Sheets("Contratos_Irregulares").Range("b5:aa100000").ClearContents
ThisWorkbook.Sheets("Parcelas").Range("b5:aa100000").ClearContents
ThisWorkbook.Sheets("Resultados_VS").Range("b9:aa100000").ClearContents
ThisWorkbook.Sheets("Análise_VS").Range("c5:f200000").ClearContents
' Variáveis que definem o escopo da busca, ou seja o mês analisado, recebem os valores
imputados na interface pelo usuário.
Data1 = ThisWorkbook.Sheets("Capa").Range("av5")
Data2 = ThisWorkbook.Sheets("Capa").Range("av6")
'Como as buscas são feitas uma de cada vez, optou-se por compartilhar planilhas que
armazenarão os dados das buscas. Para todas as buscas de contratos com fluxos regulares
existe uma, para fluxos irregulares outra, e para parcelas uma terceira. As linhas de comando
abaixo identificam que base está presente nessa aba compartilhada no momento.
ThisWorkbook.Sheets("Contratos_Irregulares").Range("D1") = "VS"
'ThisWorkbook.Sheets("Contratos_Regulares").Range("D1") = "VS"
109
ThisWorkbook.Sheets("Parcelas").Range("D1") = "VS"
ThisWorkbook.Sheets("Contratos_Irregulares").Range("D2") = _
ThisWorkbook.Sheets("Capa").Range("a5")
'ThisWorkbook.Sheets("Contratos_Regulares").Range("D2") = _
ThisWorkbook.Sheets("Capa").Range("a5")
ThisWorkbook.Sheets("Parcelas").Range("D2") = _
ThisWorkbook.Sheets("Capa").Range("a5")
' Para a realização de uma busca numa base de dados SQL aplicam-se comandos. Para a busca
que queremos define-se esse comando, armazenado na variável chamada de “SQL” para o
código do VBA.
' Para facilitar a leitura do código, foram omitidos das linhas de comando SQL os símbolos de
“&” que representam a ligação entre dois textos no VBA. Entretanto essa ligação é essencial
para que a busca no SQL funcione, visto que a linha de comando deve ser um texto único.
SQL = _
"
/* colunas do banco de dados que se deseja buscar */
SELECT
CENTRO, CONTRATO, NUM_SEQ_CONTRATO, SUBPRODUTO, DT_INIC_OPER,
DT_FIM_OPER, TX_CUSTO_OPERACAO/100, TX_JUROS_ANO/100,
VL_SLD_DEV_DT_REF, VALOR_ORIGINAL, CD_TIP_AMORT_OPER,
CONVENCAO_DIAS, DESCRICAO, FUNDING_LCA, SEGMENTO
/*endereço de armazenamento dos dados no servidor.*/
FROM
... /*Omitido por questão de confidencialidade*/
/*restrições da busca no banco de dados*/
WHERE
110
AND DT_INIC_OPER >= Data1 /* definição de data de início mínima do contrato */
and DT_INIC_OPER < Data2 /* definição de data de início máxima do contrato */
and SUBPRODUTO <> 1020 /* produto não analisado pela definição do escopo*/
and SUBPRODUTO <> 1021 /* produto não analisado pela definição do escopo*/
and subproduto <> 1013 /* produto não analisado pela definição do escopo*/
and (CD_INDEX_OPER = 'PRE' or CD_INDEX_OPER ='CDI')
"
' fim das linhas de consulta ao SQL
' Abre a conexão
DTB = "Driver=..." 'omitido por questão de confidencialidade.
Set Cnn = New ADODB.Connection
Cnn.Open (DTB)
Cnn.CommandTimeout = 300 ' tempo máximo (em segundos) que a conexão fica aberta, para
não correr risco de travar o servidor.
Set Rst = New ADODB.Recordset
Rst.Open (SQL), Cnn, adOpenForwardOnly, adLockReadOnly
' Coloca os dados da pesquisa nos bancos de dados na aba e células definidas
ThisWorkbook.Sheets("Contratos_Irregulares").Range("C5").CopyFromRecordset Rst
Cnn.Close 'Encerra conexão
Rst.Close
Set Rst = Nothing
Set Cnn = Nothing
End Sub ' Fim da rotina
111
APÊNDICE C – Código para cálculo de operações com fluxo regular
Sub Coloca_valores_HE()
' A primeira ação a ser realizada é a busca nos bancos de dados das operações da base HE que
serão analisadas. Isso é feito chamando a função Baixa_HE, equivalente à função Baixa_VS
mostrada anteriormente.
Call Baixa_HE
' Define o número de contratos a serem checados
fim_contratos_reg =
Application.WorksheetFunction.Count(ThisWorkbook.Sheets("Contratos_Regulares").Range
("g5:g500000"))
' Esse é o cálculo do número de parcelas dos contratos com fluxo de pagamento regular.
Corresponde à etapa 1 das 6 listadas anteriormente.
For i = 1 To fim_contratos_reg
pmt_reg = 12 * (Year(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4)) -
Year(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3) +
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 5))) +
Month(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4)) -
Month(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3) +
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 5)) + 1
' Conserto das operações com menos de um mês, dando a elas uma iteração.
If pmt_reg = 0 Then pmt_reg = 1 End If
' Cálculo da TTI do contrato analisado no momento, chamando a função calctec_360 ou
calctec_360_expandido caso o contrato possua mais de 120 parcelas. Essa escolha foi feita
para aumentar a velocidade do sistema, uma vez que a velocidade era um dos requisitos não-
funcionais definidos na análise de requisitos. Observou-se que a maioria dos contratos possuía
112
até 120 parcelas e que definir um vetor que pudesse calcular contratos com mais 120 parcelas
fariz com que o sistema perdesse desempenho. Assim, criou-se uma função,
calctec_360_expandido, para esse caso em especial.
If pmt_reg > 120 Then
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 9) =
calctec_360_expandido(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3),
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4), pmt_reg)
Else
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 9) =
calctec_360(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3),
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4), pmt_reg)
End If
' Existem três possibilidades para o formato das taxas registradas nos contratos, ou seja, taxa
prefixada, taxa equivalente a um percentual da taxa DI registrada a cada dia (conhecida como
%CDI) e um misto das duas anteriores, ou seja, taxa equivalente a cem por cento da taxa DI
mais uma taxa prefixada (conhecida como CDI+). Para comparar a taxa calculada com a
registrada, elas devem estar no mesmo formato. Assim, os comandos abaixo tratam esse
problema, transformando todas as taxas para prefixadas.
' Teste para saber se contrato está registrado em CDI+.
If ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 6) < 0.03 Then
If pmt_reg <= 120 Then
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 10) = (1 +
pre_oper_360(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3),
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4), pmt_reg)) * (1 +
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 6)) - 1
Else
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 10) = (1 +
pre_oper_360_expandido(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3),
113
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4), pmt_reg)) * (1 +
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 6)) - 1
End If
Else
' Teste para saber se contrato está registrado em %CDI.
If ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 6) > 0.9 Then
If pmt_reg <= 120 Then
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 10) = ((((1 +
pre_oper_360(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3),
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4), pmt_reg)) ^ (1 / 360) - 1) *
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 6) + 1) ^ 360) - 1
Else
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 10) = ((((1 +
pre_oper_360_expandido(ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 3),
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 4), pmt_reg)) ^ (1 / 360) - 1) *
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 6) + 1) ^ 360) - 1
End If
Else
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 10) =
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 6)
End If
End If
' Nessa etapa, realiza-se o cálculo da diferença entre a taxa registrada e a taxa calculada pelo
sistema, comparação feita em taxa prefixada.
114
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 11) =
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 9) -
ThisWorkbook.Sheets("Contratos_Regulares").Cells(i + 4, 10)
End sub
115
APÊNDICE D – Código para cálculo da Taxa de Transferência Interna
' Para entender completamente a função acima descrita, é preciso compreender o cálculo
propriamente dito da TTI feito pelas funções calctec_360 e calctec_360_expandido, que são
chamadas durante a execução da rotina. A diferença entre as duas funções anteriormente
citadas é apenas o tamanho dos vetores que utilizam, portanto, para mostrar seu
funcionamento, basta explicar uma das funções, no caso, a calctec_360, como é feito a seguir:
' Essa função calcula a TTI aproximada de um contrato baseada na data de início do contrato
(ini), data de vencimento do contrato (fim) e número de parcelas (pmt).
Public Function calctec_360 (ini As Date, fim As Date, pmt As Integer)
Dim Pre(121) As Double ' Vetor que armazena a taxa pré de cada parcela
Dim tec(121) As Double '
Dim dc(121) As Integer '
Dim y As Integer ' variável auxiliar para encontrar a TTI definida pelo banco na em
percentual da taxa DI no momento de início do contrato.
y = Application.Match(CLng(ini), ThisWorkbook.Sheets("Hist Tec").Range("C38:AB38"), 1)
For i = 1 To pmt
' Essa etapa calcula o número de dias corridos da parcela e o coloca no vetor designado para
armazenar essa informação. Corresponde à etapa 2 das 6 listadas anteriormente.
dc(i - 1) = Application.WorksheetFunction.EDate(fim, -(pmt - i)) - ini
116
' Realização da busca da curva Pré no histórico de curvas Pré. Corresponde à etapa 3 das 6
listadas anteriormente.
Pre(i - 1) = Interpola( _
dc(i - 1), _
ThisWorkbook.Sheets("Hist Pre").Range("G" &
Application.WorksheetFunction.Match(CLng(ini), ThisWorkbook.Sheets("Hist
Pre").Range("A1:A15111"), 0) & ":G" & Application.WorksheetFunction.Match(CLng(ini),
ThisWorkbook.Sheets("Hist Pre").Range("A1:A15111"), 0) +
Application.WorksheetFunction.CountIf(ThisWorkbook.Sheets("Hist
Pre").Range("A1:A15111"), ini) - 1), _
ThisWorkbook.Sheets("Hist Pre").Range("F" &
Application.WorksheetFunction.Match(CLng(ini), ThisWorkbook.Sheets("Hist
Pre").Range("A1:A15111"), 0) & ":F" & Application.WorksheetFunction.Match(CLng(ini),
ThisWorkbook.Sheets("Hist Pre").Range("A1:A15111"), 0) +
Application.WorksheetFunction.CountIf(ThisWorkbook.Sheets("Hist
Pre").Range("A1:A15111"), ini) - 1))
' Essa função calcula a TTI de uma das parcelas do contrato, a partir da curva Pré do período e
taxa de geração de ativos definida pelo banco em percentual da taxa DI. Corresponde à etapa
4 das 6 listadas anteriormente.
tec(i - 1) = ((((1 + Pre(i - 1)) ^ (1 / 360) - 1) * _
(Interpola(dc(i - 1), ThisWorkbook.Sheets("Hist Tec").Range("A39:A45"),
ThisWorkbook.Sheets("Hist Tec").Range("b39:b45").Offset(0, y))) + 1) ^ 360) - 1
' Realização do cáculo do valor presente da parcela. Corresponde à etapa 5 das 6 listadas
anteriormente.
Pre(i - 1) = 1 / ((1 + Pre(i - 1)) ^ (dc(i - 1) / 360))
Next
117
' Essa etapa realiza o cálculo aproximado da TTI do contrato. Corresponde à etapa 6 das 6
listadas anteriormente.
calctec_360 = Application.SumProduct(Pre, tec, dc) / Application.SumProduct(Pre, dc)
End Function
118
APÊNDICE E – Código específico para o cálculo de fluxos irregulares
For i = 1 To pmts
'O vetor dt_fluxo, que armazena a data de pagamento da parcela, recebe essa data, que havia
sido buscada por outra função na base de dados do banco.
dt_fluxo (i - 1) = ThisWorkbook.Sheets("Parcelas").Range("p4").Offset(x + i - 1, 0)
'O vetor vl_fluxo, que armazena o valor do pagamento da parcela, recebe esse valor, que
havia sido buscada por outra função na base de dados do banco.
vl_fluxo (i - 1) = ThisWorkbook.Sheets("Parcelas").Range("p4").Offset(x + i - 1, 1)
'O vetor vl_fluxo, que armazena o valor do pagamento da parcela, é trazido a valor presente
até a data de início do contrato, pela curva Pré que havia sido armazenada, exatamente como
no caso do fluxo regular.
vl_fluxo (i - 1) = (vl_fluxo(i - 1)) / ((1 + Pre(i - 1)) ^ ((dt_fluxo(i - 1) - dt_ini) / 360))
Next
