Principais lições deste artigo
- O MCP atua como camada de descoberta e invocação padronizada para agentes de IA sobre as APIs do Core Banking.
- Um gateway MCP é obrigatório em ambiente regulado para aplicar autorização por chamada, idempotência e trilha de auditoria atribuível.
- Tools de leitura e escrita exigem controles distintos. As de escrita demandam idempotency key e, em operações de alto impacto, aprovação humana.
- A conformidade com o Banco Central (Resoluções CMN nº 4.893/2021, 5.274/2025, BCB nº 538/2025 e Resolução Conjunta nº 18/2025) precisa entrar no desenho da arquitetura MCP desde o início.
- O banking da Celcoin oferece, por meio do cel_agents, uma plataforma AI First que integra MCP às APIs modulares de banking e Open Finance.
Conheça a solução MCP da Celcoin
O que é MCP em banking: desambiguação entre MCP, API e middleware
O Model Context Protocol é um protocolo aberto baseado em JSON-RPC 2.0, publicado pela Anthropic em novembro de 2024 sob licença MIT. A inicialização ocorre por um handshake único. O cliente envia uma requisição initialize com versão de protocolo e capacidades. O servidor responde com a versão que suporta. Após a notificação notifications/initialized, a conexão permanece aberta para tráfego normal.
Os transportes disponíveis são stdio, usado em hosts desktop locais, e Streamable HTTP, com endpoint POST único, recomendado para servidores remotos, com latência de 5–30 ms em LAN e 30–150 ms em WAN. As primitivas de servidor são três. Tools são funções invocadas pelo modelo com entradas e saídas tipadas por JSON Schema. Resources são conteúdos endereçáveis e somente leitura. Prompts são modelos parametrizados acionados pelo usuário.
O MCP cria uma camada de interação sobre as APIs do Core Banking. A diferença em relação a outros padrões de integração é funcional. Uma API foi construída para que um software converse com outro software de forma determinística, em que o chamador conhece o endpoint, o schema e o contrato. O MCP organiza dados e funções para que um agente entenda o que está disponível e escolha como usar cada recurso. O agente descobre as capacidades em runtime via tools/list e decide autonomamente qual tool invocar.
O middleware bancário tradicional roteia e transforma mensagens entre sistemas. Ele converte formatos, aplica regras de negócio e encaminha para câmaras de compensação. Esse middleware não organiza funções para descoberta por agente nem expõe um catálogo de operações. Em integrações entre sistemas legados e câmaras, o middleware continua adequado. O MCP agrega valor quando o consumidor é um agente de IA que precisa descobrir capacidades, entender o que cada operação faz e escolher como usá-la.
Arquitetura de gateway MCP para Core Banking
A arquitetura de referência para MCP em Core Banking opera em três camadas: agente de IA, gateway MCP e Core Banking. O gateway funciona como ponto único de controle em ambiente regulado.
O fluxo de uma chamada segue seis etapas:
- O agente descobre as tools disponíveis via
tools/liste recebe nome, descrição e JSON Schema de cada operação exposta pelo gateway. - O gateway valida o token OAuth2/OIDC da requisição, verifica escopos e aplica a política de autorização por chamada, e não por sessão.
- A chamada é registrada com identidade do chamador, nome da tool, hash dos argumentos e latência, formando a trilha de auditoria.
- Operações de escrita exigem idempotency key e, conforme o impacto, aprovação humana no circuito, seguindo o padrão maker-checker.
- O gateway traduz a chamada MCP para a API correspondente do Core Banking e aplica os controles de menor privilégio definidos por papel.
- O resultado retorna ao agente com a trilha de auditoria associada. Erros são registrados com o mesmo nível de detalhe que os sucessos.
Quando a autenticação está correta mas a autorização não é aplicada por chamada, cada cliente autenticado passa a ter privilégios excessivos. Em ambiente regulado, isso configura falha de conformidade. O gateway resolve esse problema ao avaliar permissões continuamente, e não apenas na abertura da sessão.
Veja como estruturar seu gateway MCP com a Celcoin
Quais tools um servidor MCP de Core Banking deve expor
A taxonomia de tools de um servidor MCP de Core Banking se divide em duas categorias, com regras distintas de autorização, idempotência e aprovação humana.
Tools de leitura operam com escopo restrito e rate limit, sem exigir idempotency key ou aprovação humana:
customer.getconsulta dados cadastrais do cliente.account.getconsulta dados da conta.balance.getconsulta saldo em tempo real.transaction.listretorna extrato de transações com filtros.kyc.status.getinforma o status do processo de KYC do cliente.
Tools de escrita exigem idempotency key, autorização com escopo elevado e, em operações de alto impacto, aprovação humana antes da execução:
account.openabre conta digital.payment.createcria ordem de pagamento.transfer.commitconfirma transferência interbancária.card.issueemite cartão.kyc.startinicia o fluxo de onboarding e KYC.
Essa separação permite expor o Core Banking a agentes de IA sem conceder privilégios amplos a cada cliente autenticado. A prática recomendada é evitar a conexão direta de um banco de produção com acesso de leitura e escrita a um agente sem camada de controle intermediária. Tools de escrita sem idempotency key em ambiente de Pix, que opera 24×7 sobre o SPI, podem gerar duplicidade de transações sem mecanismo de reconciliação.
MCP e conformidade com o Banco Central
O MCP cria uma nova superfície de risco regulatório. No Brasil, essa superfície precisa ser mapeada contra a regulação do Banco Central antes de qualquer implantação em produção.
A Resolução CMN nº 4.893/2021 exige autenticação, criptografia, prevenção e detecção de intrusão, mecanismos de rastreabilidade, controles de acesso e segmentação de rede. Um gateway MCP que não registra cada chamada com identidade, tool e argumentos viola o requisito de rastreabilidade dessa norma.
As Resoluções CMN nº 5.274/2025 e BCB nº 538/2025, publicadas em dezembro de 2025, transformaram a política de cibersegurança em requisitos auditáveis, com testes de intrusão anuais, independentes e documentados, e reforço de controles sobre RSFN, Pix e STR. Um servidor MCP conectado ao Core Banking passa a ser um novo ponto de entrada que precisa constar no escopo desses testes.
A Resolução Conjunta nº 18/2025 exige que toda a esteira de transformação dos dados, da origem nos sistemas transacionais até a consolidação em relatórios regulatórios, seja documentada, protegida e auditável, com rastreabilidade de quem transformou os dados ao longo do ciclo. Quando um agente de IA lê dados via MCP e os usa para gerar um relatório ou alimentar um processo de decisão, essa cadeia de transformação precisa ser registrada e atribuída a uma identidade verificável.
A RSFN exige certificados digitais, mensagens assinadas, irrevogáveis e rastreáveis. O Pix opera 24×7 sobre o SPI e exige alta disponibilidade e baixa latência. Em julho de 2026, o Pix processou quase oito bilhões de transações, movimentando R$ 3,8 trilhões. Qualquer camada MCP que introduza latência ou indisponibilidade nesse fluxo cria risco operacional e regulatório.
No Open Finance, a IA que consome ou processa informações de clientes precisa respeitar consentimento, finalidade e segurança previstos nas regras do Open Finance. Essas exigências se somam às da LGPD (Lei nº 13.709/2018). Decisões automatizadas que afetam o titular exigem explicabilidade e possibilidade de revisão humana.
Os reportes regulatórios CCS e CADOC, gerados a partir de dados do Core Banking, precisam ter rastreabilidade de origem. Quando um agente de IA participa da cadeia de transformação desses dados, essa participação precisa ser registrada e vinculada a uma identidade verificada.
A Celcoin não oferece nenhum tipo de empréstimo para consumidores. A Celcoin fornece a infraestrutura tecnológica para que empresas consigam ofertar produtos de crédito aos seus clientes.
Com o mapa regulatório definido, o passo seguinte é posicionar o MCP em relação às APIs e ao middleware já usados no setor.
MCP vs API vs middleware bancário tradicional
MCP, APIs e middleware bancário tradicional atendem necessidades diferentes. A escolha depende do tipo de consumidor e do fluxo de integração.
APIs bancárias foram construídas para integração determinística entre sistemas. O chamador conhece o endpoint, o schema e o contrato antes de fazer a primeira requisição. Esse modelo atende bem sistemas que executam fluxos fixos. Quando o consumidor é um agente de IA que decide em runtime qual operação executar com base no contexto da conversa, a API sozinha não oferece o mecanismo de descoberta necessário.
O MCP atende esse cenário ao expor um catálogo descobrível de tools com descrições semânticas que o modelo lê para decidir o que invocar. Na maioria dos casos, o MCP continua dependendo da API, com mudança apenas na forma de acesso. O gateway MCP traduz a chamada do agente para a API do Core Banking e mantém o backend inalterado.
O middleware bancário tradicional continua adequado para transformação de mensagens entre formatos, como ISO 20022, FEBRABAN e RSFN, roteamento determinístico entre câmaras e integração com sistemas legados que não expõem APIs REST. Esses cenários não se beneficiam de um catálogo descobrível por agentes.
Em Core Banking, a API segue como base para integrações determinísticas. O MCP atua como camada de descoberta e invocação para agentes de IA. O middleware permanece como solução para transformação e roteamento em ambientes legados.
Limitações e riscos de MCP em Core Banking
Latência. O transporte Streamable HTTP adiciona round-trips de rede de 5–30 ms em LAN e 30–150 ms em WAN. Além disso, um servidor MCP com 30 tools e descrições verbosas pode adicionar 4.000–8.000 tokens de entrada por turno do modelo. Em operações de Pix, em que o SPI exige liquidação em segundos, essa latência precisa ser orçada e testada antes da produção.
Superfície de ataque ampliada. O principal risco estrutural é o padrão confused deputy, em que o agente detém credenciais legítimas para sistemas de Core Banking e o atacante não precisa roubá-las, apenas convencer o agente, por meio de dados confiáveis, a usá-las em seu nome. Qualquer servidor MCP conectado pode influenciar o agente. Uma ferramenta de produtividade de baixa confiança pode encadear até o Core Banking por um caminho que nenhum firewall tradicional enxerga.
Dependência de fornecedor. Servidores MCP não governados ou baixados de repositórios públicos, sem assinatura, proveniência ou inventário, criam risco de cadeia de suprimentos. Em ambiente regulado pelo Banco Central, um servidor MCP sem proveniência verificada representa fraqueza material nos controles gerais de TI.
Maturidade da tecnologia. O ecossistema de servidores MCP ainda é imaturo, com qualidade desigual e a maioria sem varredura de segurança. A especificação evolui rapidamente. A revisão de julho de 2026 introduziu mudanças relevantes de autorização. Implementações que não acompanham o ciclo de atualização acumulam débito de segurança.
Riscos de autorização indevida. Servidores MCP que usam chaves de API compartilhadas ou tokens de conta de serviço não conseguem produzir registros de auditoria atribuíveis. Em ambiente regulado, isso configura falha direta de conformidade. Quando vários agentes compartilham um conjunto de credenciais, não é possível vincular uma chamada de tool específica a um usuário, instância de agente ou equipe.
As mitigações para cada risco convergem para o mesmo conjunto de controles. O gateway aplica autorização por chamada e mantém o menor privilégio com listas explícitas de tools permitidas. Operações de escrita exigem idempotência, e as irreversíveis passam por aprovação humana. Por fim, o inventário de servidores aprovados e a auditoria de ponta a ponta garantem que cada registro seja atribuível a uma identidade verificável.
Esse conjunto de controles orienta a forma como a Celcoin estruturou sua oferta de MCP.
Como a Celcoin aplica MCP via cel_agents
O cel_agents, lançado em 24 de agosto de 2026 durante a 36ª edição do Febraban Tech, é a primeira plataforma da Celcoin sob o conceito AI First. A plataforma disponibiliza um ambiente gratuito de testes em até cinco minutos e reduz de meses para poucas horas o tempo entre a decisão de desenvolver um novo serviço financeiro e a criação de uma versão funcional.
A versão inicial conta com cerca de 15 jornadas financeiras, entre elas abertura de contas, Pix, boletos e cobrança, Open Finance e emissão de cartões. A ampliação gradual prevê a incorporação de todo o portfólio do banking da Celcoin.
Por meio do Model Context Protocol, a inteligência artificial acessa o contexto técnico dos produtos da Celcoin e cria uma camada de interação com as APIs. O uso do Studio é opcional. Empresas que já possuem interfaces e padrões próprios de desenvolvimento podem utilizar apenas os recursos de integração assistida por IA e manter sua arquitetura e seus processos.
A Celcoin opera com um portfólio completo de licenças e tecnologia proprietária, com APIs modulares, conectada diretamente à RSFN, ao SPB, ao Pix e ao Open Finance. Com a aquisição da VERT Capital, o ecossistema passou a incluir também o mercado de capitais, com securitização, administração fiduciária e gestão de fundos estruturados. Esse arranjo permite que um cliente de banking evolua para crédito e funding sem trocar de infraestrutura.
A tabela abaixo resume como cada funcionalidade da plataforma se traduz em benefício concreto para a empresa que a adota.
| 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 | Solução com alta disponibilidade e escalável na nuvem mantém serviços funcionando mesmo com altos volumes. |
| Cobertura de diversas possibilidades de pagamentos, incluindo crédito | Oferta de 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, com impacto em 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 e velocidade de entrada no mercado. |
Teste o cel_agents gratuitamente
Perguntas frequentes sobre MCP em Core Banking
O que é MCP em banking?
MCP (Model Context Protocol) é um protocolo aberto baseado em JSON-RPC 2.0 que permite a agentes de IA descobrir e executar operações estruturadas sobre as APIs do Core Banking, sem substituí-las. O agente consulta um catálogo de tools disponíveis em runtime e decide autonomamente qual operação invocar com base no contexto da tarefa. No banking, um agente pode consultar saldo, iniciar um pagamento ou verificar o status de KYC de forma estruturada, desde que exista um gateway com autorização e auditoria no caminho.
Qual a diferença entre MCP e API em Core Banking?
A API foi construída para que um software converse com outro software de forma determinística. O chamador conhece o endpoint, o schema e o contrato antes de fazer a primeira requisição. O MCP organiza dados e funções para que um agente entenda o que está disponível e escolha como usar cada recurso em runtime. Na prática, o gateway MCP traduz a chamada do agente para a API correspondente do Core Banking e mantém o backend inalterado. APIs atendem sistemas com fluxos fixos. O MCP atende agentes de IA com decisão autônoma.
Quais os riscos e desvantagens do MCP?
Como detalhado na seção de limitações, os riscos se concentram em latência adicional, superfície de ataque ampliada, dependência de fornecedor, maturidade da tecnologia e autorização indevida. Todos são mitigáveis com gateway, política de autorização por chamada, idempotência, aprovação humana e auditoria de ponta a ponta.
Como implementar um servidor MCP para Core Banking?
A implementação começa pelo gateway MCP com autenticação OAuth2/OIDC, porque esse componente valida tokens e aplica política de autorização a cada chamada, e não por sessão. Com essa base definida, a etapa seguinte é separar as tools de leitura e de escrita, já que cada categoria exige nível diferente de controle. Tools de leitura operam com escopo restrito e rate limit. Tools de escrita exigem idempotency key e, em operações de alto impacto, aprovação humana no circuito. Como toda chamada precisa ser atribuível, o registro de identidade do chamador, nome da tool, argumentos e latência se torna obrigatório. O gateway traduz a chamada MCP para a API do Core Banking e mantém o backend inalterado. Por fim, o servidor MCP precisa constar no escopo dos testes de intrusão anuais exigidos pelas Resoluções CMN nº 5.274/2025 e BCB nº 538/2025.
MCP e conformidade com o Banco Central: o que muda?
O MCP cria uma nova superfície de risco regulatório que precisa ser coberta pelos mesmos controles exigidos para qualquer integração com o Core Banking. A Resolução CMN nº 4.893/2021 exige rastreabilidade, controles de acesso e segmentação de rede, requisitos que se aplicam diretamente ao gateway MCP. As Resoluções CMN nº 5.274/2025 e BCB nº 538/2025 exigem testes de intrusão anuais que devem incluir o servidor MCP no escopo. A Resolução Conjunta nº 18/2025 exige rastreabilidade de quem transformou os dados ao longo do ciclo, o que inclui agentes de IA que participam da cadeia de geração de reportes como CCS e CADOC. O Open Finance exige consentimento, finalidade e segurança em cada acesso a dados financeiros. A LGPD exige explicabilidade e possibilidade de revisão para decisões automatizadas que afetam o titular. Ignorar qualquer uma dessas camadas compromete a segurança da arquitetura.
Conclusão: MCP em Core Banking exige arquitetura, autorização e conformidade
MCP aplicado a Core Banking no Brasil converge para três aprendizados centrais para decisores técnicos e de produto.
O primeiro aprendizado é que o MCP atua como camada de interação sobre as APIs do Core Banking. Essa camada permite que agentes de IA descubram e executem operações bancárias de forma estruturada. O backend permanece inalterado. O que muda é o tipo de consumidor e o ponto de controle.
O segundo aprendizado é que a separação entre tools de leitura e tools de escrita é obrigatória. Tools de escrita sem idempotência, sem autorização elevada e sem aprovação humana em operações irreversíveis transformam cada agente autenticado em vetor de risco operacional e regulatório.
O terceiro aprendizado é que a camada regulatória brasileira, que inclui RSFN, SPB, Pix, Open Finance, LGPD, CCS, CADOC e as resoluções do Banco Central, precisa ser tratada como requisito de arquitetura. Cabe ao gateway MCP fazer a ponte entre o protocolo e a regulação, registrando cada chamada com identidade verificável, aplicando autorização por chamada e garantindo trilha de auditoria atribuível e resistente a adulteração.
Quem ignora a camada regulatória assume um risco que pode inviabilizar a operação. Quem a incorpora desde o início constrói uma arquitetura que pode escalar com segurança.
Fale com nossos especialistas em MCP e Core Banking
