Critérios de TMS: APIs bancárias e multi-banco

Resumo: Avaliar um TMS (Treasury Management System, sistema de gestão de tesouraria) em open finance, APIs bancárias e multi-banco passa por cobertura de bancos, latência dos dados, tipos de operação suportados, normalização entre instituições e governança de acesso. Constar "integração bancária" numa lista de funcionalidades diz pouco sobre como ela funciona na prática.

Em propostas comerciais, a palavra conectividade aparece quase sempre. O que muda de um sistema para outro é o que existe por trás dela: arquivos em lote, APIs proprietárias de cada banco, Open Finance ou combinações entre eles.

Este artigo desmonta cinco crenças comuns na hora de comparar plataformas. Cada uma traz o fato que a contradiz e a razão pela qual ela persiste.

Os números de exemplo são ilustrativos e não representam nenhuma empresa ou banco específico.

Por que a conectividade pesa tanto na avaliação de um TMS?

Porque todo o resto da tesouraria depende dela. Posição de caixa, previsão, conciliação e pagamentos só são tão atuais quanto os dados que chegam dos bancos.

Um TMS com análises sofisticadas, mas alimentado por extratos do dia anterior, entrega uma fotografia velha. Por isso os profissionais de tesouraria costumam separar a avaliação em duas camadas: o que o sistema faz com os dados e como os dados chegam até ele.

Quais mitos mais aparecem ao comparar open finance, APIs e multi-banco?

Mito 1: "Open Finance resolve a conectividade de toda a tesouraria"

Não resolve sozinho. O Open Finance Brasil é um ecossistema regulado pelo Banco Central, com base na Resolução Conjunta nº 1/2020 (BCB e CMN), que padroniza o compartilhamento de dados e a iniciação de pagamentos mediante consentimento do cliente. A cobertura depende das instituições participantes e das categorias de dados e serviços que cada uma disponibiliza.

Além disso, o consentimento tem prazo de validade e é renovado periodicamente. Operações específicas de tesouraria, como certos tipos de cobrança ou pagamentos em lote, podem ser atendidas por APIs próprias do banco, fora do escopo padronizado.

O mito persiste porque o Open Finance é a face mais visível do tema. A conversa pública se concentra nele, e as APIs diretas dos bancos recebem menos atenção.

Mito 2: "Ter API é ter dado em tempo real"

API é apenas a forma de comunicação. A atualização depende de como ela é consumida e do que o banco expõe. Há bancos com saldo e extrato intradia, e outros em que o extrato só fecha no dia seguinte.

Variáveis técnicas que costumam entrar na comparação:

• latência entre o lançamento no banco e a chegada ao sistema;
• uso de consulta periódica (polling) ou de notificação por evento (webhook);
• limites de requisições por período impostos pelo banco;
• endpoints disponíveis: saldo, extrato, investimentos, pagamentos, cobrança;
• comportamento em caso de indisponibilidade da API.

A crença persiste porque "API" soa como sinônimo de instantâneo. Na prática, duas integrações por API podem ter frescor de dados bem diferente.

Mito 3: "CNAB e VAN já bastam, o resto é modismo"

CNAB é o padrão de arquivos de remessa e retorno da Febraban, e VAN é a rede de valor agregado que transporta esses arquivos. Ambos funcionam e seguem em uso em muitas empresas. A questão é o modelo: processamento em lote, retorno assíncrono e, em geral, visibilidade do saldo atrasada.

Há plataformas que consolidam saldos, extratos e investimentos por conectividade bancária via API e Open Finance, sem CNAB nem VAN. Outras mantêm os arquivos como camada principal e adicionam APIs onde existem. Na avaliação, o que costuma ser observado é qual é o caminho principal e qual é o de contingência.

O mito persiste porque a migração tem custo de homologação por banco, e o que já funciona raramente é questionado.

Mito 4: "Multi-banco significa ter muitos logotipos na lista"

A lista de bancos informa a cobertura, não a qualidade da consolidação. O trabalho difícil é normalizar dados: cada banco descreve lançamentos, tarifas e saldos de um jeito. Sem padronização, a posição consolidada exige ajustes manuais.

Para ilustrar, suponha 6 bancos e 10 CNPJs. São até 60 combinações banco-CNPJ, cada uma com credenciais, consentimentos e permissões próprios. O que o sistema faz com essa combinatória aparece em critérios como:

• visão por conta, banco, moeda e CNPJ;
• limites de caixa mínimo e máximo por conta;
• transferências entre bancos e entre CNPJs do mesmo grupo;
• catálogo padronizado de tarifas para comparar bancos.

Um ponto técnico recorrente é o cash pooling, a centralização de saldos de várias contas em uma conta principal. O modelo oferecido por um banco costuma operar apenas entre contas daquela instituição, e esse é um limite daquele formato. Existem plataformas que executam as transferências entre bancos e CNPJs diferentes a partir de regras de caixa mínimo e máximo, com fluxo de aprovação.

O mito persiste porque "quantos bancos" é a pergunta mais fácil de fazer e de responder.

Mito 5: "Segurança e governança são assunto só de TI"

Num TMS conectado a bancos, a governança de acesso faz parte do desenho financeiro. O Open Finance Brasil adota perfis de segurança baseados no padrão FAPI e autenticação mútua entre as partes, e o tratamento de dados pessoais segue a LGPD (Lei 13.709/2018).

No plano do usuário, entram critérios como:

• perfis de acesso separados por empresa, banco e função;
• fluxos de aprovação para transferências e pagamentos;
• trilha de auditoria de quem fez o quê e quando;
• política de armazenamento das credenciais e dos tokens de consentimento.

O mito persiste porque essas camadas são invisíveis numa demonstração. Quando tudo funciona, ninguém as vê.

O que de fato importa na comparação?

Os cinco mitos têm algo em comum: tratam um rótulo (Open Finance, API, multi-banco) como se fosse um resultado. O que diferencia as plataformas está nos detalhes operacionais de cada rótulo.

Perguntas que organizam a avaliação

• Qual caminho de dados vale para cada banco: Open Finance, API direta ou arquivo?
• Qual a atualização efetiva de saldo e extrato, por banco?
• Quais operações são suportadas além da consulta?
• Como os dados de bancos diferentes são normalizados?
• Como funcionam permissões, aprovações e auditoria?
• Como o sistema se comporta quando um banco fica indisponível?

Com essas respostas, a comparação entre plataformas deixa de ser uma lista de funcionalidades e passa a ser uma comparação de arquitetura, que é o que afeta o dia a dia do caixa. A gestão de caixa consolidada depende desse alicerce.

A Datanomik conecta os bancos da empresa por API e Open Finance e consolida a posição de caixa ao longo do dia.

Perguntas frequentes

Open Finance substitui as APIs diretas dos bancos num TMS?

Não necessariamente. O Open Finance padroniza dados e iniciação de pagamentos entre instituições participantes, enquanto as APIs diretas podem cobrir operações e produtos que ficam fora desse escopo. Muitos sistemas combinam as duas vias.

O que é polling e webhook em integrações bancárias?

Polling é quando o sistema consulta o banco em intervalos regulares para saber se há novidades. Webhook é quando o banco avisa o sistema assim que um evento ocorre. O segundo tende a reduzir a latência, mas depende de o banco oferecer esse recurso.

Por que a normalização de dados importa em ambientes multi-banco?

Porque cada banco descreve lançamentos, categorias e tarifas de forma própria. Sem um padrão comum, a consolidação por conta, CNPJ ou moeda exige tratamento manual, o que atrasa a posição de caixa e abre espaço para divergências.

Um TMS precisa de CNAB para operar com vários bancos?

Depende do modelo da plataforma. Alguns sistemas usam CNAB e VAN como camada principal, e outros operam por APIs e Open Finance, sem esses arquivos. A diferença aparece na latência e no esforço de homologação por banco.