Core banking vs BaaS: o que realmente compra

O core banking é o sistema de registo do dinheiro: o ledger que contém todas as contas, todos os saldos e todos os lançamentos, mais as regras que movem valor entre eles corretamente. O Banking-as-a-Service (BaaS) é alugar o core de outrem — e a autorização regulada que o acompanha — através de uma API, em vez de gerir o seu. Entre ter um core e apoiar-se no registo de um agente existe um espectro, e o ponto em que se situa decide o que constrói, o que aluga e pelo que responde. «Core banking vs BaaS» não é verdadeiramente uma comparação de produtos; é uma pergunta sobre quanto da stack quer possuir.

Vale a pena esclarecer, porque os dois são procurados como se estivessem no mesmo corredor. Não estão. Um é software que tem de estar correto; o outro é um acordo comercial que lhe entrega a correção como serviço e lha fatura. Saber qual está a comprar — e qual realmente necessita — é a maior parte da decisão.

O que «core banking» realmente designa

Um sistema de core banking é o ledger de referência e a maquinaria à sua volta. Contém o plano de contas, mantém os saldos, regista cada lançamento por partidas dobradas para que débitos e créditos batam sempre certo, coloca e liberta reservas, apura juros e comissões e produz os extratos de que tudo o resto depende. É a parte de um banco que tem de estar certa, porque, se o ledger estiver errado, nada construído por cima merece confiança. Tudo o resto — a app, o design do cartão, as notificações — é apresentação. O core é a verdade.

É a primeira distinção a reter: o core não é a app. O cliente vê uma app; por trás, um ledger vai mantendo as contas. Pode possuir esse ledger, alugá-lo ou apoiar-se em quem tem um. Essas três escolhas são o espectro.

O espectro: core próprio, BaaS, agente

No extremo pesado, possui o core por inteiro: o seu ledger, a sua autorização para deter ou movimentar dinheiro, as suas ligações diretas aos rails de pagamento. No meio fica o BaaS: um fornecedor licenciado detém o core e a autorização, e você constrói sobre a API dele — as contas dele, os IBAN dele, os cartões dele, com a sua marca. No extremo leve está o modelo de agente: não tem core nem licença própria, operando ao abrigo de uma entidade licenciada que o registou. Cada degrau elimina capacidade e, com ela, uma parcela de custo e de obrigações.

Ter o seu core: controlo, e a fatura que vem com ele

Ter o core compra controlo. Define o roadmap do produto em vez de esperar pelo de um fornecedor. Detém as contas diretamente, liga-se diretamente aos rails, e a sua unit economics deixa de ser a margem de outrem — à escala, a renda por conta e por transação que pagaria a um fornecedor de BaaS passa a ser margem que fica consigo. Nada se interpõe entre as suas decisões e o ledger onde elas se registam.

A fatura é grande e, na maior parte, não é de software. É preciso a autorização regulada (uma compra separada do software, e muitas vezes a mais difícil — o vocabulário de salvaguarda, interchange e liquidação está reunido em /glossary), o capital que essa autorização exige, a equipa de compliance e operações para a sustentar e integrações diretas com cada rail e scheme que utilize. E a correção passa a ser sua: quando o ledger falha às 2 da manhã, não há fornecedor a quem ligar. É dono da verdade, o que significa que também é dono das falhas.

BaaS: alugar o core e a autorização

O BaaS condensa essa fatura numa relação mensal. Um parceiro licenciado mantém as contas, emite os IBAN e os cartões, salvaguarda o float e responde perante o regulador; você constrói a app sobre a API dele e lança. O que compra é velocidade — um core funcional e autorizado desde o primeiro dia, em vez de um pedido de licença e de um projeto de ledger. Para a maioria das equipas que lança um primeiro produto, esta troca é a certa.

O que perde é a propriedade. A economia do fornecedor passa a ser o seu custo mínimo: paga por conta e por transação, e essas taxas não descem com o crescimento como acontece com uma infraestrutura própria. Os limites do fornecedor passam a ser os seus, o roadmap dele condiciona o seu, e não possui o ledger — o que torna a saída cara e a migração um projeto por si só. O BaaS é alugar a parte correta de um banco. A renda é barata no início e nunca acaba.

Um core próprio é um projeto de capital que compensa à escala. Um core alugado é um custo operacional que nunca desce. A questão não é qual é melhor — é qual deles o seu volume e a sua margem já justificam.

O modelo de agente: o mais leve de todos

Ainda mais leve, o modelo de agente pede-lhe que construa quase nada do lado do dinheiro. Regista-se como agente de uma instituição de pagamento ou distribuidor de um emitente de moeda eletrónica; a licença deles cobre a sua atividade, o core deles mantém o ledger e o regulador conhece-o através deles. É a forma mais rápida de pôr um produto financeiro com a sua marca à frente dos clientes e a que lhe deixa menos controlo — é uma cara sobre os rails de outrem, e as condições deles são o seu teto.

Onde se encaixa uma plataforma whitelabel sobre o seu core

Há uma quarta posição que o espectro esconde: ter o seu core sem construir a camada de app de raiz. A autorização regulada e o software que a opera são compras separadas — pode deter a sua licença e ainda assim comprar a app do cliente, a consola de operador e a personalização visual como plataforma por cima. É aqui que se situa uma plataforma whitelabel. O Protocore Pay (/products/pay) é a camada de software isolada: uma plataforma de apps com a sua marca e consola de operador que corre sobre o core e os rails que trouxer — próprios ou de parceiros — sem soldar uma licença à venda. A consola que o acompanha, onde cada ação privilegiada exige um motivo e fica registada num log de auditoria, é o Protocore Center (/products/center).

Enquadrar o tema desta forma é esclarecedor, porque permite avaliar as duas linhas de forma independente. A autorização é avaliada pela jurisdição, pela salvaguarda de fundos e pelas condições; o software é avaliado pelo funcionamento do onboarding, pela limpeza da integração com o ledger e pela capacidade de os operadores o gerirem de facto. Comprar software não o compromete com uma licença, e comprar uma licença não lhe dá uma aplicação — um facto que, quando se confundem as duas coisas, custa meses aos projetos sem que se perceba.

Escolher o seu degrau

A heurística honesta assenta em volume, margem e controlo. Está a arrancar, sem certeza da procura e a mover-se depressa: BaaS ou um registo como agente põem-no em produção sem aumento de capital, e aceita a renda por transação como o preço da rapidez. Está a crescer, com um volume em que a renda excede o que custariam a sua própria conformidade e infraestrutura, e com um roadmap que um fornecedor continua a bloquear: é aí que ter o core próprio começa a compensar. A maioria dos produtos começa em modelo alugado e passa para modelo próprio uma única vez — quando os números dizem que o capital e a equipa saem mais baratos do que a renda.

Nada disto é aconselhamento jurídico, e o nome das categorias muda consoante a jurisdição; use-o como o mapa que leva para uma conversa com um regulador ou um consultor, não como substituto. Mas a estrutura mantém-se em todo o lado: o core banking é o ledger que tem de estar correto, o BaaS é alugar essa correção ao mês, e uma plataforma whitelabel é o software que se coloca por cima de qualquer um dos dois. Compre o degrau que o seu volume justifica — e compre o software e a autorização como as duas coisas distintas que sempre foram.