Open Finance e BaaS: Além do Open Banking

As instituições financeiras estão sendo pressionadas a compartilhar dados e capacidades com clientes, fintechs, agregadores, parceiros e plataformas digitais em um ritmo para o qual sua tecnologia raramente foi construída. Muitas ainda dependem de interfaces fragmentadas, integrações ponto a ponto desenhadas para um único parceiro e práticas de compartilhamento de dados que variam de um sistema para outro.

O Open Finance e o BaaS são duas respostas interligadas a essa pressão. O Open Finance amplia o acesso a dados autorizado pelo cliente, que o open banking estabeleceu para contas de depósito e pagamentos, para um conjunto maior de produtos financeiros, como crédito, investimentos e seguros. O Banking as a Service (BaaS) expõe capacidades bancárias, como contas, pagamentos, emissão de cartões ou serviços de compliance, por meio de APIs e plataformas, para que outras empresas possam consumi-las como infraestrutura.

Nos Estados Unidos, a Seção 1033 da Consumer Financial Protection Act é a principal referência regulatória para o acesso e a portabilidade dos dados financeiros dos consumidores, e sua implementação ainda não está definida. Isso torna as escolhas de arquitetura ainda mais importantes, já que as instituições precisam de sistemas que se adaptem ao modelo regulatório que prevalecer no fim.

Os dois modelos respondem a perguntas diferentes. O Open Finance define quem pode acessar os dados financeiros, com a permissão de quem e como os participantes interagem. O BaaS trata de como as capacidades financeiras são empacotadas e entregues a outras organizações. As finanças embarcadas (embedded finance) e o composable banking estão ao lado dos dois: o primeiro conceito descreve como essas capacidades chegam aos clientes finais, e o segundo, como as instituições as organizam internamente. Este artigo analisa cada modelo do ponto de vista de negócio, de arquitetura e regulatório, para os líderes que precisam planejar o trabalho de plataforma por trás deles.

Por Que a Infraestrutura Financeira Está Ficando Mais Aberta

Durante décadas, a maioria dos bancos operou stacks de tecnologia verticalmente integrados. Produtos, dados e canais ficavam dentro de uma única fronteira, e tudo o que era externo passava por projetos customizados. Esse modelo está dando lugar a ecossistemas em que dados, produtos e capacidades são expostos por meio de interfaces padronizadas.

Várias forças impulsionam essa mudança. Os clientes esperam conectar suas contas a ferramentas de controle financeiro, credores, provedores de folha de pagamento e softwares de gestão sem atrito. As APIs, que hoje são a forma padrão de conectar sistemas, reduziram o custo de expor uma capacidade a um parceiro, e fintechs especializadas entregam capacidades específicas mais rapidamente do que uma única instituição conseguiria construí-las. Os direitos de portabilidade de dados e a atenção dos supervisores às relações com terceiros influenciam o desenho do acesso, os serviços financeiros aparecem cada vez mais dentro dos aplicativos que os clientes já usam, e as áreas de negócio querem lançar produtos em semanas, e não em trimestres.

Todas essas forças levam ao mesmo requisito técnico: interfaces estáveis e governadas para os dados e serviços da instituição. As instituições que tratam esse tema como parte de uma estratégia mais ampla de desenvolvimento de software para empresas de serviços financeiros conseguem conectar essas demandas externas às decisões de plataforma que já precisam tomar, como a modernização do core, os padrões de integração e a segurança.

Bancos como Parte de Ecossistemas Financeiros Mais Amplos

Um banco tradicional constrói ou compra um produto, distribui esse produto pelos próprios canais e mantém os dados dos clientes dentro dos próprios sistemas. Em um modelo de ecossistema, o mesmo banco é um participante entre muitos, e outras empresas consomem partes das suas capacidades.

Essa mudança alcança várias partes do stack de tecnologia. Capacidades internas, como consulta de contas, iniciação de pagamentos ou gestão de limites, passam a ser expostas por meio de APIs. A integração de parceiros segue padrões repetíveis, de modo que adicionar o décimo parceiro exige muito menos esforço do que adicionar o primeiro. Canais de terceiros vendem ou atendem os produtos da instituição, os dados dos clientes são enviados a terceiros autorizados quando o cliente solicita, os serviços são modulares o suficiente para que um componente mude sem que tudo precise ser reconstruído, e provedores especializados cuidam de funções como verificação de identidade, processamento de pagamentos ou triagem antifraude.

O banco continua sendo o provedor regulado e o sistema de registro durante todo o processo. As instituições com APIs reutilizáveis, integração repetível com parceiros e responsáveis claros por cada capacidade conseguem adicionar novos parceiros e canais sem refazer o core a cada vez.

O Open Finance no Ecossistema Financeiro dos EUA

O Open Finance é um modelo de acesso a dados financeiros mediante permissão que vai além dos dados tradicionais de conta corrente e poupança. O cliente decide qual terceiro pode ver quais dados, com qual finalidade e por quanto tempo. O escopo pode incluir crédito, investimentos, pagamentos, seguros e dados de previdência ou de patrimônio, quando aplicável, além de casos de uso mais amplos de gestão financeira.

A cobertura varia conforme a categoria. A regulação atual dos EUA não trata todos os tipos de produto da mesma forma, e o escopo exato da Seção 1033 deve ser diferenciado do conceito mais amplo de Open Finance. Parte do compartilhamento de dados no mercado americano acontece por meio de acordos privados entre instituições e agregadores, apoiados por padrões do setor, e alcança categorias que a regulação não cobre diretamente.

Open Finance versus Open Banking

A diferença está no escopo. O open banking (artigo em inglês) abrange o acesso a contas bancárias, dados de transações e serviços relacionados a pagamentos. O Open Finance aplica o mesmo modelo de permissão a produtos mantidos em bancos, credores, seguradoras e gestoras de investimentos. Os modelos de consentimento, os padrões de API e as práticas de segurança criados para os dados de contas continuam valendo, e é por isso que as instituições com capacidades maduras de open banking saem na frente.

O escopo mais amplo também muda o trabalho de desenho para os bancos americanos. Padrões de API, serviços de identidade, gestão de consentimentos e governança de dados precisam acomodar mais produtos financeiros, parceiros e escopos de permissão.

A Seção 1033 e o Movimento em Direção ao Acesso Padronizado a Dados

A Seção 1033 da Consumer Financial Protection Act garante aos consumidores o direito de acessar os próprios dados financeiros. O Consumer Financial Protection Bureau (CFPB), agência federal americana de proteção financeira ao consumidor, publicou em outubro de 2024 uma regra para implementar esse direito, abrangendo o acesso pelos consumidores e por terceiros autorizados por eles. O modelo trata do abandono do screen scraping baseado em credenciais em favor de um acesso mais padronizado por meio de APIs, com atenção à segurança de dados, ao consentimento, à autenticação, à governança e às responsabilidades dos provedores de dados.

Para os líderes de tecnologia, a discussão sobre a Seção 1033 e o Open Finance importa porque aponta uma direção: acesso padronizado, autenticado e baseado em consentimento, com responsabilidades claras dos dois lados. Essa direção é útil para o planejamento, mesmo enquanto os detalhes legais mudam.

A situação jurídica exige atenção especial. A regra de 2024 foi contestada na Justiça, e um tribunal federal no Kentucky suspendeu sua aplicação enquanto o CFPB a reconsidera. Depois de um aviso prévio publicado em agosto de 2025, que reabriu questões como quem pode atuar como representante autorizado e se os provedores de dados podem cobrar tarifas, o CFPB enviou uma proposta de reconsideração ao Office of Information and Regulatory Affairs (OIRA) em 6 de agosto de 2026. Por isso, os prazos de implementação, as entidades abrangidas, as regras de cobrança e as obrigações de compliance podem ser diferentes dos da regra original. Este artigo traz uma visão de estratégia de tecnologia e não é uma orientação jurídica, por isso as instituições devem confirmar a situação atual com seus advogados e com as fontes do CFPB e do Federal Register antes de assumir compromissos.

Implicações de Arquitetura do Acesso a Dados Autorizado pelo Consumidor

Seja qual for a forma final das regras, o acesso autorizado pelo consumidor cria um conjunto consistente de requisitos técnicos:

• Acesso padronizado por API às categorias de dados abrangidas, com interfaces versionadas e documentadas.
• Registros de consentimento que mostrem quem autorizou o quê, quando e com qual finalidade, com uma revogação que tenha efeito rápido e chegue a todos os sistemas que guardam a permissão.
• Autenticação tanto do cliente quanto do terceiro solicitante, com acesso baseado em tokens no lugar do compartilhamento de senhas.
• Minimização de dados, para que cada requisição retorne apenas os dados cobertos pela autorização.
• Registro de acessos capaz de reconstruir quem acessou quais dados e quando.
• Controles de volume e de uso, além do monitoramento de disponibilidade, latência, taxas de erro e padrões de acesso incomuns, para proteger os sistemas core de tráfego abusivo ou descontrolado.

O Banking as a Service no Mesmo Ecossistema

O Banking as a Service permite que bancos ou provedores de infraestrutura licenciados exponham capacidades financeiras por meio de APIs e plataformas, para que outras organizações possam integrá-las aos próprios produtos ou experiências do cliente. O parceiro constrói o relacionamento com o cliente e a experiência do usuário, e o provedor fornece a capacidade bancária regulada por trás dela.

Essas capacidades podem incluir infraestrutura de contas, pagamentos e movimentação de dinheiro, emissão de cartões, funcionalidades de ledger, serviços de compliance e componentes de onboarding. Os provedores variam no que oferecem: alguns se especializam em programas de cartões, outros em estruturas de contas ou em trilhos de pagamento. Por isso, cada parceria começa com um mapeamento de quais capacidades estão disponíveis e de quem assume cada responsabilidade regulatória.

Essa última questão importa mais do que parece à primeira vista. O banco que fornece a capacidade regulada continua responsável pelas atividades que o parceiro realiza em seu nome, incluindo obrigações de compliance como a prevenção à lavagem de dinheiro. O parceiro é responsável pela experiência do cliente e precisa entender as obrigações do banco antes de desenhar o produto. A orientação interagências de junho de 2023 sobre gestão de riscos de terceiros, publicada pelos reguladores bancários federais dos EUA, trata diretamente das parcerias com fintechs, e a seção sobre governança, mais adiante, volta ao que ela exige dos bancos.

Como o Open Finance e o BaaS Se Reforçam

Os dois modelos têm papéis diferentes e se encontram dentro de ecossistemas mais amplos. Uma empresa que usa uma plataforma de BaaS para oferecer contas também pode precisar de dados autorizados pelo cliente em outras instituições para avaliar a capacidade de pagamento, verificar saldos ou personalizar o produto. Um banco que expõe serviços de BaaS pode ser o provedor de dados desses mesmos clientes. Os dois dependem de APIs, identidade, consentimento e governança, e é por isso que as duas discussões acontecem cada vez mais juntas.

Pense em um credor regional que abre contas de depósito para pequenas empresas por meio de um provedor de BaaS e, com a permissão de cada cliente, consulta saldos e históricos de pagamento mantidos em outras instituições para definir o valor de uma linha de crédito. O provedor de BaaS fornece a infraestrutura de contas, e o Open Finance dá acesso às informações mantidas em outros lugares. O credor precisa coordenar as duas coisas sem perder o controle sobre as permissões dos clientes, a propriedade dos dados ou as responsabilidades de cada provedor. Essa combinação abre caminho para produtos financeiros mais conectados e aumenta a importância de uma integração confiável entre os participantes.

Composable Banking

O composable banking (artigo em inglês) é o modelo de arquitetura que conecta essas tendências. A instituição monta suas capacidades a partir de serviços modulares, cada um com responsabilidades claras, uma API consumida pelos outros componentes e um ciclo de releases próprio. Os provedores ficam por trás de interfaces estáveis, o que acelera a montagem de produtos e transforma a substituição de um único componente em um projeto contido.

Arquitetura para Ecossistemas Financeiros Abertos

As arquiteturas de Open Finance e BaaS costumam combinar várias capacidades que trabalham juntas para expor dados e serviços financeiros com segurança. A forma como elas se organizam depende do ambiente de tecnologia, dos padrões de integração e dos requisitos operacionais de cada instituição.

Os principais componentes são a gestão de APIs, que expõe interfaces documentadas e aplica controles de tráfego, acesso e uso; os serviços de identidade e consentimento, que autenticam os participantes e aplicam as permissões; e a integração e a orquestração, que coordenam as interações entre os sistemas bancários, os provedores externos e os processos de negócio. Os serviços de core banking e de BaaS executam as operações financeiras e mantêm os sistemas de registro. As plataformas de dados oferecem acesso governado às informações financeiras, com controles de transformação e qualidade. A conectividade com parceiros gerencia a integração com terceiros autorizados e serviços externos, e o monitoramento e a segurança garantem visibilidade, resposta a incidentes e proteção em todo esse conjunto.

Essas capacidades nem sempre seguem uma única sequência de execução. Uma requisição de acesso a dados pode seguir um caminho diferente de uma instrução de pagamento ou de um workflow de abertura de conta. A arquitetura deve preservar responsabilidades claras e, ao mesmo tempo, permitir que cada processo use os serviços de que precisa.

Por trás de cada API existe uma camada de controle que determina se uma requisição está autorizada, como ela é processada e o que acontece quando uma dependência falha. Uma requisição de dados autorizada pelo cliente, por exemplo, pode precisar de validação do consentimento, autenticação do parceiro, aplicação de políticas, normalização dos dados e registro do acesso antes que a resposta seja enviada. Se um desses sistemas ficar indisponível, a integração precisa falhar sem expor informações não autorizadas nem deixar um resultado inconsistente. Centralizar os controles adequados permite que a instituição aplique políticas consistentes a todos os parceiros e produtos e tenha visibilidade da requisição completa.

Identidade e Consentimento como Infraestrutura

Em um ecossistema financeiro aberto, a autorização do cliente precisa continuar consistente entre canais, produtos e conexões com terceiros. Uma permissão concedida por uma interface pode precisar ser reconhecida por vários sistemas, enquanto as alterações e revogações precisam ser refletidas em todos os pontos em que essa permissão é aplicada.

Quando a identidade e o consentimento são gerenciados de forma independente por cada aplicação, as instituições enfrentam decisões de acesso inconsistentes, registros fragmentados e mais dificuldade para demonstrar compliance. Serviços compartilhados de identidade e consentimento dão às decisões de autorização e às evidências de auditoria uma fonte consistente de informações.

O Consentimento ao Longo do Ciclo de Vida do Cliente

O consentimento muda com o tempo, e a arquitetura precisa acompanhá-lo em cada etapa:

• Criação: registrar a escolha do cliente, com seu escopo e sua finalidade.
• Verificação: confirmar a identidade do cliente e do terceiro solicitante no momento da autorização.
• Mudanças de escopo: tratar solicitações para ampliar ou reduzir permissões.
• Expiração: encerrar as permissões automaticamente quando as regras ou a escolha do cliente exigirem.
• Revogação: interromper o acesso rapidamente e notificar todos os sistemas afetados.
• Histórico de acessos: manter um registro do que foi acessado com base em cada consentimento.
• Aplicação de políticas: verificar a situação do consentimento no momento de cada requisição.

Arquitetura de Dados para o Open Finance

O Open Finance depende tanto da gestão de dados quanto da conectividade. Uma API pode entregar dados rapidamente, mas o valor desses dados continua dependendo da sua precisão, consistência e origem.

Cada domínio de dados precisa de um responsável definido, com autoridade para estabelecer definições e padrões de qualidade. Um modelo canônico dá a clientes, contas e transações uma representação comum, para a qual os formatos dos parceiros são mapeados, e a normalização converte dados de fontes diferentes em estruturas e códigos consistentes. A linhagem de dados rastreia cada dado até a sua origem e cada transformação aplicada, as regras de sincronização definem com que rapidez as mudanças em um sistema aparecem nos outros, e verificações automatizadas testam a completude, a validade e a atualidade dos dados. O controle de acesso segue o modelo de consentimento e as políticas internas da instituição, os metadados tornam os dados localizáveis pelas equipes e pelos parceiros que os utilizam, e identificadores de cliente consistentes ligam os registros de um mesmo cliente entre os sistemas.

Essas disciplinas se reforçam: os responsáveis definem os conceitos, os modelos e a normalização os aplicam, a linhagem e as verificações de qualidade os validam, e o controle de acesso limita a exposição.

Dados Fragmentados e o Valor do Ecossistema

Dados mal governados geram problemas operacionais visíveis. Registros de clientes duplicados levam a contatos em dobro, consentimentos que não batem e confusão sobre quem é o cliente. Saldos conflitantes entre sistemas causam falhas em pagamentos e chamados no atendimento, dados desatualizados levam a decisões erradas em crédito, risco e personalização, e uma categorização inconsistente das transações torna os insights financeiros pouco confiáveis. A falta de rastreabilidade da origem torna impossível resolver disputas sobre de onde veio um número, e schemas incompatíveis entre parceiros exigem um mapeamento customizado a cada nova integração. Esses problemas crescem a cada participante adicionado e costumam ser mais baratos de resolver na origem do que nos sistemas posteriores.

Onde Entram as Finanças Embarcadas

As finanças embarcadas (artigo em inglês) consistem no uso de capacidades financeiras dentro da experiência do cliente de outra empresa, e o BaaS é a camada de infraestrutura que torna isso possível. As finanças embarcadas criam oportunidades de distribuição para bancos e provedores de infraestrutura ao levar os serviços financeiros para as plataformas que os clientes já usam.

Uma seguradora, por exemplo, pode pagar indenizações em uma conta virtual ou em um cartão virtual dentro do próprio aplicativo de sinistros. O segurado interage com o aplicativo da seguradora, e a atividade regulada acontece nos sistemas bancários e nos provedores externos por trás dele.

Para a instituição financeira, esse modelo muda a forma de gerenciar a confiabilidade do serviço e o atendimento ao cliente. Um problema com saldos, status de pagamentos ou onboarding pode afetar a experiência do cliente do parceiro mesmo quando os canais digitais do próprio banco funcionam normalmente.

A Infraestrutura por Trás das Experiências Financeiras Embarcadas

As equipes precisam definir como as transações são conciliadas, como os incidentes são escalonados, quais níveis de serviço se aplicam e como as informações dos clientes são protegidas entre as fronteiras das organizações. Cada novo canal de distribuição aumenta essa carga de trabalho.

Oportunidades de Negócio para as Instituições Financeiras dos EUA

O trabalho de arquitetura sustenta várias oportunidades: novos canais de distribuição e ecossistemas de parceiros que ampliam o alcance da instituição, modelos de API ou de plataforma baseados em tarifas, parcerias mais rápidas com fintechs graças a um onboarding padronizado, insights financeiros mais ricos a partir de dados compartilhados com permissão, produtos mais personalizados, serviços de infraestrutura para plataformas não bancárias e a portabilidade do cliente, que pode ser tanto um diferencial de serviço quanto uma obrigação.

Nenhuma dessas oportunidades gera receita automaticamente. Cada uma depende de uma proposta de valor clara, de um mercado de parceiros interessado e de custos operacionais que o modelo de preços consiga cobrir. O acesso baseado em tarifas, em especial, deve aguardar o resultado da reconsideração da Seção 1033, que reabriu a discussão sobre a possibilidade de os provedores de dados cobrarem pelo acesso. As instituições obtêm os melhores resultados quando escolhem as oportunidades de acordo com seus pontos fortes e as testam com um grupo limitado de parceiros antes de escalar.

Bancos de Médio Porte e Estratégias Seletivas de Plataforma

Para os bancos de médio porte, a questão estratégica é quais capacidades oferecer e quais contratar de terceiros. Várias abordagens se encaixam nessa posição: competir pela especialização em um setor, um segmento ou um produto específico; expor capacidades selecionadas por meio de parceiros, em vez de construir uma plataforma completa; usar infraestrutura especializada de terceiros para funções caras de construir e manter; acelerar lançamentos de produtos selecionados com componentes já existentes; e participar de ecossistemas de finanças embarcadas como provedor regulado.

Os controles de fornecedores, compliance, segurança e operações crescem com o número de parceiros. Por isso, uma instituição de médio porte costuma ganhar mais com poucas relações bem governadas do que com muitas relações pouco gerenciadas.

Riscos e Governança de Parceiros

Os ecossistemas abertos trazem riscos que os stacks fechados evitavam por natureza. O risco de terceiros e a dependência de provedores externos para funções críticas crescem a cada parceiro, e a concentração de fornecedores aparece quando muitas funções dependem de um único provedor. O abuso de APIs, incluindo scraping e credential stuffing (ataques com credenciais vazadas), e o vazamento de dados por escopos amplos demais ou por parceiros mal protegidos aumentam a exposição na interface. Falhas de consentimento, como acessos que continuam depois da revogação, fraudes que se propagam rapidamente entre sistemas conectados, indisponibilidades que passam de um participante para os outros e falta de clareza sobre as responsabilidades quando algo dá errado completam o quadro. A exposição regulatória continua com a instituição mesmo quando um parceiro executa a função.

A orientação interagências de junho de 2023 deixa claro que usar um terceiro não elimina as responsabilidades do próprio banco e organiza a supervisão em cinco etapas: planejamento, due diligence e seleção, negociação do contrato, monitoramento contínuo e encerramento. As duas seções a seguir acompanham esse ciclo de vida.

Acesso de Terceiros e Responsabilização

A governança cobre todo o ciclo de vida da relação. O onboarding começa com uma due diligence sobre a segurança, a situação financeira e a postura de compliance do parceiro, seguida de escopos de acesso limitados aos dados e funções de que ele precisa. Os SLAs trazem compromissos mensuráveis, revisados com regularidade, as responsabilidades em incidentes definem quem detecta, comunica e resolve cada tipo de evento, e as revisões de segurança se repetem em um calendário recorrente. As políticas de uso de dados limitam o que os parceiros podem fazer com os dados que recebem. No fim da relação, o offboarding confirma a exclusão dos dados e o encerramento das conexões, e a revogação de acessos precisa funcionar rapidamente para um único parceiro ou para um único cliente.

Aplicar esses controles por meio de configuração e monitoramento, e não apenas de contratos, faz com que eles funcionem mesmo sob pressão. Um modelo de governança consistente também encurta o onboarding, já que cada novo parceiro segue um caminho conhecido.

Arquitetura para a Flexibilidade na Escolha de Fornecedores

A arquitetura pode reduzir a dependência de um único provedor. Uma camada de abstração coloca a interface da própria instituição entre suas aplicações e cada provedor. Contratos padronizados definem os formatos de requisição e resposta esperados de qualquer provedor de uma determinada função, e adaptadores fazem a tradução entre esse contrato e a API específica de cada provedor. Os dados ficam em formatos e locais controlados pela instituição, os limites de responsabilidade definem qual sistema guarda cada parte da lógica de negócio, e uma arquitetura componível transforma a substituição de um componente em um projeto com escopo delimitado.

Usar APIs em todos os lugares não garante a portabilidade. Schemas proprietários, lógica de negócio espalhada por vários sistemas e integrações ponto a ponto criam dependência.

Roadmap de Implementação para Instituições Financeiras

A modernização para ecossistemas abertos funciona melhor como uma série de etapas que entregam valor uma a uma, sem a substituição completa do stack. Uma sequência prática:

• Mapear as capacidades atuais de dados e de APIs. Documentar o que existe, quem usa e qual é o desempenho.
• Identificar os sistemas de registro. Definir qual sistema é a referência oficial de cada domínio de dados.
• Definir as responsabilidades relacionadas à Seção 1033. Trabalhar com as áreas jurídica e de compliance para traduzir a posição regulatória atual em requisitos técnicos e revisitá-la conforme as regras evoluírem.
• Avaliar a arquitetura de consentimento e identidade. Identificar onde essa lógica está duplicada ou ausente.
• Priorizar os casos de uso e definir padrões de API. Escolher os primeiros casos de uso pela demanda e pela viabilidade e definir convenções de nomenclatura, versionamento, segurança e documentação.
• Introduzir a governança de parceiros. Implantar os processos de onboarding, SLAs e offboarding antes que o volume de parceiros cresça.
• Modernizar a integração de forma incremental. Substituir primeiro as conexões ponto a ponto mais problemáticas e oferecer rastreamento de ponta a ponta, alertas e relatórios para todas as APIs e todos os parceiros.
• Expandir para casos de uso de BaaS ou de finanças embarcadas onde o argumento estratégico estiver claro.

Na prática, as etapas se sobrepõem, e cada uma gera algo utilizável por si só, de modo que a instituição obtém valor antes de concluir a sequência. Revisões periódicas, especialmente das responsabilidades regulatórias da terceira etapa, mantêm o roadmap alinhado às regras e à estratégia da instituição.

A ordem das etapas deve considerar primeiro a necessidade regulatória e, depois, o impacto para o cliente, os problemas de integração (trabalho manual, erros ou atrasos que custam caro), a prontidão dos dados, a maturidade das APIs e o valor estratégico, incluindo capacidades cujo retorno vem mais tarde. A substituição do core pode se justificar em algumas instituições, mas deve ser resultado dessa análise.

Como Medir o Progresso

As métricas úteis ligam o desempenho técnico aos resultados de negócio: disponibilidade e latência das APIs, tempo de onboarding de parceiros, taxa de sucesso dos consentimentos, taxas de erro no acesso a dados, incidentes de suporte ligados a problemas de integração ou de dados, tempo para lançar uma nova integração, percentual de APIs reutilizáveis, adesão dos clientes aos serviços conectados, exceções de conciliação e desempenho dos parceiros em relação aos SLAs. O volume bruto de chamadas de API diz pouco sem contexto. O conjunto de métricas deve mostrar se a plataforma é confiável, se novos parceiros e produtos chegam mais rápido à produção e se os custos operacionais e o risco estão sob controle.

Perguntas Frequentes

Como Construir uma Infraestrutura Bancária Preparada para Ecossistemas

O Open Finance e o BaaS abrem espaço para que as instituições financeiras ampliem a distribuição, conectem novos parceiros e desenvolvam serviços em torno das capacidades bancárias que já têm. Aproveitar esse espaço exige decisões sobre arquitetura, acesso a dados, integração e responsabilidade operacional.

A NTConsult ajuda as instituições financeiras a avaliar seus ambientes de tecnologia e a planejar iniciativas de integração, modernização e orquestração que sustentem modelos de negócio em evolução.

Fale com a NTConsult sobre a sua arquitetura de Open Finance.