Como um core banking para fintech registra uma transferência: regras, reserva do valor, limites e tarifa, do começo ao registro final.
Quando uma fintech compara fornecedores de core banking, a primeira coisa que aparece é uma lista: contas operando o dia todo, cadastro central, transferências por Pix, relatórios para o regulador. A lista é necessária, mas diz pouco sobre o que acontece quando uma operação sai do caminho comum. Este texto parte de uma fintech que acabou de lançar uma conta digital com transferência e tarifa, e propõe outro critério de escolha: onde ficam as regras de movimentação, o que o core registra e o que ele deixa auditar.
Na Lerian, o core banking reúne ledger, controles transacionais, tarifas, relatórios e interfaces de pagamento. O ledger é o Midaz, os controles transacionais ficam com o Tracer e os relatórios com o Reporter. Imagine que Maria transfere R$ 150,00 para João e paga R$ 1,50 de tarifa. Essa transferência vai aparecer em cada uma dessas peças.
Onde ficam as regras
A primeira pergunta é onde mora a regra que diz quem pode enviar e quem pode receber. Quando ela vive no código de cada integração, todo time que mexe na transferência reimplementa a mesma validação, e cada cópia pode divergir das outras. No Midaz, a regra fica no ledger, em rotas de transação. Uma rota define, por exemplo, que origem e destino precisam ser contas correntes, e o ledger recusa qualquer transação fora desse desenho. Se Maria tentar enviar de uma conta de poupança que a rota não aceita, a operação é rejeitada sem que o aplicativo precise escrever essa checagem.
Cada transação guarda também o identificador da rota que seguiu. Meses depois, quando o compliance perguntar por que aquele movimento foi aceito, a resposta está no próprio registro, e não na memória de quem escreveu o código.
Reservar, confirmar e desfazer
A transferência de Maria acontece em um passo, mas nem todo fluxo é assim. Quando o valor precisa ficar reservado até uma aprovação, o Midaz trabalha com o cenário de duas etapas. Se a transferência de Maria precisasse de aprovação, os R$ 150,00 sairiam do saldo disponível dela e ficariam reservados. O dinheiro continua sendo da conta de Maria, mas fora do que ela pode gastar, e a transação fica pendente até a próxima etapa.
Quando a aprovação chega, a confirmação libera o valor para João. Se ela não chega, o cancelamento devolve o valor ao saldo disponível de Maria. Nos dois casos, cada etapa é um lançamento próprio, e o saldo mostra cada movimento no momento em que ele acontece, e não só o resultado final.
A reversão trata de outra situação, a da transação que já foi concluída. Depois de aprovada, uma transação do Midaz não pode ter os valores alterados nem ser apagada. Para desfazê-la, o ledger cria uma nova transação em sentido contrário, ligada à original, e as duas ficam no histórico.
Controles transacionais
Antes de a transferência de Maria chegar ao ledger, alguém precisa perguntar se ela pode acontecer. No core da Lerian, o Tracer responde a essa pergunta: recebe a operação e a valida contra regras e limites antes do registro. Uma regra é uma expressão curta, como negar transações acima de certo valor para um segmento, e o limite pode ser diário, semanal, mensal ou por transação. Se a conta de Maria tiver um teto diário de R$ 5.000,00 e ela já tiver movimentado R$ 1.000,00 no dia, a transferência de R$ 150,00 passa.
A resposta do Tracer é uma decisão: permitir, negar ou enviar para revisão, acompanhada do que se aplicou e do quanto do teto já foi usado. Quem age sobre a decisão é o sistema que chamou o Tracer, e cada validação fica registrada em uma trilha de auditoria imutável. Regras e limites são fáceis de mudar pela interface do Tracer.
Tarifas, relatórios e interfaces
A tarifa de R$ 1,50 mostra por que a forma do registro importa. No Midaz, ela entra como um terceiro lançamento da mesma transação, creditada em uma conta interna de receita. Maria é debitada em R$ 151,50, João recebe R$ 150,00 e a conta de receita recebe R$ 1,50, tudo em uma única transação atômica. O financeiro vê para onde foi cada centavo, porque a tarifa é um lançamento e não um campo escondido em metadados. A precificação pode variar por produto, cliente ou tipo de operação, e cada cobrança gera o seu lançamento contábil.
Como tudo isso fica no mesmo ledger, o Reporter gera relatórios contábeis, regulatórios e operacionais a partir dos mesmos dados, com modelos configuráveis. As interfaces completam o desenho: Pix, boleto, TED e pagamento de contas se integram ao ledger por mensageria da Lerian ou de terceiros, e a transferência de Maria, se sair por Pix, termina como um registro no mesmo lugar.
No fim, a fintech consegue responder, para a transferência de Maria, qual regra ela seguiu, se passou pelos limites, quais lançamentos gerou, para onde foi a tarifa e como seria desfeita. Contratar um core transfere a manutenção do sistema, mas a instituição continua sendo quem explica cada movimentação a auditores e ao compliance. Por isso, além de contar funções, vale testar o que o core mostra quando alguém pergunta.
O core banking da Lerian reúne essas peças em uma plataforma modular, que inclui ainda o CRM, com campos sensíveis criptografados, e a estrutura de contas para subentidades.
Conheça o Core Banking Lerian
O core banking da Lerian reúne ledger, controles transacionais, tarifas, relatórios e interfaces de pagamento, para que a operação fique registrada, controlada e auditável em um só lugar.