Este conteúdo foi adaptado da newsletter mensal da Opus.
Assine a newsletter mensal da Opus
A pergunta que define a sua infraestrutura de Open Finance não é “construir ou comprar”.
É onde alocar a energia dos seus melhores engenheiros.
Há um padrão que se repete nas operações de Open Finance: o arquiteto mais sênior da empresa passa meses sem avançar em nada além dos tickets regulatórios. A cada semana, uma versão nova de API, um marco novo, um prazo do Banco Central.
O time que deveria desenhar o que diferencia o negócio se converte, sem que ninguém perceba, em uma equipe de manutenção de conformidade.
O problema não é de competência, e sim de gravidade regulatória: o volume de exigências absorve qualquer recurso disponível e não o devolve.
Vale, portanto, reexaminar uma decisão tratada como detalhe técnico, mas que determina performance, custo e capacidade de inovação por anos:
A formulação, do jeito que normalmente se apresenta, está mal colocada.
Este artigo explica por que build or buy é a pergunta errada para a infraestrutura de Open Finance, como usar frameworks do Gartner para decidir camada por camada, e o que essa escolha muda no custo e na alocação do seu time técnico.
Referência rápida
| O que é build or buy no Open Finance? | Qual a resposta rápida? |
É a decisão de construir ou contratar a infraestrutura técnica e regulatória para operar no ecossistema Open Finance. | Não é uma escolha única para a plataforma inteira. Contrate a camada regulatória, um Sistema de Registro no modelo Pace Layering, e construa o diferencial (jornadas, produtos, análises) por cima dela. |
Por que “build or buy” é a pergunta errada para o Open Finance
Build or buy é uma das escolhas mais antigas da gestão de tecnologia, e quase sempre é apresentada em dois polos.
Construir dá controle e liberdade, ao custo de tempo, talento e manutenção contínua. Comprar dá velocidade e previsibilidade, ao custo de depender de um fornecedor.
No Open Finance, essa moldura binária deixa de fora duas peças centrais da realidade:
- Existe um terceiro caminho. É possível estabelecer uma parceria ou a terceirização de uma camada específica, em vez da plataforma inteira.
- A decisão não precisa ser única para toda a arquitetura. Ela pode, e deve, ser tomada por partes, camada por camada, em vez de resolvida de uma vez para toda a arquitetura.
Exemplos reais
Dois exemplos reais, anonimizados, ilustram o ponto acima
Nenhuma das duas construiu tudo ou comprou tudo: ambas fatiaram a decisão camada por camada.
É essa possibilidade que a maioria das empresas deixa de considerar quando presume que precisa escolher uma aquitetura única para toda a plataforma.
O modelo que organiza a decisão: as três camadas do Pace Layering
Para fatiar a decisão com critério, utilizamos um modelo consolidado de classificação de sistemas, o Pace Layering, do Gartner, que divide os sistemas de uma empresa em três camadas conforme o ritmo em que mudam e o papel que cumprem.
A pergunta que orienta essa escolha é: em qual dessas três camadas vive a infraestrutura regulatória do Open Finance?
A resposta é clara: trata-se de um Sistema de Registro. Os papéis de detentor e transmissor de dados, por exemplo, são integralmente regulatórios.
Nesse contexto, o que importa é garantir eficiência operacional e atender aos requisitos do Banco Central, como SLA, tempo de resposta e disponibilidade.
| O que o BC exige aqui? | O que essa camada não entrega? |
| SLA | Preferência do cliente |
| Tempo de resposta | Diferenciação de produto |
| Disponibilidade | Vantagem competitiva |
São métricas de conformidade, não fontes de vantagem competitiva: cumpri-las bem é obrigação, cumpri-las de forma excepcional não faz o cliente final escolher a instituição.
Isso altera o cálculo por completo. Para um Sistema de Registro, o objetivo não é liberdade nem agilidade criativa, mas o menor custo total de propriedade possível.
A flexibilidade de customizar à exaustão, decisiva num Sistema de Diferenciação, converte-se aqui em custo sem retorno.
No vocabulário que a Amazon popularizou, é undifferentiated heavy lifting: trabalho pesado, indispensável e que não diferencia a empresa de ninguém.
Para um receptor de dados ou um iniciador de pagamento, há uma base regulatória que também precisa ser implementada e igualmente não diferencia. Mas é sobre essa base que se constrói o que de fato importa: as jornadas, as análises, os produtos que usam dado e pagamento para gerar retorno.
O teste dos quatro critérios: a matriz FACT do Gartner
Classificar a camada é o primeiro passo. Para transformar a classificação em decisão, o Gartner propõe a análise FACT.
O que é a matriz FACT?
Quatro categorias, separadas mas interligadas, para comparar opções de entrega de software de forma estruturada e objetiva, em vez de disputa de opiniões entre áreas.
O ponto central do framework é que o peso de cada critério muda conforme a camada. É aqui que FACT e Pace Layering se encaixam.
Aplicação da matriz FACT no Open Finance
Aplicando os quatro critérios à camada regulatória do Open Finance, um Sistema de Registro, o resultado é um checklist objetivo:
| Critério | Aplicação à camada regulatória do Open Finance |
| Finance | Prioridade é o menor TCO. Não há retorno financeiro por utilizar profissionais valiosos e bem remunerados para construir e, principalmente, manter uma camada que não gera receita, só conformidade |
| Agility | Evitar customização. A mudança aqui é ditada pelo regulador, não pelo negócio, o que importa é acompanhar a esteira do BC sem esforço próprio. |
| Control | Governança orientada a eficiência: SLA, disponibilidade e resposta ao regulador, não controle criativo sobre o produto. |
| Technology | Encaixe e integração. O que importa é acoplar bem aos sistemas de retaguarda, não reinventar a arquitetura. |
O que o próprio Gartner recomenda para cada camada
Cruzando as opções de entrega de software com as três camadas do Pace Layering, o próprio Gartner chega a uma matriz de preferência que confirma a tese deste artigo.
Na coluna Registro, onde vive a infraestrutura regulatória do Open Finance, contratar como serviço tem preferência alta e construir é classificado como “evitar”.
Não é uma opinião de fornecedor: é a recomendação estruturada de quem criou o modelo de camadas.
O custo real não está na fatura
Quando uma empresa decide construir a camada regulatória internamente, o erro de cálculo mais frequente não é subestimar o preço, e sim o que o projeto consome do time.
Para construir e, sobretudo, manter uma operação de Open Finance internamente, o piso realista observado pela Opus Open Finance é de cinco profissionais dedicados:
O custo de caixa, porém, é apenas o sintoma visível. O impacto mais relevante está no custo de oportunidade do talento técnico.
Cada hora que um engenheiro sênior dedica a um ticket de conformidade é uma hora que deixa de ser investida na construção do que diferencia o produto e gera retorno.
É aí que o custo vai além do TCO: enquanto o TCO mostra quanto a operação custa, a esteira regulatória revela quanto da capacidade do time ela consome.
O indicador mais simples para identificar uma empresa no caminho mais caro é este: o time técnico não consegue priorizar iniciativas estratégicas porque opera permanentemente em resposta às demandas regulatórias. Nesse ponto, a empresa paga salário de inovação para executar trabalho de manutenção.
Os custos que não aparecem na planilha
Há ainda uma camada de custos invisíveis que raramente entra na decisão e que, no Open Finance, pesa mais do que em quase qualquer outra área de tecnologia, precisamente porque há um regulador do outro lado. Entre eles, estão:
Custo reputacional
As métricas de operação não são privadas: o Dashboard do Cidadão expõe publicamente indicadores como a conversão de funil.
Uma instituição relevante que apareça ali com conversão baixa o faz à vista de concorrentes, parceiros e clientes. Uma métrica fraca deixa de ser um problema interno e passa a ser um cartão de visitas involuntário.
Custo dos novos módulos
A agenda regulatória não é estática.
Em determinado momento, passou a ser exigido um módulo inteiramente novo e de alta complexidade, exigindo que cada chamada fosse reportada em uma estrutura específica, com redesenho de arquitetura, filas de eventos e equipe dedicada.
Para quem havia internalizado a solução, foi um projeto não planejado; para quem terceirizou, o custo foi zero, porque resolver a dor regulatória é a proposta de quem opera a plataforma.
E a esteira não para: a confirmação de pagamentos iniciada em um dispositivo e concluída em outro (CIBA) e o Pix Automático são os próximos marcos a caminho.
Saiba mais sobre o Pix Automático aqui →
Quando construir faz sentido?
Terceirizar não é sempre a melhor escolha. Há três cenários claros em que construir internamente é a decisão correta.
1. Capacidade de desenvolvimento excedente
Quando a empresa dispõe de um time grande e maduro, capaz de absorver as demandas regulatórias sem comprometer o roadmap estratégico, o custo de oportunidade diminui e construir torna-se viável.
2. Recusa a adicionar fornecedores
A gestão de fornecedores tem custo próprio, e para quem já administra muitos, internalizar pode ser uma opção legítima de simplicidade operacional.
3. Necessidade de integração inegociável
Quando os sistemas de retaguarda não oferecem modularidade suficiente para integrar o Open Finance com o baixo acoplamento esperado de uma plataforma de mercado, são necessárias adaptações significativas na arquitetura.
A limitação dos sistemas de retaguarda, nesse caso, implica um alto custo de adaptação e torna o passivo tecnológico ainda mais elevado.
Em todos esses casos, a conta precisa ser feita de olhos abertos: o custo total de propriedade (TCO) subirá de forma expressiva.
O erro está em construir por orgulho técnico, presumindo que a liberdade compensa o preço numa camada que não diferencia.
A decisão é reversível
A recomendação central deste artigo é terceirizar a fundação regulatória para reduzir o TCO e liberar o time para construir o que realmente diferencia o produto.
A decisão, portanto, não é entre construir ou terceirizar tudo, mas entender quais camadas fazem sentido internalizar e quais fazem sentido delegar.
O principal entrave, na prática, é o receio do compromisso: a percepção de que terceirizar a infraestrutura é uma porta sem volta.
Tomando emprestada uma distinção difundida pela Amazon, há decisões de porta de mão única, irreversíveis, e decisões de porta de mão dupla, reversíveis.
Terceirizar a camada regulatória do Open Finance é uma porta de mão dupla. É reversível, ainda que trabalhoso.
Uma migração, para internalizar ou trocar de fornecedor, é um projeto de alguns meses com custo de transição real, mas cuja conta fecha.
Em um cenário típico acompanhado pela Opus Open Finance, uma empresa que sustenta a operação internamente a alto custo consegue recuperar o investimento da migração em menos de seis meses.
A economia vem, principalmente, de liberar recursos que antes eram consumidos pela operação e que podem, agora, ser investidos em inovação.
É possível, portanto, começar pela opção mais eficiente sem se comprometer indefinidamente.
A agenda regulatória vai acelerar
O Open Finance brasileiro é uma agenda viva, e os indícios apontam para aceleração. Cada novo marco, seja CIBA, Pix Automático ou o que vier depois, adiciona uma volta à esteira regulatória.
Para quem a carrega internamente, cada volta é um time a menos disponível para gerar valor; para quem a terceirizou, é, no máximo, uma atualização nos bastidores.
E o que isso significa para o meu negócio?
Para quem decide sobre a infraestrutura de Open Finance da própria instituição, o exercício começa por classificar os sistemas de acordo com as três camadas do Pace Layering.
Detentor de conta, transmissor de dados e servidor de autenticação tendem a fazer parte do Sistema de Registro, mesmo quando parecem estratégicos por estarem no caminho crítico da operação.
O diferencial e inovação está no que é construído sobre essa base: jornadas, ofertas personalizadas e produtos que usam o Open Finance para gerar negócio.
O risco de não fazer essa separação é concreto: times sêniores presos em manutenção de conformidade, pagando salário de inovação por trabalho que não abre nenhuma vantagem competitiva.
Não fazer essa separação tem um custo concreto. Significa manter profissionais sêniores dedicados à conformidade e à manutenção, trabalho que não gera nenhuma vantagem competitiva, enquanto paga salário de inovação.
Por isso, a pergunta que vale levar ao board não é “vamos construir ou terceirizar?”, e sim “onde estamos alocando a energia dos nossos melhores profissionais e o retorno dessa camada justifica esse investimento?”
A oportunidade está justamente aí. Cada hora de engenharia sênior que sai da manutenção regulatória e volta para a construção de produto é uma hora a mais de vantagem competitiva.
E essa escolha ganha ainda mais peso à medida que a agenda regulatória do Open Finance avança. Quanto maior a complexidade regulatória, mais importante se torna separar o que é infraestrutura do que realmente diferencia o negócio.
Como a Opus pode ajudar
A Opus assume justamente a camada presente no Sistema de Registro: a infraestrutura regulatória necessária para operar no Open Finance.
A plataforma atende aos quatro perfis do ecossistema: Iniciador de Transação de Pagamentos, Detentor de Conta, Transmissor e Receptor de Dados, com uma arquitetura modular, que permite terceirizar apenas as camadas que fazem sentido para cada instituição, sem precisar substituir toda a infraestrutura.
Saiba mais sobre o Iniciador de Transação de Pagamentos (ITP) aqui →
Com 39 anos de experiência em sistemas de missão crítica e uma subdivisão dedicada exclusivamente ao Open Finance, a Opus assume a evolução e a manutenção dessa base regulatória, acompanhando as mudanças do ecossistema e reduzindo o esforço necessário para mantê-la internamente.
Na prática, isso permite que o time interno da instituição concentre seus recursos no que realmente gera diferenciação: novas jornadas, melhores experiências e produtos que transformam Open Finance em negócio e fazem o cliente final escolher a sua instituição.
FAQ
O que significa “build or buy” no Open Finance?
É a decisão entre construir a infraestrutura regulatória internamente ou contratá-la de um fornecedor especializado. No Open Finance, essa escolha não precisa ser única para toda a plataforma: pode, e deve, ser feita camada por camada.
Devo construir ou contratar a infraestrutura de Open Finance?
Depende da camada.
Para a infraestrutura regulatória (detentor de conta, transmissor de dados, servidor de autenticação), classificada como Sistema de Registro no modelo Pace Layering do Gartner, a recomendação é contratar.
Para as jornadas e produtos que diferenciam o negócio, construir internamente costuma valer mais.
O que é Pace Layering?
Um modelo do Gartner que classifica os sistemas de uma empresa em três camadas conforme o ritmo de mudança:
Sistemas de Inovação, que mudam o tempo todo; Sistemas de Diferenciação, que mudam com frequência; e Sistemas de Registro, que mudam devagar, não diferenciam ninguém, mas precisam ser confiáveis e baratos de manter.
O que é a análise FACT do Gartner?
Um framework com quatro critérios, Finance, Agility, Control e Technology, para comparar opções de entrega de software de forma objetiva. O peso de cada critério muda conforme a camada do sistema avaliado.
O que é undifferentiated heavy lifting?
Undifferentiated heavy lifting é o trabalho necessário para manter uma operação funcionando, mas que consome recursos sem gerar diferenciação competitiva.
No caso de Open Finance, inclui o esforço para acompanhar mudanças regulatórias, atualizar APIs, realizar certificações, manter conformidade e sustentar a infraestrutura. São atividades indispensáveis, mas que não geram diferenciação.
O que é TCO?
TCO (Total Cost of Ownership, ou Custo Total de Propriedade) representa todos os custos envolvidos em construir, operar e manter uma solução ao longo do tempo, e não apenas o investimento inicial.
No Open Finance, isso significa considerar desenvolvimento, infraestrutura, equipe especializada, certificações, monitoramento, suporte, adequações regulatórias e atualizações recorrentes.
Por isso, comparar apenas o preço de um fornecedor com o custo inicial de desenvolvimento interno pode gerar uma visão distorcida. A decisão entre build or buy deve considerar quanto cada alternativa custa durante todo o seu ciclo de vida.
O que são decisões de porta de mão única e de porta de mão dupla?
Na distinção popularizada pela Amazon, decisões de porta de mão única são difíceis ou até mesmo impossíveis de reverter (irreversíveis), enquanto as de porta de mão dupla são reversíveis, ou seja, permitem voltar atrás ou mudar de caminho com mais facilidade.
Quanto custa manter uma operação de Open Finance internamente?
Na observação de campo da Opus, o piso realista é de cinco profissionais dedicados (dois desenvolvedores, um de infraestrutura, um de QA e um de produto), com tendência de alta.
O custo típico gira em torno do dobro de contratar uma plataforma pronta, para um sistema que não gera diferencial.
Por que contratar pode ser mais barato do que construir internamente?
Porque um fornecedor dilui os custos de desenvolvimento, manutenção e evolução regulatória entre vários clientes. Em uma operação interna, a empresa precisa absorver sozinha toda essa estrutura, mantê-la continuamente atualizada com novas versões, certificações e mudanças no ecossistema e dedicar profissionais especificamente a essas atividades
Terceirizar a infraestrutura regulatória do Open Finance é uma decisão reversível?
Sim. É uma decisão de porta de mão dupla, ou seja, reversível. A empresa pode trocar de fornecedor ou internalizar a operação no futuro. A migração exige tempo e investimento, mas, ainda assim, é possível.
Quando faz sentido construir a infraestrutura de Open Finance internamente?
Em três cenários: quando a empresa tem capacidade de desenvolvimento excedente, quando prefere evitar adicionar mais um fornecedor à gestão, ou quando precisa de um grau de integração com os sistemas de retaguarda que nenhuma plataforma pronta oferece.
Quais são os próximos marcos regulatórios que aumentam essa esteira?
CIBA, a confirmação de pagamento iniciado em um dispositivo e concluído em outro, e o Pix Automático são os próximos módulos a exigir adaptação de quem opera Open Finance.
Conclusão
O Open Finance no Brasil consolidou uma esteira regulatória que só tende a acelerar, com CIBA e Pix Automático como os próximos marcos.
Nesse cenário, a decisão sobre onde construir e onde contratar deixou de ser um detalhe técnico para se tornar uma escolha estratégica sobre a alocação dos talentos da empresa.
Classificar cada sistema pelas camadas do Pace Layering, e comparar as opções com os quatro critérios do FACT, transforma essa escolha em um exercício objetivo.
Para a fundação regulatória do Open Finance, um Sistema de Registro, contratar reduz o custo total de propriedade e libera o time técnico. Para o que diferencia o negócio, construir internamente continua sendo um caminho viável.
Para bancos, fintechs e demais participantes do ecossistema, a pergunta central é onde, hoje, está alocada a energia dos melhores profissionais da empresa, e se essa camada devolve retorno proporcional a esse talento.
Responder isso com critério, camada por camada, é o primeiro passo para transformar a complexidade regulatória do Open Finance em vantagem competitiva real.