Sexta-feira, 17h40. Dona Lurdes, aposentada, aceita pelo aplicativo do banco um empréstimo consignado de R$ 8.000 em 84 parcelas.
Se você nunca contratou um, consignado é o empréstimo em que a parcela é descontada direto do salário ou da aposentadoria, antes de o dinheiro chegar à conta. Quem entrega a parcela ao banco não é a dona Lurdes: é o INSS, que paga o benefício dela. Para o banco, isso quase elimina o risco de calote. Para ela, significa uma das taxas de juros mais baixas do mercado.
Só que, para o desconto acontecer, o banco precisa avisar ao INSS: "deste benefício, R$ 190 por mês agora são meus". Esse aviso tem nome, averbação1, e passa pela Dataprev2, a empresa que processa os dados da Previdência.
A proposta sai do sistema do banco em direção à Dataprev. A resposta demora. Depois de 30 segundos sem retorno, o sistema desiste de esperar, o famoso timeout, e faz exatamente o que foi programado para fazer: tenta de novo. A segunda tentativa também não volta. Aí entra a última regra do fluxo, escrita meses antes por alguém que queria evitar proposta travada no fim de semana: se a averbação não responder em duas tentativas, segue para o desembolso e concilia na segunda-feira.
Segunda-feira de manhã, o atendimento abre dois chamados. No primeiro, a margem da dona Lurdes aparece com duas parcelas reservadas e um único depósito de R$ 8.000 na conta: ela vai pagar R$ 380 por mês por um empréstimo cuja parcela é R$ 190. A Dataprev tinha recebido os dois pedidos e estava apenas lenta para responder.
No segundo chamado, outro cliente recebeu o dinheiro via Pix e a margem dele nunca foi reservada: ali os dois pedidos morreram no caminho, e a Dataprev nunca soube que existiram. Na folha seguinte, não vai haver parcela para descontar.
Ninguém escreveu um bug no sentido clássico. Os testes passavam. O código fazia o que dizia. O problema estava no modelo: ele não tinha onde guardar a pergunta "a Dataprev recebeu o meu pedido ou não?".
O contrato estava perfeito no banco de dados do banco e não existia no único lugar que importava.
Uma única regra de timeout, dois incidentes opostos. A diferença entre eles não estava no código: estava num fato que o código não tinha como saber, se o pedido chegou do outro lado ou não. Sem lugar para guardar essa dúvida, o sistema foi obrigado a chutar. Chutou duas vezes, e errou nas duas direções possíveis.
A cena é fictícia; os ingredientes, não. Este artigo é sobre por que isso acontece com consignado, com financiamento de carro, com antecipação de recebível e com praticamente qualquer produto de crédito no Brasil, e sobre por que todos eles quebram do mesmo jeito.
Ele foi escrito para dois tipos de leitor. Se você trabalha com tecnologia, vai encontrar modelagem, estados e código. Se não trabalha, vai entender por que o seu empréstimo às vezes demora a cair, e por que a taxa de um crédito é tão diferente da de outro. As partes técnicas vêm sempre com uma tradução ao lado.
Antes de tudo: o que é crédito?
Crédito é dinheiro de hoje trocado por uma promessa de amanhã.
A palavra vem do latim credere, acreditar. Quem empresta acredita que o dinheiro vai voltar. E essa crença tem preço: os juros3, que pagam duas coisas ao mesmo tempo. Uma é o tempo, porque o dinheiro emprestado deixa de render para quem emprestou. A outra é o risco de a promessa não ser cumprida.
Muita gente usa crédito sem chamar pelo nome. A compra parcelada no cartão é crédito. O carnê da loja é crédito. O cheque especial que entra sozinho quando a conta fica negativa é crédito, e dos mais caros. Até o "parcelado sem juros" é crédito: alguém está financiando aquela compra, e o custo foi embutido no preço ou pago pela loja.
As duas perguntas de quem empresta
Imagine que um conhecido te pede R$ 500 emprestados. Antes de responder, você faz duas perguntas, mesmo sem perceber:
Essa pessoa vai me pagar? Você pensa no que sabe dela: se trabalha, se costuma honrar o que promete, se já te deu calote.
E se não pagar, o que eu faço? Se ela deixar o celular com você até devolver o dinheiro, você empresta mais tranquilo. Se não deixar nada, você pensa duas vezes, ou empresta menos.
Essas duas perguntas são o mercado de crédito inteiro. A primeira os bancos respondem com informação: histórico de pagamentos, renda, dívidas em aberto. A segunda eles respondem com garantia4: alguma coisa que o banco pode segurar se a promessa falhar.
Por que existem tantos tipos de crédito?
Porque existem muitas respostas diferentes para a segunda pergunta. Cada tipo de crédito é, no fundo, uma resposta diferente para "o que o banco pode segurar?".
No consignado, o banco segura a parcela antes de ela chegar ao cliente, porque ela sai direto do salário ou do benefício.
No financiamento de veículo, o banco segura o próprio carro. Ele fica no nome do banco até a última parcela.
No crédito imobiliário e no home equity5, o banco segura o imóvel.
Na antecipação de recebíveis, que é crédito para empresas, o banco segura o dinheiro que a loja ainda vai receber das vendas no cartão.
No crédito pessoal, no cheque especial e no rotativo do cartão6, o banco não segura nada. Só tem a informação da primeira pergunta.
E a regra geral é intuitiva: quanto mais o banco consegue segurar, menos risco ele corre, e menor tende a ser a taxa. Com uma correção que importa mais do que parece: o que pesa não é ter garantia, é poder executá-la rápido e barato. Garantia que leva anos no Judiciário para virar dinheiro entra no preço quase como se não existisse, e é por isso que o carro, que vale muito menos que o apartamento, sustenta uma taxa melhor que o home equity.
Agora vem a parte que quase ninguém percebe, e que dá título a este artigo. O que torna um crédito barato é a garantia — e, em quase todos os casos, ela não está com o banco. O salário está na folha do INSS ou da empresa. O carro está registrado no Detran. O imóvel, no cartório. Para o crédito sair mais barato, o banco precisa reservar alguma coisa dentro de um sistema que não é dele.
Vale a exceção, porque ela prova o ponto: existe crédito barato cuja garantia está dentro de casa. No empréstimo com garantia de investimento, o banco bloqueia um CDB do próprio cliente, e a reserva vira uma linha numa tabela sua, com transação e UNIQUE. Todo este artigo deixa de existir. O problema nunca foi a garantia: é a fronteira. O custo de engenharia nasce no instante em que o recurso escasso passa a morar do lado de fora.
É aí que a conversa vira engenharia.
Um restaurante que não é seu
Quando um banco oferece crédito com garantia, ele está tentando reservar algo que não mora no seu próprio banco de dados.
Pense numa reserva de restaurante feita por telefone. Você liga, pergunta se tem mesa para quatro às 20h, pede para reservar e desliga. A mesa não é sua. O caderno de reservas fica no restaurante. A única coisa que você tem é a lembrança de que ligou.
Agora imagine que a ligação caiu no meio da frase "então fica reservado no nome de...". Você reservou ou não? Se ligar de novo e disser "quero uma mesa para quatro às 20h", pode sair com duas mesas no seu nome. A pergunta certa é outra: "vocês têm alguma reserva no nome Rafael?"
Só que essa pergunta tem uma condição escondida, e ela é a parte que mais se esquece: você só pode perguntar "tem reserva no nome Rafael?" porque disse o seu nome antes de a ligação cair. Se não disse nada que identifique o pedido, não existe pergunta a fazer. Existe apenas pedir de novo, e torcer.
Guarde essa diferença entre repetir o pedido e perguntar pelo pedido. Ela é o artigo inteiro.
Todo crédito com garantia segue os mesmos quatro movimentos:
Consultar se o recurso escasso está livre: a margem do aposentado, o carro sem restrição, o recebível ainda não comprometido.
Reservar esse recurso junto a quem guarda o registro oficial dele.
Liberar o dinheiro. Só a partir daqui o contrato existe de verdade.
Devolver, se o contrato não nascer. Este é o movimento que quase ninguém desenha, e é dele que sai o incidente que ninguém abre.
O que muda de um produto para outro são três características da contraparte7:
Quem guarda a verdade. Um sistema central, dezenas de sistemas diferentes, uma entidade de registro, ou ninguém.
Quanto demora e quando fecha. Milissegundos, horas ou dias, e com quais janelas de indisponibilidade.
Se dá para desfazer. Existe desaverbação, baixa de gravame, cancelamento de registro? Em quanto tempo?
Com essas três perguntas, os produtos de crédito brasileiros se agrupam em quatro famílias. Antes de visitar cada uma, vale resolver o problema da dona Lurdes, porque ele aparece em todas.
O estado que quase ninguém modela
Entre pedir a reserva e saber o resultado existe um intervalo, e o seu modelo precisa ter um nome para ele.
Antes de nomear o intervalo, a condição técnica que o torna tratável. A pergunta "você recebeu o meu pedido?" só existe se o pedido levar um identificador estável, gerado e gravado pelo banco antes da primeira chamada e repetido em toda tentativa e em toda consulta. É o seu nome na reserva do restaurante. Essa chave de correlação é o que separa um estado de desconhecimento, que você resolve depois, de um beco sem saída, em que você sabe que não sabe e não tem como descobrir.
No artigo sobre modelagem de dados, vimos que estados intermediários são cidadãos de primeira classe: dinheiro em trânsito precisa de endereço. Com a garantia é igual. Veja uma máquina de estados8 para a originação, que é o nome técnico para o nascimento de um contrato de crédito.
Se você não programa, leia o bloco abaixo como uma lista de situações possíveis para o contrato, na ordem em que acontecem. As frases depois de // são comentários explicando cada uma.
public enum OriginationStatus {
PROPOSAL_CREATED,
COLLATERAL_CHECKED, // a snapshot, not a reservation: it can go stale
RESERVATION_REQUESTED, // sent with our correlation key; no answer yet
RESERVATION_CONFIRMED, // has an expiry date: the counterparty may drop it
RESERVATION_REJECTED,
RESERVATION_UNKNOWN, // timeout: we do not know. Bounded in time, not forever
RESERVATION_EXPIRED, // confirmed, then aged out before the money left
MANUAL_REVIEW, // UNKNOWN hit its ceiling: a human owns it now
DISBURSEMENT_SENT, // reachable only from RESERVATION_CONFIRMED
DISBURSEMENT_FAILED, // the money never left: the reservation must go back
RESERVATION_RELEASED, // margin returned. The only honest end for a dead proposal
ACTIVE,
SETTLED,
CANCELLED
}Os estados CONFIRMED e REJECTED todo sistema tem. O RESERVATION_UNKNOWN quase nenhum tem, e é ele que representa a ligação que caiu. Sem esse estado, o sistema só tem duas mentiras à disposição, e nada o impede de contar as duas em sequência:
tratar o timeout como falha e pedir de novo, o que pode gerar reserva duplicada;
tratar o timeout como sucesso e liberar o dinheiro, o que pode gerar dinheiro sem garantia.
Foi exatamente o que o fluxo da sexta-feira fez, nessa ordem: pediu de novo e, sem resposta, liberou o dinheiro. Os dois chamados da segunda-feira não foram dois bugs diferentes. Foram a mesma omissão, vista por dois clientes com sortes diferentes.
Repare também no COLLATERAL_CHECKED, que existe por um motivo específico: consultar disponibilidade é tirar um retrato, não reservar nada. Entre o retrato e a reserva, a margem pode ter sido tomada, e o concorrente mais provável não é outro banco. É a sua própria casa. Duas propostas do mesmo CPF entrando por canais diferentes na mesma tarde consultam a mesma margem livre, as duas passam na validação e as duas pedem reserva. Se a soma não couber, a contraparte recusa uma delas num dia bom; se couber, ela aceita as duas e o cliente descobre no extrato. Por isso a reserva começa dentro de casa, com um bloqueio local da margem, com prazo de validade, antes de qualquer chamada externa. A fila de quem liga para o restaurante também é sua.
A regra que sai disso cabe numa linha: timeout não é falha nem sucesso. É desconhecimento, e desconhecimento se resolve consultando, não repetindo.
O incidente que ninguém abre: a reserva que ninguém devolve
Os dois chamados da segunda-feira têm um irmão silencioso, e ele é mais comum que os dois juntos. Entre RESERVATION_CONFIRMED e DISBURSEMENT_SENT existe uma janela em que a margem já está comprometida e o dinheiro ainda não saiu. Se o desembolso falha, se a análise reprova numa segunda passada, se o cliente desiste, ou se a proposta simplesmente morre no backlog, aquela fatia da renda fica presa a um contrato que nunca existiu.
Do lado do banco ninguém abre chamado: nenhum real saiu, nenhum painel ficou vermelho. Do lado do cliente, é um dos atendimentos mais frequentes do consignado, "minha margem está presa e eu não consigo contratar em lugar nenhum". É o caso da dona Lurdes de novo, com o prejuízo do outro lado do balcão.
Daí saem duas consequências de modelagem. A primeira: desfazer é um estado, não um script de emergência. Todo caminho que não termina em contrato ativo precisa passar por uma liberação explícita, com protocolo de volta da contraparte, exatamente como a reserva teve. A segunda: reserva confirmada tem prazo. Boa parte das contrapartes derruba a reserva sozinha se o contrato não for concluído em alguns dias, o que significa que RESERVATION_CONFIRMED não é um estado permanente. Ele envelhece. Quem trata essa confirmação como definitiva vai, em algum dia movimentado, desembolsar contra uma garantia que já caiu.
A mesma régua vale para o desconhecimento. RESERVATION_UNKNOWN precisa de teto. Consultar com intervalo crescente é correto por algumas horas; depois disso, continuar consultando é só uma forma elegante de nunca decidir. Vencido o teto, o contrato vai para revisão humana, com dono e prazo, e alguém avisa o cliente, porque do lado dele a proposta está parada sem explicação desde sexta-feira.
Pense comigo
Se a contraparte cair entre o seu pedido e a resposta dela, em qual estado do seu modelo o contrato fica? Se a resposta for "depende do log que a gente olhar", está faltando um estado.
O seu retry pergunta antes de repetir? Se não pergunta, ele não é retry. É um segundo contrato esperando para acontecer. E o pedido original leva uma chave que torne essa pergunta possível, ou você só tem o seu próprio id interno, que a contraparte nunca viu?
Existe algum caminho no código em que o dinheiro sai sem a reserva estar confirmada? Vale procurar hoje, porque em produção ele aparece de qualquer jeito. E o caminho inverso, que ninguém procura: existe algum em que a proposta morre e a margem fica reservada?
Quatro jeitos de guardar a verdade
Os produtos de crédito brasileiros cabem em quatro arquétipos, definidos por quem guarda o registro da garantia. Cada um exige uma coisa diferente do seu sistema.
Arquétipo 1: uma contraparte central, e o calendário dela
Quando toda a verdade mora num lugar só, a integração fica mais simples e você passa a viver no ritmo de outra organização.
O consignado de aposentados e pensionistas sempre passou pela Dataprev. Em 2025, o consignado dos trabalhadores com carteira assinada foi pelo mesmo caminho. A Lei 15.179/2025 criou o programa Crédito do Trabalhador e acabou com os convênios individuais entre empresas e bancos. Hoje a consulta de margem, a averbação e o controle dos contratos passam por uma plataforma central, integrada ao eSocial9, à CTPS Digital e ao FGTS Digital. Para o trabalhador CLT, a margem é de até 35% da remuneração disponível.
E tem um detalhe do Crédito do Trabalhador que quase não aparece nas análises de arquitetura: a garantia não é só a margem. O programa usa também o FGTS do trabalhador, até 10% do saldo da conta mais a multa rescisória, como lastro para o caso de demissão. São duas reservas, em dois registros que não são seus, com prazos e regras de baixa diferentes: a folha, pelo eSocial, e o fundo, pelo FGTS Digital. Pelo mesmo motivo, a antecipação do saque-aniversário é arquétipo 1 em estado puro, só com outro recurso escasso: a parcela anual do FGTS, e quem guarda a verdade dela é a Caixa.
Do ponto de vista de arquitetura, isso é trocar dezenas de integrações ponto a ponto por um hub10. Antes, cada banco precisava de convênio com cada empresa. Agora, todos falam com um lugar só. É uma padronização excelente, com dois custos que costumam ser subestimados.
Primeiro custo: a padaria fecha para contar o caixa
Pense na padaria do bairro que, no fim do mês, baixa a porta por algumas horas para fechar o caixa. Ninguém compra pão nesse intervalo, e isso não é defeito: é o jeito de a padaria saber quanto vendeu.
A Dataprev faz algo parecido em escala nacional. Todo mês acontece a virada de competência11, um processamento em que ela consolida os contratos para que os descontos saiam certos na folha. No consignado CLT, durante esses 3 a 4 dias, averbação, simulação e consulta de margem ficam suspensas. No INSS existe o equivalente, a chamada maciça: o processamento mensal que fecha a folha de todos os beneficiários e recalcula a margem do mês seguinte.
Para o seu sistema, isso significa uma coisa: indisponibilidade planejada é requisito, não incidente. Se o fluxo trata "proposta aceita" e "contrato averbado" como o mesmo estado, a virada de competência aparece no monitoramento como um apagão mensal. Se trata como estados separados, ela vira uma fila que volta a andar sozinha quando o balcão reabre.
Segundo custo: a regra muda por medida provisória
2026 entregou o melhor exemplo possível. Até maio, aposentados e pensionistas do INSS podiam comprometer 45% do benefício: 35% com empréstimos, 5% com cartão de crédito consignado e 5% com cartão consignado de benefício, as rubricas RMC e RCC12. Em 19 de maio, a Medida Provisória13 1.355/2026 reduziu o total para 40% e acabou com a divisão. Virou uma margem única, usada livremente entre empréstimo e cartões.
A MP não foi convertida em lei pelo Congresso. Perdeu a validade em 31 de agosto, a regra anterior voltou, e a Dataprev começou o recálculo na noite de 1º de setembro.
Agora a parte que interessa a quem modela dados. Quem contratou durante a MP, usando a margem única, voltou para uma regra em que empréstimo só cabe em 35%. Parte desses beneficiários passou a aparecer com margem negativa. O contrato era válido quando nasceu e, pela regra de hoje, não caberia. Os dois fatos são verdadeiros ao mesmo tempo.
E a história não parou aí: o TCU, no Acórdão 1.094/2026, suspendeu novas averbações de cartão consignado até nova deliberação. Mais uma mudança de regra vinda de fora, sem aviso ao seu backlog.
Isso só é administrável se o sistema souber responder "qual regra valia na data em que este contrato foi assinado?". A resposta de modelagem é simples: o percentual da margem não é uma constante, é um dado com vigência.
Para quem não programa: o bloco abaixo cria uma tabela em que cada regra fica guardada junto com a data em que começou e a data em que deixou de valer. A última consulta pergunta "qual regra valia no dia em que este contrato foi assinado?".
CREATE TABLE consignable_margin_rule (
id BIGSERIAL PRIMARY KEY,
segment VARCHAR(20) NOT NULL, -- INSS, CLT, SIAPE, BPC
bucket VARCHAR(20) NOT NULL, -- LOAN, RMC, RCC, UNIFIED
max_ratio DECIMAL(5,4) NOT NULL, -- 0.3500 = 35%
valid_from DATE NOT NULL,
valid_to DATE, -- NULL = still in force
legal_basis VARCHAR(120) NOT NULL
);
-- INSS in 2026, as it actually happened
-- (earlier history and the RMC/RCC rows omitted for brevity)
INSERT INTO consignable_margin_rule
(segment, bucket, max_ratio, valid_from, valid_to, legal_basis)
VALUES
('INSS', 'LOAN', 0.3500, '2026-01-01', '2026-05-18', 'Lei 10.820/2003'),
('INSS', 'UNIFIED', 0.4000, '2026-05-19', '2026-08-31', 'MP 1.355/2026'),
('INSS', 'LOAN', 0.3500, '2026-09-01', NULL, 'Lei 10.820/2003 (MP expired)');
-- which rule applied to this contract on the day it was signed?
SELECT bucket, max_ratio, legal_basis
FROM consignable_margin_rule
WHERE segment = 'INSS'
AND :signed_on BETWEEN valid_from AND COALESCE(valid_to, DATE '9999-12-31');Se o percentual estava como constante no código, 2026 custou dois deploys de emergência em quatro meses, e ainda deixou a pergunta sem resposta para os contratos antigos. Se estava numa tabela com vigência, custou dois INSERTs.
Arquétipo 2: muitas contrapartes, muitos dialetos
Quando o mesmo conceito de negócio mora em dezenas de sistemas diferentes, o problema deixa de ser integrar e passa a ser traduzir.
O consignado de servidores públicos é o caso-limite. Os servidores federais têm a folha processada pelo SIAPE14. Estados e municípios têm os próprios sistemas, muitas vezes operados por empresas contratadas, cada um com portal, protocolo, layout de arquivo e regra de reserva diferentes. Para o banco, "reservar margem" é uma coisa só. Do outro lado, são dezenas de jeitos de dizer a mesma coisa.
O financiamento de veículos tem o mesmo desenho. A garantia precisa ser registrada no Detran do estado onde o carro está emplacado e no SNG15, o Sistema Nacional de Gravames operado pela B3, em que a financeira inclui, consulta e dá baixa na restrição. São 27 Detrans, e cada um tem suas particularidades.
O adaptador de tomada
Quem já viajou para outro país com um carregador de celular conhece a solução. Você não troca de carregador a cada fronteira. Você leva um adaptador que encaixa na tomada local e, quando a tensão também muda, um conversor junto, e o seu aparelho continua recebendo sempre a mesma coisa.
Em arquitetura, esse adaptador tem nome: Anti-Corruption Layer16, que já discutimos aqui aplicado à integração entre o Pix e o core bancário. O seu domínio fala uma língua só, e cada contraparte ganha um adaptador que traduz o dialeto dela. E traduzir aqui não é converter formato de arquivo: é converter significado. Quando um estado chega como "em processamento" e outro como "pendente de confirmação", alguém precisa decidir se os dois querem dizer a mesma coisa no seu modelo. Essa decisão é a camada; deixá-la implícita é como importar o vocabulário de 27 órgãos para dentro do seu domínio.
Em linguagem comum: o código abaixo define as quatro perguntas que o banco sabe fazer a qualquer contraparte (reserve, qual o status, desfaça, o que você suporta), sem se importar com o jeito que cada uma responde por dentro. A segunda parte lista as quatro respostas possíveis para a pergunta de status: reservei, recusei, não tenho nada com essa chave, e não consigo responder agora.
public interface CollateralRegistry {
// Ask the counterparty to reserve. The request carries OUR correlation key,
// persisted before this call. A timeout here is not a failure.
ReservationReceipt reserve(ReservationRequest request) throws TimeoutException;
// "Do you have anything under this correlation key?"
// Four answers, never two. "I cannot tell you now" is not the same as "nothing here".
StatusAnswer status(CorrelationKey key);
// Undo: cancel the payroll deduction, lift the lien, release the encumbrance.
// Idempotent, and retried until acknowledged.
void release(ReservationId reservationId);
// Declared, not assumed: is status() authoritative or eventually consistent?
// How long before a NOT_FOUND can be trusted? Maintenance windows?
// Does it support file reconciliation, and how long may a reservation sit unused?
CounterpartyCapabilities capabilities();
}
sealed interface StatusAnswer {
record Reserved(ReservationReceipt receipt, Instant expiresAt) implements StatusAnswer {}
record Rejected(String reason) implements StatusAnswer {}
record NotFound(Instant observedAt) implements StatusAnswer {}
record Unavailable(Instant retryAfter) implements StatusAnswer {}
}O detalhe que costuma faltar é o método status. Toda contraparte responde a um pedido de reserva. Nem toda oferece um jeito de perguntar "você recebeu isto?". Quando não oferece, o adaptador precisa de um plano B, geralmente conciliação17 por arquivo no dia seguinte. E esse plano precisa estar escrito no adaptador, não na cabeça de quem o construiu.
E tem um detalhe mais fino, que é onde eu já vi time competente escorregar depois de acertar tudo o resto: NOT_FOUND não é prova de que nada chegou. Se a contraparte grava de forma assíncrona, se a sua consulta cai numa réplica atrasada, ou se o pedido ainda está numa fila do outro lado, a resposta "não tenho nada com essa chave" é um falso negativo. Reenviar na hora reproduz exatamente a reserva duplicada que você estava tentando evitar, agora com a consciência tranquila de quem consultou antes.
A correção é barata: NOT_FOUND só autoriza reenvio depois de um intervalo mínimo declarado pela contraparte, ou depois de duas consultas consistentes separadas no tempo. É para isso que existe o capabilities(), que na maioria dos sistemas é um método decorativo: ele precisa responder se o status é autoritativo ou eventual, e quanto tempo é preciso esperar antes de acreditar numa ausência.
Vale o mesmo cuidado na forma da resposta. Se "não consigo responder agora" chega ao seu código do mesmo jeito que "não tenho nada", você voltou a ter duas opções onde existem quatro, e o desconhecimento desapareceu do modelo no último metro, justamente na fronteira em que ele nasce. Estado de primeira classe no banco de dados e ausência indistinta no contrato da integração é meio caminho.
Tem outra consequência: monitoramento agregado mente. "99% de sucesso na averbação" pode esconder um estado inteiro fora do ar. Cada adaptador precisa do próprio painel, do próprio SLA18 e do próprio alarme.
Pense comigo
Quantos lugares do seu código conhecem o nome de uma contraparte específica? Se for mais de um, a próxima mudança de layout vira projeto.
Se amanhã um Detran mudar o formato do retorno, quantos serviços você precisa publicar de novo? A resposta certa é um.O seu painel mostra a taxa de erro por contraparte ou só a média de todas? E alguma contraparte do seu catálogo declara, em código, se o status dela é confiável no mesmo instante, ou isso é conhecimento que vive na cabeça de duas pessoas?
Arquétipo 3: a garantia que só existe quando o mundo sabe
Em algumas garantias, o registro não é uma burocracia que vem depois do contrato. É o que faz a garantia valer.
Voltemos ao carro. Na alienação fiduciária19, o banco é o dono do veículo até a última parcela e o cliente é quem usa. Só que isso só vale perante terceiros depois que o gravame20 está registrado no órgão de trânsito. Sem o registro, alguém pode comprar o carro de boa-fé, ou outro banco pode aceitá-lo como garantia de um segundo empréstimo, e o seu contrato não impede nenhuma das duas coisas.
A analogia é o ingresso de show com QR code. O papel na sua mão não prova nada. O que prova é a catraca validar o código contra a base do organizador e barrar a segunda pessoa que aparecer com a mesma imagem.
Três catracas, três velocidades
Veículo. Registro no Detran e no SNG, com resposta eletrônica em segundos ou minutos.
Imóvel. Registro na matrícula, no Cartório de Registro de Imóveis. Desde a Lei 14.382/2022, os cartórios estão interligados pelo SERP21, mas o prazo continua em dias: 10 dias úteis para títulos de alienação fiduciária de imóveis, e 5 dias úteis quando o título eletrônico estruturado chega pelo sistema.
Recebíveis22. Registradoras23 autorizadas pelo Banco Central, como CERC, TAG e Núclea, registram as agendas de cartão e as duplicatas24. O arcabouço começou com a Resolução CMN 4.734 e existe para dar publicidade e impedir que o mesmo recebível seja onerado25 duas vezes.
A mesma operação de reserva vai de segundos a semanas conforme o bem. Um sistema que trata as três com o mesmo timeout de 30 segundos não está simplificando; está errando em duas delas.
Mas a conclusão arquitetural importa mais que a escolha do número. Acima de alguns minutos, reserva deixa de ser chamada e passa a ser processo. Alguém precisa guardar o pedido, acordar sozinho depois, consultar ou receber o callback, e sobreviver a deploy, a reinício de serviço e a fim de semana. Timeout é a ferramenta errada para um prazo de 10 dias úteis: ali não existe "esperar a resposta", existe um protocolo em aberto, com dono, prazo e alarme no vencimento. A carteira monitorada do cartório não é zelo operacional de backoffice; é a consequência de ter modelado a reserva como processo de longa duração em vez de chamada demorada. Quem não faz essa troca acaba com um thread pool inteiro esperando um cartório, ou com um job que reenvia o mesmo título todo dia porque nunca soube que o primeiro envio continua válido.
A registradora é idempotência entre concorrentes
Este é o ponto que mais me interessa como engenheiro. No artigo de modelagem, defendi que a idempotência26 mora no schema: uma restrição UNIQUE impede que o mesmo lançamento entre duas vezes. Funciona muito bem dentro da sua casa.
Agora pense no lojista que vende R$ 100 mil no cartão por mês e tenta antecipar a mesma agenda com três bancos na mesma tarde. Nenhum deles enxerga o banco de dados do outro, e não existe UNIQUE possível entre instituições concorrentes.
A registradora é esse UNIQUE. É uma chave única compartilhada pelo mercado, mantida por um terceiro em quem todos precisam confiar. Quando o segundo banco tenta registrar a oneração de um recebível que o primeiro já registrou, a registradora recusa, do mesmo jeito que o seu banco recusa a segunda linha com a mesma chave.
Traduzindo o bloco abaixo: a primeira parte é a regra que o banco consegue impor dentro de casa ("esta chave só pode existir uma vez"). A segunda mostra a mesma regra oferecida como serviço pela registradora, que responde "já está comprometido" para quem chegar depois.
-- inside your walls: the database enforces one row per fact
ALTER TABLE ledger_entry
ADD CONSTRAINT uk_idempotency UNIQUE (idempotency_key);
-- across the market nobody can write that constraint,
-- so a registry enforces it as a service:
-- POST /encumbrances { receivable_id, creditor_id }
-- -> 409 ALREADY_ENCUMBEREDAgora preciso estragar um pouco a minha própria analogia, senão quem trabalha com recebível para de confiar no resto do artigo. Esse UNIQUE não é um só. Existem várias registradoras autorizadas, e a unicidade é forte dentro de cada uma e historicamente frágil entre elas. O mesmo recebível aparecendo em duas registradoras diferentes é um problema conhecido do mercado, e a interoperabilidade entre elas vem sendo construída por regulação e convênio, não por um índice único que qualquer um possa consultar.
Então a imagem certa não é uma tabela com uma restrição UNIQUE. É um índice particionado em que as partições ainda estão aprendendo a conversar. E isso muda o que o seu sistema precisa fazer: consultar uma registradora não é consultar o mercado, e "não encontrei oneração" quer dizer "não encontrei onde eu olhei". Quem antecipa recebível tratando ausência de registro como ausência de ônus está confiando numa garantia de unicidade que não cobre o universo, o que é uma forma caríssima de aprender a diferença entre chave única e chave única por partição.
Com isso, o registro deixa de ser detalhe de backoffice e vira fato de primeira classe no seu modelo. Ele tem protocolo externo, a data em que passou a valer e a data em que você ficou sabendo: os três tempos que vimos no artigo de modelagem. Quando alguém perguntar daqui a três anos "essa garantia estava registrada no dia do inadimplemento?", a resposta precisa ser um SELECT.
Arquétipo 4: quando não há nada para reservar
No crédito pessoal, no cheque especial e no rotativo do cartão, não há garantia para reservar em lugar nenhum. O problema inteiro migra para a decisão.
Aqui a integração muda de natureza. Você não fala com quem guarda uma garantia; fala com quem guarda informação: o SCR27 do Banco Central, os bureaus de crédito e, cada vez mais, o Open Finance28. Nenhum deles reserva nada. Eles só reduzem a incerteza, e o que sobra de incerteza vira preço.
Os números mostram o tamanho disso: em abril de 2026, a taxa média do consignado INSS foi de 23,9% ao ano, contra 63% ao ano na média do crédito pessoal não consignado para pessoa física, segundo as séries de taxas de juros do Banco Central. Vale dizer de qual recorte se trata, porque ele muda muito: cheque especial e rotativo do cartão correm em outra ordem de grandeza e puxariam esse número para muito acima de 63%.
E aqui eu preciso ser honesto com o número, porque o jeito mais fácil de usá-lo é circular. A taxa do consignado INSS não é só preço de risco: ela tem teto, fixado pelo Conselho Nacional de Previdência Social e revisado de tempo em tempo. Não foi o mercado que chegou a 23,9% sozinho, olhando para a perda esperada.
O argumento não cai com isso; ele fica mais preciso. O teto não explica a taxa, ele é o que a integração torna sustentável. Em qualquer modalidade sem reserva na fonte, um teto nessa altura secaria a oferta, porque ninguém empresta a 24% ao ano contra risco de crédito pessoal puro. No consignado ele funciona porque a reserva na folha derruba a perda esperada a ponto de 24% ainda cobrir funding, operação e a inadimplência que sobra, que é basicamente morte do beneficiário e bloqueio de benefício. A integração não define o preço. Ela define qual preço é possível sem matar o produto.
No extremo em que não há nada para reservar em lugar nenhum, a taxa de juros é, em boa parte, o preço da integração que não existe.
Lembra das duas perguntas do começo, "vai me pagar?" e "se não pagar, o que eu faço?"? Neste arquétipo só existe a primeira. É o conhecido dos R$ 500 do começo do artigo, agora na escala de um sistema financeiro: sem o celular em cima da mesa, você empresta menos, cobra mais, ou não empresta. Consignado é o mesmo empréstimo feito por quem já tem a mão na folha de pagamento.
O cartão de crédito é um caso curioso, porque mistura os dois mundos. A autorização é uma microrreserva: a bandeira reserva limite em milissegundos. Depois vêm a captura, a liquidação em D+N29 e o faturamento, cada um com contraparte e prazo próprios. É a mesma forma, em miniatura, repetida milhões de vezes por dia.
Uma lição de modelagem fica deste arquétipo: se a decisão substitui a garantia, a decisão é um fato. Ela precisa ser guardada junto com o que a produziu, ou seja, quais dados foram consultados, quando, e qual versão do modelo decidiu. Esse tema merece um artigo só para ele.
E quando a contraparte não responde?
Cada arquétipo pede uma resposta diferente para o timeout, e escolher a resposta errada produz os dois incidentes da dona Lurdes.
Contraparte central. Consulte o status pela sua chave de correlação. Se ela estiver em janela planejada, estacione o contrato e retome quando reabrir.
Contrapartes fragmentadas. A mesma regra, mas cada adaptador precisa declarar se oferece consulta de status e se a resposta dela é autoritativa na hora. As que não oferecem entram em conciliação por arquivo.
Registro. Nunca considere a garantia constituída sem o protocolo de volta. Operações pendentes de registro entram numa carteira monitorada, com prazo e responsável.
Sem reserva. O risco do timeout está na liberação do dinheiro. O desembolso precisa ser idempotente, e o E2E ID30 do Pix é uma chave natural pronta para isso.
E, nos quatro, a mesma regra de saída, que é a metade esquecida de todas as listas desse tipo: proposta que não vira contrato devolve o que reservou, com protocolo de volta.
Em código, a regra geral cabe em poucas linhas.
Para quem não programa: quando a resposta não chega, o contrato vai para o estado "não sei" e o sistema agenda uma consulta. Na consulta, se a contraparte diz que reservou, segue; se diz que recusou, encerra; se diz que não consegue responder agora, espera e pergunta de novo. E se diz que nunca viu o pedido, ele só reenvia depois do tempo mínimo em que essa resposta pode ser levada a sério. Vencido o teto de tentativas, um humano assume. O último trecho é o caminho inverso, o que quase ninguém escreve: proposta que morre devolve a margem.
void requestReservation(Contract contract) {
contract.moveTo(RESERVATION_REQUESTED); // correlation key already persisted
try {
ReservationReceipt receipt = registry.reserve(contract.toReservationRequest());
contract.confirmReservation(receipt); // carries the expiry date. It is not forever
} catch (TimeoutException e) {
contract.moveTo(RESERVATION_UNKNOWN); // never retry blindly
resolver.scheduleCheck(contract.id(), Duration.ofMinutes(2));
}
}
void resolveUnknown(Contract contract) {
if (contract.unknownFor().compareTo(caps.unknownCeiling()) > 0) {
contract.moveTo(MANUAL_REVIEW); // stop asking. A human owns it now
return;
}
switch (registry.status(contract.correlationKey())) {
case Reserved r -> contract.confirmReservation(r.receipt());
case Rejected x -> contract.moveTo(RESERVATION_REJECTED);
case Unavailable u -> resolver.scheduleCheck(contract.id(), u.retryAfter());
// NOT_FOUND is not proof that nothing arrived. Trust it only after the
// settling window the counterparty itself declares, or we recreate
// the very duplicate we were trying to avoid.
case NotFound n -> {
if (caps.notFoundIsConclusive(n.observedAt())) requestReservation(contract);
else resolver.scheduleCheck(contract.id(), backoffFor(contract));
}
}
}
// The mirror image, and the one almost nobody writes:
// a proposal that dies gives the margin back.
void abandon(Contract contract, Reason reason) {
if (contract.holdsReservation()) {
registry.release(contract.reservationId()); // idempotent, retried until acked
contract.moveTo(RESERVATION_RELEASED);
}
contract.close(reason);
}Por baixo de tudo, uma rede de segurança: conciliação diária entre o que você acha que reservou e o que a contraparte diz que foi reservado. E a conciliação tem duas direções, não uma: reserva que você acha que tem e a contraparte não reconhece, e reserva que a contraparte ainda segura para uma proposta que na sua base já morreu. Divergência encontrada ali é incidente, com dono e prazo, e nunca um ajuste silencioso.
Pense comigo
Quando foi a última vez que alguém do time leu o relatório de conciliação? Relatório que ninguém lê é só um arquivo ocupando espaço.
Se a contraparte ficar fora do ar por quatro dias, o que acontece com as propostas aceitas nesse período? Quem avisa o cliente?
Qual é o maior valor que já saiu do seu sistema com a reserva em estado desconhecido? Se ninguém sabe responder, esse é o primeiro painel a construir. O segundo é mais barato e dói mais: quantas margens o seu sistema está segurando agora para propostas que nunca viraram contrato?
O contrato de sexta-feira
O contrato da dona Lurdes não quebrou por causa da Dataprev. A Dataprev fez o que qualquer sistema faz às vezes: demorou numa sexta-feira à tarde. Ele quebrou porque o modelo não tinha lugar para "eu pedi e ainda não sei".
Consignado, carro, imóvel, recebível, crédito pessoal. O produto muda de nome, de taxa e de prazo. A pergunta de engenharia é sempre a mesma: onde mora a verdade da garantia, e o que o seu sistema faz enquanto ela não responde. E o arquétipo 4 é a exceção que prova a regra: quando não existe nada para reservar em lugar nenhum, alguém paga a diferença, em taxa, em limite ou em porta fechada. Reservar num banco de dados que não é seu não é um detalhe de integração. É o que separa 24% ao ano de 63%.
Fica a pergunta para os comentários: na sua instituição, qual contraparte mais te acorda de madrugada? Dataprev, Detran, cartório ou registradora? E vocês têm um estado para "não sei"? E um para "devolvi"?
Fontes
Correio da Manhã: fim de MP faz margem do consignado do INSS voltar a 45%
Contábeis: consignado do INSS, margem volta a 45% após fim de MP
Bevi: o que muda na margem do INSS e do SIAPE com o fim da MP 1.355
Seu Crédito Digital: consignado INSS e cartões bloqueados (Acórdão TCU 1.094/2026)
Celcoin: regras de APIs para crédito consignado privado em 2026
Fórum de Desenvolvimento Imobiliário: prazos na Lei 14.382/2022 (nota técnica)
Planalto: Medida Provisória 1.355/2026, texto original (fonte primária)
TCU: Acórdão 1.094/2026, íntegra (fonte primária)
Planalto: Lei 15.179/2025, Crédito do Trabalhador (fonte primária)
Banco Central: séries de taxas médias de juros por modalidade de crédito
Conselho Nacional de Previdência Social: resoluções de teto de juros do consignado do INSS
Dados regulatórios verificados em 30 de setembro de 2026.
Averbação: registro oficial, feito por quem administra a folha ou o benefício, de que um pedaço daquela renda já tem dono. É o carimbo que transforma uma promessa de desconto em desconto garantido.
Dataprev: empresa pública de tecnologia que processa os dados da Previdência. É por ela que passam a consulta de margem e a averbação do consignado. Desde a Lei 15.179/2025, também opera a plataforma do consignado dos trabalhadores com carteira assinada.
Juros: o preço de usar o dinheiro de outra pessoa por um tempo. Como um aluguel, só que do dinheiro em vez de um imóvel.
Garantia: algo de valor que fica comprometido com o credor e pode ser usado para cobrir a dívida se ela não for paga.
Home equity: empréstimo em que a pessoa dá o imóvel que já tem como garantia, para conseguir uma taxa menor. O dinheiro pode ser usado para qualquer fim.
Rotativo do cartão: o crédito que entra automaticamente quando a fatura não é paga inteira. O valor que ficou para trás passa a ser financiado, com uma das taxas mais altas do mercado.
Contraparte: o outro lado de uma operação. Neste artigo, quem guarda o registro oficial da garantia, e não o cliente.
Máquina de estados: um jeito de modelar algo que só pode estar em um estado por vez, com regras explícitas sobre de qual estado se pode ir para qual. Como um semáforo, que nunca pula do verde direto para o vermelho.
eSocial: sistema do governo em que as empresas informam folha de pagamento, vínculos e obrigações trabalhistas. É de lá que sai a informação de quanto cada trabalhador ganha.
Hub: ponto central por onde todas as conexões passam, como um aeroporto de conexão. Simplifica as rotas e concentra os atrasos.
Competência: o mês de referência de uma folha ou de um fato contábil. A virada de competência é a passagem de um mês de referência para o seguinte.
RMC e RCC: Reserva de Margem Consignável (cartão de crédito consignado) e Reserva de Cartão Consignado de benefício. São fatias da margem separadas por lei para os dois tipos de cartão.
Medida provisória (MP): norma com força de lei editada pela Presidência. Vale na hora, mas precisa ser aprovada pelo Congresso em até 120 dias. Se não for, caduca: perde a validade e a regra anterior volta a valer.
SIAPE: sistema que processa a folha de pagamento dos servidores públicos federais.
SNG (Sistema Nacional de Gravames): base operada pela B3 em que financeiras registram, consultam e dão baixa nas restrições sobre veículos dados em garantia.
Anti-Corruption Layer (camada anticorrupção): padrão do Domain-Driven Design em que uma camada traduz o modelo de um sistema externo para o seu, para que os conceitos do outro lado não contaminem o seu domínio.
Conciliação: comparar dois registros do mesmo fato, feitos por lados diferentes, para encontrar divergências. É o bater do caixa dos sistemas.
SLA (Service Level Agreement): o nível de serviço combinado, como disponibilidade mínima ou tempo máximo de resposta.
Alienação fiduciária: o devedor transfere a propriedade do bem ao credor como garantia e a recebe de volta quando quita a dívida. Você dirige o carro, mas ele é do banco até a última parcela.
Gravame: restrição registrada sobre um bem, avisando que ele garante uma dívida. Enquanto existir, o bem não pode ser vendido livremente.
SERP (Sistema Eletrônico dos Registros Públicos): criado pela Lei 14.382/2022 para interligar os cartórios pela internet. Na parte de imóveis, o operador é o ONR.
Recebível: dinheiro que alguém tem a receber no futuro. O exemplo clássico são as vendas no cartão, que o lojista só recebe dias ou semanas depois.
Registradora: entidade autorizada pelo Banco Central a registrar ativos financeiros, dando publicidade a quem é o dono de cada um e se ele já está comprometido.
Duplicata: título que representa uma venda a prazo entre empresas. Hoje ela é escritural, ou seja, existe apenas como registro eletrônico.
Onerar: comprometer um ativo como garantia. Um recebível onerado já está prometido a um credor e não pode ser prometido de novo.
Idempotência: propriedade de uma operação que, repetida várias vezes, produz o mesmo efeito de uma vez só. Apertar o botão do elevador cinco vezes não chama cinco elevadores.
SCR (Sistema de Informações de Créditos): base do Banco Central com as operações de crédito de cada pessoa e empresa no sistema financeiro.
Open Finance: sistema regulado pelo Banco Central em que o cliente autoriza uma instituição a acessar os dados dele em outra.
D+N: prazo contado em dias úteis a partir da data da operação. D+2 significa dois dias úteis depois.
E2E ID (End-to-End ID): identificador único que acompanha cada Pix de ponta a ponta, do pagador ao recebedor.