Principais lições deste artigo
-
MCP funciona como uma camada de interface de agente que toma decisões em tempo de execução e altera o perfil de risco regulatório em relação a uma API tradicional.
-
Arquitetura segura exige camadas distintas, com MCP gateway, policy engine, taxonomia de tools e logs imutáveis para garantir controle e auditabilidade.
-
Tools de escrita, como Pix e emissão de cartão, demandam step-up authentication, consentimento granular e confirmação humana. Tools de leitura podem operar com maior nível de automação.
-
O Banco Central exige classificação de riscos tecnológicos e adaptação de contratos de BaaS até 31 de dezembro de 2026, mantendo a responsabilidade regulatória com a instituição licenciada.
-
A Celcoin oferece infraestrutura full stack para BaaS e Open Finance com compliance integrado. Esse modelo permite que fintechs, bancos digitais e ERPs exponham serviços financeiros via MCP com segurança regulatória.
Veja como a Celcoin estrutura a camada de execução regulada para arquiteturas MCP.
O problema: MCP como camada de interface de agente
Uma API tradicional executa o que o desenvolvedor programou. Um agente conectado via MCP decide, em tempo de execução, qual ferramenta chamar, com quais parâmetros e em qual sequência. Essa dinâmica muda o perfil de risco. Quando um agente invoca initiate_pix, um modelo de linguagem tomou a decisão com base na descrição da ferramenta e no contexto, e não um humano ou um fluxo totalmente determinístico.
O BaaS é o modelo em que empresas não reguladas operam serviços financeiros sob a licença de um parceiro regulado. Nesse arranjo, a responsabilidade regulatória permanece com a instituição licenciada, independentemente de quem ou do que iniciou a transação. Quando o MCP entra no BaaS, o agente passa a ser mais um ator no caminho de execução. Os frameworks regulatórios brasileiros consideram esse ator no desenho de responsabilidades e auditoria.
Tratar MCP como camada de integração comum aumenta a exposição regulatória. A camada de interface de agente exige um policy engine próprio, autorização baseada em consentimento e execução regulada.
Veja como a Celcoin estrutura a camada de execução regulada para arquiteturas MCP.
A solução em camadas: onde o risco realmente mora
Uma arquitetura segura para MCP em financial services organiza o fluxo em camadas distintas, com responsabilidade clara em cada ponto:
-
Agente: modelo de linguagem que raciocina e decide qual ferramenta invocar.
-
MCP gateway: camada intermediária que intercepta, valida e roteia cada chamada antes que ela atinja o destino. Centraliza autenticação, rate limiting e mascaramento de dados. Sem esse ponto de inspeção, não existe trilha unificada que relacione a decisão do modelo à execução da ferramenta.
-
Policy engine: componente que decide, por chamada, se aquele agente, atuando como aquele usuário, pode invocar aquela ferramenta com aqueles parâmetros. Esse componente concentra a lógica de autorização mais sensível da arquitetura.
-
Tools financeiras: funções tipadas expostas pelo servidor MCP, com semânticas distintas por nível de risco.
-
BaaS / Open Finance: camada de acesso a dados e execução de operações, sujeita ao modelo regulatório do Banco Central.
-
Instituição regulada: detentora da licença e responsável final perante o regulador.
O MCP funciona como camada de interface de agente, com responsabilidades que vão além da integração. O MCP padroniza a interação, mas não padroniza o controle. Em serviços financeiros, o controle é o foco principal das auditorias regulatórias.
Taxonomia de tools MCP: leitura, análise e escrita
A taxonomia de tools ajuda a dimensionar o risco de cada operação. Uma classificação prática organiza as ferramentas em três grupos, com implicações de segurança específicas:
-
Tools de leitura: funções como
get_balanceelist_transactionsconsultam dados sem alterar estado. Podem operar com maior nível de automação, desde que o consentimento do usuário cubra o acesso e que o gateway aplique mascaramento de PII antes de incluir os dados no contexto do modelo. -
Tools de análise: funções que agregam, categorizam ou pontuam dados para apoiar decisões, como avaliação de capacidade de pagamento ou detecção de anomalias. O risco é indireto. A saída alimenta uma decisão que pode ter efeito jurídico, o que aciona o Art. 20 da LGPD, que garante ao titular o direito de solicitar revisão humana de decisões automatizadas que produzam efeitos legais ou afetem significativamente seus interesses.
-
Tools de escrita: funções como
initiate_pixouissue_virtual_cardalteram estado, movem dinheiro e tocam sistemas de produção. Exigem autorização reforçada, step-up authentication e confirmação humana em operações sensíveis. As tools são a primitiva de maior risco no MCP porque mutam estado, gastam dinheiro e tocam sistemas de produção.
Usar MCP para expor tools não significa transformar um LLM em API bancária irrestrita. A taxonomia de tools torna o princípio do menor privilégio auditável. O agente enxerga apenas as ferramentas compatíveis com seu papel, e tools de escrita não aparecem no contexto de agentes sem permissão explícita.
MCP e Open Finance: consentimento, step-up authentication, idempotência e logs imutáveis
No modelo regulatório brasileiro, qualquer compartilhamento de dados financeiros exige consentimento prévio, livre, informado e inequívoco do titular. A finalidade deve ser declarada, conforme o Art. 13 da Resolução Conjunta nº 1/2020. Em um servidor MCP para serviços financeiros, cada chamada de tool que acessa ou transmite dados precisa ser rastreável até o consentimento específico que a autorizou. A revogação desse consentimento deve interromper o acesso de forma imediata.
Quatro requisitos técnicos estruturam essa arquitetura:
-
Consentimento granular: o escopo do consentimento deve cobrir o acesso aos dados, o processamento autônomo e a tomada de decisão aplicada a esses dados pelo agente.
-
Step-up authentication: operações de maior risco, como transferências acima de determinado valor ou emissão de cartão, exigem fator de autenticação adicional antes da execução. O padrão segue o NIST SP 800-63B e os parâmetros
acr_valuesemax_agedo OpenID Connect, que permitem exigir uma Authentication Context Class Reference específica antes da operação privilegiada. -
Idempotência: tools de escrita devem garantir que a mesma chamada executada mais de uma vez produza o mesmo resultado, sem efeito colateral adicional. Esse requisito é crítico em ambientes em que o agente pode retentar uma operação após falha de rede.
-
Logs imutáveis: 100% das chamadas devem ser registradas, com retenção mínima de 5 anos. Essa trilha permite reconstruir quem acessou o quê e quando, para responder a auditorias e solicitações regulatórias.
Esses requisitos são obrigatórios. Eles definem se a integração será aceita ou questionada pelo regulador.
O que o Banco Central exige de integrações BaaS com IA
O Banco Central do Brasil ainda não publicou resolução específica sobre MCP, mas o framework regulatório atual já cria obrigações para integrações de IA em BaaS. A Resolução CMN 4.893 exige que instituições supervisionadas classifiquem seus riscos tecnológicos e tratem um agente de IA em fluxo crítico como provedor de tecnologia terceirizado. A responsabilidade regulatória permanece com a entidade supervisionada.
O Banco Central estabeleceu 31 de dezembro de 2026 como data-limite para adaptação de contratos de BaaS às novas exigências regulatórias. Arquiteturas que expõem serviços financeiros via MCP precisam estar em conformidade antes dessa data, com contratos que descrevam as responsabilidades entre provedor regulado e parceiro de BaaS, incluindo fluxos automatizados por agentes.
Um exemplo ajuda a visualizar como essas exigências se aplicam na prática. O Banco MCP, conectado ao Open Finance Brasil, expõe dados de saldo, transações, faturas e investimentos para agentes de IA sem endpoint de transferência, Pix ou pagamento. Uma de suas ferramentas, openfinance_force_sync, é classificada como “write” por solicitar sincronização ao agregador, sem movimentar dinheiro. Essa escolha reduz o perfil de risco regulatório, mas mantém as obrigações de consentimento e auditoria. Para empresas que precisam ir além da leitura de dados e executar operações reguladas, a Celcoin cobre execução regulada, incluindo Pix, transferências, emissão de cartão e cadeia de liquidação, com compliance integrado desde a camada de infraestrutura.
Casos de uso concretos: o que automatizar e o que exige confirmação humana
A taxonomia de tools orienta o que pode ser automatizado com segurança e o que exige intervenção humana:
-
Consulta de saldo e extrato (
get_balance,list_transactions): tools de leitura que podem operar de forma automatizada com consentimento ativo e mascaramento de PII no gateway. Um caso típico é o copiloto financeiro que responde perguntas sobre fluxo de caixa em linguagem natural. -
Conciliação e detecção de anomalias: tools de análise que agregam dados de múltiplas contas e identificam cobranças duplicadas ou despesas fora do padrão. O resultado apoia uma decisão humana. O agente não executa ações autônomas com base no que encontra.
-
Emissão de cartão virtual (
issue_virtual_card): tool de escrita que exige step-up authentication, confirmação explícita do usuário e log imutável da operação. Operações como deletar registro, enviar comunicação externa e mover dinheiro exigem revisão humana obrigatória. -
Iniciação de Pix (
initiate_pix): tool de escrita de maior risco. Requer autorização reforçada, idempotência garantida e trilha de auditoria completa. Confirmação humana é obrigatória para valores acima dos limites definidos pela política da instituição.
A regra prática é direta. Quanto mais irreversível a ação, mais camadas de autorização são necessárias antes da execução.
Como a Celcoin se posiciona nessa arquitetura
Implementar essa arquitetura em camadas exige infraestrutura que já incorpore controles regulatórios. A Celcoin opera com portfólio completo de licenças e tecnologia proprietária, oferecendo APIs modulares para banking, pagamentos e crédito. Fintechs, bancos digitais, ERPs e grandes varejistas podem iniciar no modelo BaaS, usando a licença da Celcoin, e migrar para o Core Banking com licença própria, mantendo a mesma base tecnológica, segurança e suporte.
Em arquiteturas MCP para serviços financeiros, a Celcoin cobre a camada de execução regulada, com contas digitais, cartões, Pix, TED e liquidação, e também as obrigações de compliance exigidas pelo regulador, como CCS, CADOCs, COSIF, DIMP e BacenJud, com conexão direta à RSFN e ao SPB. A infraestrutura de Open Finance da Celcoin permite acesso e transmissão de dados financeiros com consentimento do usuário, dentro do modelo regulatório do Banco Central. Essa base viabiliza servidores MCP que precisam operar em conformidade com as regras brasileiras.
A Celcoin media mais de R$ 30 bilhões em transações mensalmente e atende mais de 6 mil clientes. A Celcoin não oferece empréstimo direto para consumidores. A Celcoin fornece infraestrutura tecnológica para que empresas ofertem produtos de crédito aos seus clientes. Na prática, essa infraestrutura se traduz em capacidades que sustentam a arquitetura MCP descrita acima, da modularidade das APIs ao compliance integrado, como resume a tabela a seguir.
Tabela: capacidades da infraestrutura Celcoin que sustentam arquiteturas MCP reguladas
|
Funcionalidade da Celcoin |
Benefício para sua empresa |
|
APIs modulares |
Integrações mais rápidas, com redução de custos e prazos de desenvolvimento. |
|
Experiência e suporte ao desenvolvedor |
Documentação, SDKs e sandboxes que reduzem ciclos de integração e custos de engenharia. |
|
Capacidade de lançamento rápido |
Módulos pré-construídos e entrega via SaaS aceleram lançamentos e melhoram o tempo para geração de receita. |
|
Distribuição white-label e embutida (embedded) |
Suporte a produtos financeiros com marca própria. |
|
Escalabilidade com confiabilidade |
Ter alta disponibilidade e escalabilidade em nuvem mantém serviços funcionando em altos volumes e protege a receita. |
|
Cobertura de diversas possibilidades de pagamentos, incluindo crédito |
Oferecer pagamentos e emissão de crédito aumenta conversão, ARPU e fidelização. |
|
Acesso a dados e personalização |
Dados e análises via Open Finance permitem ofertas personalizadas e melhoram conversão e retenção. |
|
Compliance e conformidade como princípio |
KYC, AML e relatórios integrados reduzem risco regulatório e aceleram ciclos de vendas. |
|
Prevenção de fraude e controles de risco |
Monitoramento baseado em IA e autenticação robusta reduzem estornos, perdas e exposição regulatória. |
|
Força do ecossistema de parceiros da Celcoin |
Parcerias e integrações com bancos, redes e fintechs ampliam cobertura, recursos e velocidade de entrada no mercado. |
Conheça as APIs e o compliance integrado da Celcoin para BaaS e Open Finance.
Perguntas frequentes
O que é um servidor MCP financeiro?
Um servidor MCP financeiro é um componente de infraestrutura que expõe capacidades de serviços financeiros, como consulta de saldo, listagem de transações e iniciação de pagamentos, para agentes de IA por meio do Model Context Protocol. Ele organiza essas capacidades em três primitivas: tools (ações executáveis), resources (dados somente leitura) e prompts (templates reutilizáveis). Em um contexto regulado como o brasileiro, o servidor MCP financeiro precisa operar junto com um MCP gateway que tenha policy engine, controle de consentimento e logs imutáveis. Sem esses componentes, o servidor expõe a instituição a risco regulatório, mesmo quando as ferramentas individuais parecem inofensivas.
Como funciona o MCP no BaaS?
No BaaS, já descrito neste artigo, uma empresa não regulada opera serviços financeiros sob a licença de um parceiro regulado. Quando o MCP entra nesse arranjo, ele substitui integrações ponto a ponto por uma interface padronizada que agentes de IA usam para descobrir e invocar ferramentas financeiras. O fluxo típico é o agente consultar o servidor MCP via tools/list para descobrir o que está disponível e depois invocar uma ferramenta específica via tools/call. O MCP gateway intercepta cada chamada, valida a identidade do agente, verifica o consentimento do usuário, aplica a política de autorização e registra a operação antes de encaminhar a requisição ao BaaS. Como já mencionado, a responsabilidade permanece com a instituição licenciada, independentemente de a ação ter sido iniciada por humano ou agente.
MCP pode movimentar dinheiro com segurança?
MCP pode movimentar dinheiro com segurança quando a arquitetura inclui os controles corretos. Tools de escrita como initiate_pix podem ser expostas via MCP, desde que exista consentimento do usuário que cubra explicitamente a execução autônoma, step-up authentication antes da operação, idempotência para evitar execuções duplicadas em caso de retry, confirmação humana para operações acima dos limites definidos pela política da instituição e log imutável de toda a cadeia de autorização. Sem esses controles, expor tools de escrita via MCP transforma o agente em vetor de risco regulatório e operacional. A segurança fica concentrada na camada de policy engine e autorização que atua entre o agente e a execução.
Qual a diferença entre ferramentas MCP de leitura e escrita?
Tools de leitura, como get_balance e list_transactions, consultam dados sem alterar estado. Podem operar com maior nível de automação, mas ainda exigem consentimento ativo e mascaramento de PII antes de os dados entrarem no contexto do modelo. Tools de escrita, como initiate_pix e issue_virtual_card, alteram estado, movem recursos e produzem efeitos jurídicos. Exigem autorização reforçada, step-up authentication, idempotência e confirmação humana em operações sensíveis. Entre essas duas categorias existem as tools de análise, que agregam dados para apoiar decisões. O risco é indireto, mas aciona o direito de revisão humana previsto no Art. 20 da LGPD quando a saída afeta de forma relevante os interesses do titular.
O que o Banco Central exige de integrações BaaS com IA?
O Banco Central ainda não publicou resolução específica sobre MCP ou agentes de IA, mas o framework regulatório atual já define obrigações. A Resolução CMN 4.893 exige classificação de riscos tecnológicos e trata agentes de IA em fluxos críticos como provedores de tecnologia terceirizados, mantendo a responsabilidade com a instituição supervisionada. O Open Finance Brasil exige consentimento granular, rastreável e revogável em tempo real para qualquer compartilhamento de dados. A LGPD exige que decisões automatizadas com efeito jurídico sejam explicáveis e sujeitas a revisão humana sob solicitação. Como mencionado, o prazo de 31 de dezembro de 2026 exige que arquiteturas MCP estejam em conformidade antes dessa data.
Conclusão: MCP exige policy engine, autorização e conformidade
MCP aplicado a financial services e BaaS é, acima de tudo, uma questão de arquitetura regulatória. O protocolo padroniza como agentes se conectam a ferramentas, mas não define quem pode chamar o quê, sob qual consentimento, com quais restrições e com qual trilha de auditoria. Esses pontos pertencem ao policy engine. Ignorar essa camada aumenta o risco de transformar ganhos de eficiência em exposição regulatória.
A arquitetura correta organiza o fluxo em camadas com responsabilidades claras. MCP gateway atua como ponto único de inspeção. O policy engine recalcula a autorização a cada chamada. A taxonomia de tools aplica o princípio do menor privilégio. O consentimento é rastreável via Open Finance. Operações sensíveis passam por step-up authentication. Tools de escrita operam com idempotência garantida. Logs imutáveis mantêm retenção adequada. Cada componente corresponde a um requisito regulatório, e todos são necessários.
A Celcoin oferece infraestrutura full stack que cobre essa jornada, da execução regulada ao compliance contínuo, do BaaS ao Core Banking, do Pix à liquidação, com conexão direta à RSFN e ao SPB e com obrigações regulatórias integradas desde a camada de infraestrutura.
Conheça a infraestrutura da Celcoin para MCP em serviços financeiros.
