Impulsionando o consentimento de Open Banking com MongoDB e agentes de IA

O Open Banking e o Open Finance (OB&OF) só se expandem se os clientes puderem conceder e renovar o consentimento de uma forma que pareça segura, transparente e sem esforço. No entanto, hoje o atrito no consentimento faz com que mais da metade dos usuários abandone experiências digitais que, de outra forma, seriam de alto valor. Este blog mostra como as instituições financeiras podem usar o MongoDB, os agentes de IA, o MongoDB Atlas Vector Search e o MongoDB MCP Server para transformar fluxos de consentimento fragmentados em uma jornada única e auditável que reduz o abandono e impulsiona o crescimento do open finance.

À medida que os consumidores reconhecem o valor dos seus dados, eles estão cada vez mais dispostos a compartilhá-los quando a experiência é clara e confiável. Uma pesquisa recente da Mastercard mostra que 76% dos consumidores mudariam de provedor para obter uma gestão financeira digital superior, e 82% estão dispostos a compartilhar dados para simplificar solicitações de empréstimos ou garantir melhores taxas de juros.

Segundo o CGAP, o ecossistema de Open Finance do Brasil já conecta mais de 41 milhões de contas e, nos EUA, a regra da Seção 1033 do CFPB está formalizando os direitos de acesso dos consumidores aos dados.

Historicamente, as instituições financeiras controlavam em grande parte os dados financeiros dos clientes. OB&OF transforma esse modelo ao transferir o equilíbrio de poder para os consumidores, ao mesmo tempo que reforça a função das instituições como custodiantes confiáveis dos dados. Na prática, os consumidores ganham maior controle sobre quais terceiros podem acessar seus dados financeiros, quais dados podem ser compartilhados e por quanto tempo. No centro dessa mudança está o consentimento explícito e informado, que permite aos consumidores autorizar e gerenciar o acesso aos seus dados financeiros. Essa mudança também reforça a transição de um modelo centrado no produto para um modelo mais centrado no cliente, à medida que as instituições financeiras competem cada vez mais para conquistar e manter a confiança, o engajamento e a relevância junto aos clientes, em vez de dependerem principalmente do controle sobre o relacionamento com o cliente e seus dados.

Figura 1. A mudança de poder no relacionamento.

Um desafio em OB&OF é que as jornadas de consentimento não acompanharam. Linguagem jurídica densa, ciclos recorrentes de reautenticação de 90 dias e redirecionamentos desconexos agora bloqueiam a adoção mais do que a própria regulamentação: provedores como a TrueLayer relatam taxas de abandono superiores a 50% durante os fluxos de consentimento, e a análise do mercado brasileiro pelo CGAP destaca o atrito na jornada de consentimento como um dos principais fatores que impedem a participação no ecossistema.

Para corrigir isso, as instituições precisam de uma maneira mais clara de definir o que está sendo autorizado e uma melhor experiência de usuário para concedê-lo. O framework DPSD— escopo de dados, finalidade, fonte e duração — oferece a todos um modelo compartilhado de consentimento. O restante deste blog mostra como um copiloto de agentes de IA, apoiado pelo MongoDB como a camada unificada de consentimento e memória, pode operacionalizar o DPSD sem aumentar o atrito.

Como o framework DPSD organiza o consentimento em OB&OF?

O gerenciamento eficaz de consentimentos no OB&OF depende do framework DPSD, que divide cada consentimento em quatro parâmetros claros:

• Escopo de dados: define os clusters de dados específicos e os níveis de sensibilidade de acesso que estão sendo solicitados, variando de dados compartilháveis a registros privados e altamente privados, que devem ser estabelecidos formalmente nos Termos e Condições do serviço.
• Finalidade: define o motivo explícito da coleta de dados.
• Instituição de origem e identidade: identifica o detentor dos dados e o destinatário.
• Duração do acesso: Define o período de autorização para o destinatário.

Quais casos de uso de OB&OF dependem do consentimento explícito do consumidor?

Como detalhado no whitepaper, Next Generation Open Finance with MongoDB and Agentic AI, várias ofertas altamente valiosas e centradas no cliente não podem operar sem essa estrutura de permissão formal, como:

• Gerenciamento financeiro pessoal (PFM) proativo: agrega contas de vários bancos, empréstimos e carteiras de investimento em um único dashboard para fornecer insights de gastos e estratégias de melhoria de crédito em tempo real.
• Serviços de iniciação de pagamentos (PIS): permitem pagamentos instantâneos, transferências recorrentes e solicitações de crédito entre provedores em aplicativos de terceiros, sem usar os portais do banco de origem.
• Pontuação de crédito alternativa: utiliza hábitos transacionais, pagamentos de serviços públicos e dados de fluxo de caixa para automatizar a subscrição digital e acelerar as aprovações de crédito para consumidores com arquivos de crédito reduzidos.
• Portabilidade de crédito e empréstimo: agrega dados históricos de desempenho para automatizar comparações de taxas e preparação de documentos, oferecendo aos consumidores melhores opções financeiras.

Por que o consentimento está interrompido no OB&OF?

O consentimento não funciona porque a experiência do usuário (UX), a complexidade legal e os fluxos de reautorização de 90 dias fazem com que os consumidores abandonem casos de uso que seriam valiosos. Embora o framework DPSD pareça simples no papel, sua implementação no mundo real está repleta de desafios que corroem a confiança do consumidor:

• Complexidade jurídica: os consumidores muitas vezes se sentem sobrecarregados pela terminologia jurídica densa, em vez de receber explicações claras e em linguagem simples sobre os contratos.
• Design de UX manipulativo: padrões de design inadequados podem induzir os usuários a compartilhar dados em excesso ou criar obstáculos desnecessários ao tentar revogar o acesso.
• Fricção na interface: Etapas excessivas e navegação desconexa entre aplicativos de terceiros e portais bancários degradam a experiência do usuário e reduzem a transparência.
• Preocupações de segurança: a falta de familiaridade com novos provedores geralmente gera ansiedade do consumidor em relação à privacidade dos dados e possíveis usos indevidos.

Onde ocorre o atrito de consentimento na jornada de OB&OF?

Para identificar onde os agentes de IA podem fornecer mais valor, devemos analisar a jornada de consentimento padrão com base nas Diretrizes de experiência do usuário da FDX.

Figura 2. Fluxo de concessão de consentimento de compartilhamento de dados.

Nesse fluxo, surgem vários pontos críticos de fricção em que os usuários se sentem sobrecarregados ou perdidos:

• Esclarecimento de valor: muitos usuários abandonam o processo logo no início porque os benefícios de OB&OF não são claramente articulados.
• Negociação de parâmetros: jargões complexos dificultam que os usuários entendam os parâmetros do DPSD ou negociem acesso granular e parcial aos dados.
• Confusão com redirecionamento: a transição entre aplicativos e portais institucionais geralmente cria um "abismo de redirecionamento" onde os usuários perdem o contexto do processo.
• Fadiga de autenticação: O requisito recorrente de reautenticação a cada 90 dias gera atrito significativo e frustração para os usuários.
• Lacunas de transparência: as instituições muitas vezes não fornecem dashboards centralizados que exibam claramente as autorizações ativas e os limites de compartilhamento de dados.

Quando essa jornada é apoiada pelo MongoDB como a camada de memória operacional e de IA compartilhada, um copiloto agêntico pode explicar as compensações em linguagem simples a cada etapa, em vez de forçar os usuários a passar por redirecionamentos opacos e formulários estáticos.

Como os agentes de IA podem atuar como um copiloto de consentimento em OB&OF?

Um copiloto de consentimento com agentes de IA substitui formulários estáticos por um guia conversacional que explica as vantagens e desvantagens em linguagem simples, orienta os usuários durante os redirecionamentos bancários e automatiza a reautenticação, preservando a rastreabilidade completa e a revogação instantânea. Ele simplifica a experiência ao:

1. Simplificar o jargão: oferecendo tradução de juridiquês complexo da DPSD para uma linguagem clara e coloquial.
2. Navegar de forma guiada: fornecendo orientação passo a passo em tempo real durante redirecionamentos bancários para definir expectativas claras do usuário.
3. Automatizar a reautenticação: o gerenciamento seguro de ciclos de reautenticação de 90 dias por meio de aprovação biométrica simples substitui logins complicados de várias etapas. Crucialmente, este processo opera com rastreabilidade de ponta a ponta e registro de auditoria imutável, proporcionando aos consumidores visibilidade completa e a capacidade imediata de revogar o consentimento a qualquer momento.
4. Habilitar o controle granular: capacitando os usuários a selecionar facilmente o compartilhamento parcial de dados (por exemplo, compartilhamento de dados de conta corrente e exclusão de poupança).

Figura 3. Agentes de IA como copiloto de consentimento.

Figura 4. Visão geral da arquitetura: integração dos agentes de IA e do MongoDB para habilitar o fluxo de concessão de consentimento.

Por que o MongoDB é o habilitador da IA agêntica

O MongoDB fornece a camada de dados unificada e a infraestrutura de IA de que esses agentes precisam — armazenando registros de consentimento e o estado do agente, viabilizando a pesquisa vetorial no conteúdo das ofertas de instituições jurídicas e financeiras e expondo ferramentas seguras via MCP para que os agentes possam agir com segurança em nome do cliente. Para líderes de TI que arquitetam o futuro dos serviços financeiros, os agentes de IA só funcionam em escala se houver uma camada de dados unificada para consentimento, estado e memória — que é o que o MongoDB oferece.

O MongoDB está posicionado de forma única como a camada de dados fundamental para essa arquitetura:

1. Perfis de agentes, metas e fluxos de trabalho: o Open Finance exige o gerenciamento de transições de estado de várias etapas ao lado de níveis de autorização granulares, que variam de metadados de conta compartilháveis a registros altamente privados. O document model flexível do MongoDB agiliza essa complexidade ao incorporar estados dinâmicos do agente, metas em evolução e escopos de permissão em camadas diretamente em um único documento. Isso permite que as aplicações atualizem os níveis de autorização de consentimento e rastreiem o progresso do fluxo de trabalho dos agentes em tempo real, sem migrações de esquema rígidas ou junções complexas de várias tabelas.
2. Histórico de instruções: manter um registro de auditoria verificável das instruções de IA e das decisões de consentimento do usuário é fundamental para o compliance. O MongoDB lida com eficiência com históricos de instruções de alto volume com carimbo de data/hora.
3. Memória de curto e longo prazo: Para funcionar como um copilot verdadeiramente personalizado, um agente de IA requer memória. O MongoDB unifica o gerenciamento do estado da conversa de curto prazo (a sessão atual) e da memória de longo prazo (preferências históricas e ciclos de reautenticação de 90 dias) em uma única plataforma.
4. Pesquisa vetorial: MongoDB Atlas Vector Search armazena embeddings vetoriais junto com dados operacionais. Isso permite que a IA recupere instantaneamente explicações simplificadas e relevantes para jargões jurídicos complexos com base na similaridade semântica.
5. Integração com a Voyage AI: ao integrar modelos avançados de embedding e reclassificação, como a Voyage AI, ao MongoDB Atlas Vector Search, o sistema obtém recuperação contextual ultraprecisa, garantindo que o agente de IA forneça interpretações precisas de termos e regulamentações financeiras.
6. Integração com o servidor MCP: por meio do Protocolo de Contexto de Modelo (MCP), o MongoDB conecta com segurança os modelos de IA diretamente às fontes de dados corporativas. Isso permite que os agentes leiam os perfis de consentimento do usuário e dados transacionais, e executem chamadas de API em nome do usuário com controles de acesso rigorosos. O servidor MCP atua como um tradutor, permitindo que agentes se comuniquem diretamente com as operações do banco de dados.

Figura 5. Como o MongoDB possibilita e acelera os agentes de IA.

Figura 6. Uma abordagem de arquitetura aberta permite que o chatbot agente responda a perguntas ad hoc sobre acesso a dados concedido, contas de clientes, transações e produtos fazendo consultas diretamente ao MongoDB por meio do servidor MCP. Esse design flexível permite que as instituições financeiras integrem seus modelos empresariais de linguagem longa ou curta e frameworks de IA de sua preferência.

tópicos

Ao combinar os agentes de IA com o MongoDB, as instituições financeiras podem transformar o consentimento de um gargalo de conformidade em uma vantagem competitiva, melhorando a satisfação do cliente, reduzindo custos operacionais e fortalecendo a auditabilidade em seus ecossistemas de Open Finance.

• Maior satisfação do cliente e NPS: cria confiança por meio de transparência com linguagem simples, integração sem atrito e redução da rotatividade dos usuários.
• Menores custos operacionais: automatiza explicações e orientações complexas de T&C, reduzindo significativamente a sobrecarga do call center e o suporte humano.
• Rastreabilidade e auditabilidade: fornece logs de auditoria completos e verificáveis para cada concessão de consentimento, modificação e evento de compartilhamento de dados.

Com o MongoDB sustentando a memória, o estado e as capacidades vetoriais desses agentes de IA, as instituições financeiras têm a plataforma de desenvolvedor unificada necessária para oferecer experiências de OB&OF seguras, escaláveis e sofisticadas, sem complexidade arquitetônica.