Agora imagine um sistema capaz de seguir o rastro desse dinheiro, bloquear valores ao longo do caminho e estruturar a devolução de forma coordenada entre as instituições financeiras. É exatamente essa evolução que a Resolução BCB nº 493/2025 trouxe ao Regulamento do Pix: o fortalecimento do Mecanismo Especial de Devolução e a criação da funcionalidade de Recuperação de Valores, o chamado MED 2.0.

O que realmente mudou com o MED 2.0?

Você já imaginou descobrir que foi vítima de um golpe e, mesmo sabendo que o valor já passou por várias contas diferentes, ainda assim existir um mecanismo capaz de mapear esse percurso quase como quem recompõe as peças de um quebra-cabeça?

O Mecanismo Especial de Devolução já existia como ferramenta para tratar fraudes e falhas operacionais. O problema é que sua atuação era limitada: o bloqueio se concentrava na primeira conta recebedora. Se o valor fosse rapidamente transferido para contas subsequentes, a recuperação tornava-se improvável.

O MED 2.0 altera essa lógica. A nova regulamentação amplia as funcionalidades do DICT, que passa a ser o canal estruturado para:

• Solicitação de devolução;
• Rastreamento de transações;
• Bloqueio em múltiplas etapas;
• Devoluções parciais ou sucessivas.

Funciona assim: identificada uma suspeita pelo banco do pagador, a comunicação percorre a rede de instituições participantes. Se os recursos já tiverem sido transferidos para outra instituição, e depois para mais uma, o rastreamento não se encerra. Ele acompanha o fluxo, conectando as operações subsequentes e permitindo a adoção de medidas também nessas etapas posteriores.

Imagine, por exemplo, um valor que sai da conta da vítima, é enviado para uma conta “laranja”, depois dividido em três partes e redistribuído para instituições diferentes. No modelo anterior, a chance de recuperação diminuía drasticamente a cada nova transferência. Agora, a análise considera esse encadeamento de operações, ampliando o alcance das notificações e dos bloqueios.

Golpes digitais dependem de dispersão rápida para criar camadas de distância entre o autor do ilícito e o dinheiro. Quando o sistema passa a reconstituir o trajeto das transações e permite bloqueios também nas etapas seguintes, a estratégia de fragmentação perde eficiência. O tempo deixa de ser um aliado automático do fraudador.

Em vez de uma corrida contra o relógio em que o dinheiro “some” após alguns cliques, o que se tem é uma estrutura capaz de acompanhar o percurso financeiro, reduzir a liquidez nas contas de passagem e aumentar a probabilidade de recomposição dos valores.

Bloqueio imediato deixa de ser opção e vira obrigação

Um dos pontos mais relevantes da atualização está no rito de bloqueio. Nos termos do art. 41-D, §1º, o PSP recebedor deve realizar o bloqueio imediatamente após o recebimento da notificação de infração vinculada à suspeita de fraude.  A palavra-chave aqui é imediatidade.

Isso significa que, uma vez acionado o mecanismo pelo PSP do pagador, após reclamação da vítima e havendo fundada suspeita, o bloqueio não pode ser postergado para análise posterior. Ele ocorre primeiro; a apuração vem na sequência. Essa inversão operacional aumenta significativamente a eficácia do mecanismo.

Recuperação de Valores: rastreabilidade em cadeia

Com o MED 2.0, a utilização da funcionalidade de Recuperação de Valores implica a criação automática de notificações de infração para todas as transações selecionadas, seja por algoritmo interno do DICT, seja por priorização do PSP do pagador.

Além disso, o art. 78-J introduz uma inovação relevante: permite múltiplas solicitações de devolução para uma mesma transação no contexto da recuperação de valores.

Isso viabiliza bloqueios sucessivos e devoluções parciais, conforme os recursos são localizados ao longo da cadeia de transferências. Não se trata apenas de bloquear. Trata-se de reconstruir o fluxo financeiro.

A nova posição do PSP recebedor

O fortalecimento do mecanismo vem acompanhado de maior responsabilidade.

A Banco Central do Brasil ampliou expressamente os deveres do PSP recebedor, que passa a:

• Realizar bloqueio imediato dos valores;
• Debitar os recursos quando confirmada a fraude;
• Efetuar a devolução ao pagador em seu próprio nome;
• Observar os prazos e procedimentos que serão detalhados no Manual Operacional do DICT.

Essa alteração não é meramente operacional. Ela produz efeitos jurídicos e contratuais relevantes, exigindo revisão de processos internos, adequação tecnológica e reavaliação da matriz de riscos.

Impactos regulatórios e operacionais

Diante das mudanças, torna-se recomendável:

• Integração tecnológica plena ao DICT;
• Automatização dos fluxos de bloqueio ao receber Notificação de Infração;
• Revisão de políticas internas e contratos;
• Capacitação das equipes técnicas e jurídicas;
• Monitoramento contínuo de riscos e conformidade regulatória.

O mecanismo deixa de ser um recurso residual e passa a ocupar posição estratégica na estrutura antifraude das instituições.

Como pedir o reembolso no MED 2.0? 

O tempo é o fator mais importante para o sucesso do bloqueio. Se você perceber que caiu em uma fraude, siga este passo a passo imediatamente:

1. Conteste no Aplicativo: Acesse o extrato do seu banco, localize a transação suspeita do Pix e clique no botão de “contestar” ou “reportar fraude”. O alerta chegará ao banco recebedor em até 30 minutos.
2. Atenção ao Prazo: Com a nova regra, a vítima tem até 80 dias para contestar uma operação suspeita pelo app.
3. Faça um Boletim de Ocorrência (B.O.): Registre o crime na delegacia virtual do seu estado. O documento é fundamental para comprovar a fraude durante a análise do banco.
4. Aguarde a análise e a devolução: Após o bloqueio preventivo, as instituições analisam o caso.

O que isso representa para o ecossistema do Pix?

O Pix permanece sendo, em regra, instantâneo e irreversível. O MED 2.0 não transforma o sistema em um meio de pagamento revogável por arrependimento ou erro de digitação. Ele continua restrito a hipóteses de fraude, coação ou falha operacional. Mas o que muda é significativo.

Se antes o dinheiro podia se dissipar em segundos por meio de transferências sucessivas, agora existe um arcabouço regulatório que permite rastrear, bloquear e estruturar a devolução com maior coordenação e previsibilidade.

O MED 2.0 não elimina o risco de fraude, nenhum sistema elimina, mas ele eleva o custo do crime digital e reduz o espaço para pulverização impune de valores.

E talvez a reflexão final seja esta: em um sistema que movimenta bilhões diariamente e integra praticamente toda a população bancarizada do país, você já imaginou o impacto de transformar segundos, que antes favoreciam o fraudador, em segundos que agora favorecem o bloqueio?

Nesse cenário de constante evolução regulatória e tecnológica, contar com parceiros preparados faz toda a diferença. A Delfinance acompanha de perto as transformações do ecossistema financeiro e atua para oferecer soluções seguras, eficientes e alinhadas às exigências do mercado digital.

Se você busca mais segurança nas operações financeiras, inovação tecnológica e uma instituição comprometida com conformidade, prevenção a fraudes e excelência operacional, conheça a Delfinance e descubra como podemos apoiar você e o seu negócio na construção de uma experiência financeira mais moderna, confiável e inteligente.

Entre em contato conosco e se torne um cliente Delfinance.

Mas a verdade é que entender como esse tributo funciona é a chave para tomar decisões estratégicas que impactam diretamente a saúde financeira da empresa, não só para cumprir as obrigações fiscais.

Em relação aos prazos, é importante reforçar: empresas optantes pelo Simples Nacional e os Microempreendedores Individuais (MEIs) devem realizar suas declarações até 31 de maio, enquanto as empresas enquadradas no Lucro Presumido e no Lucro Real devem cumprir suas obrigações até o último dia útil de julho (portanto, 31 de julho de 2026) por meio da Escrituração Contábil Fiscal (ECF).

Mais do que atender prazos, este é o momento ideal para revisar conceitos, entender o funcionamento do IRPJ e identificar oportunidades de otimização tributária.

O que é o IRPJ e como ele funciona na prática

O IRPJ é o imposto que as empresas pagam sobre o dinheiro que realmente ganham, já queele incide sobre o lucro, ou seja, sobre o que sobra depois de pagar todas as despesas.

Mas aqui existe um ponto importante: o imposto não depende só do quanto a empresa fatura, mas também de como esse resultado é calculado. Isso porque há regras específicas que permitem ajustes no lucro, como incluir ou excluir valores.

Na prática, isso significa que duas empresas com o mesmo faturamento podem pagar valores bem diferentes de IRPJ, tudo a depender do regime tributário escolhido, dos custos da empresa e da forma como a contabilidade está organizada.

Quem precisa pagar o IRPJ

De forma geral, toda empresa com CNPJ ativo no Brasil está sujeita ao IRPJ, independentemente do porte ou do setor de atuação, o que inclui grandes corporações até pequenos negócios estruturados como pessoa jurídica.

Mesmo empresas que não tiveram faturamento no período ou que estão sem atividade (as chamadas empresas inativas) continuam tendo obrigações com a Receita Federal. Ou seja, ainda precisam declarar sua situação informando que não houve movimentação.

Já nos casos de empresas efetivamente encerradas, com baixa formal do CNPJ, a obrigação deixa de existir a partir da finalização do processo de encerramento, mas até esse momento todas as declarações devem estar em dia.

Além disso, temos algumas particularidades relevantes. O Microempreendedor Individual (MEI), por exemplo, não recolhe o IRPJ separadamente, pois o tributo já está incluído no valor mensal pago via DAS. Ainda assim, ele continua obrigado a entregar a declaração anual (DASN-SIMEI), mesmo que não tenha tido faturamento no período.

Além disso, entidades sem fins lucrativos podem ser isentas, desde que cumpram requisitos legais específicos, como a não distribuição de lucros. Mesmo nesses casos, a obrigação de prestar informações à Receita Federal permanece.

Regime tributário: o fator que mais impacta o IRPJ

Se existe um ponto que define quanto uma empresa paga de IRPJ, é o regime tributário. Ele determina como o imposto será calculado e qual será a base sobre a qual as alíquotas serão aplicadas. Fazendo um resumo, é basicamente isso:

No Lucro Presumido, a Receita Federal define previamente uma margem de lucro, que varia conforme a atividade da empresa. Já no Lucro Real, o imposto incide sobre o lucro efetivamente apurado, considerando receitas, custos e despesas.

Essa diferença pode gerar impactos significativos. Empresas com margens reduzidas podem pagar mais imposto no Lucro Presumido do que pagariam no Lucro Real, enquanto empresas com margens elevadas podem se beneficiar da simplicidade do regime presumido. Por isso, a escolha do regime não deve ser feita de forma automática, ela precisa ser analisada com base na realidade do negócio.

Como o IRPJ é calculado

De forma geral, o cálculo do IRPJ segue uma lógica padrão: aplica-se uma alíquota de 15% sobre a base de cálculo, com um adicional de 10% sobre o lucro que exceder R$ 20 mil por mês ou R$ 60 mil por trimestre.

O ponto mais importante, no entanto, não é a alíquota em si, mas a definição da base de cálculo. É ela que determina quanto efetivamente será pago.

No Lucro Presumido, essa base é obtida a partir de um percentual fixo aplicado sobre o faturamento, enquanto no Lucro Real, ela corresponde ao lucro efetivo da empresa, ajustado por regras fiscais.

Exemplo prático: entendendo o impacto no dia a dia

Para tornar isso mais concreto, imagine uma empresa prestadora de serviços no Lucro Presumido com faturamento trimestral de R$ 300.000. Nesse caso, aplica-se o percentual de presunção de 32%, resultando em uma base de cálculo de R$ 96.000.

Sobre esse valor, incide o IRPJ de 15%, totalizando R$ 14.400. Como o lucro presumido ultrapassa R$ 60.000 no trimestre, também há o adicional de 10% sobre o excedente de R$ 36.000, o que gera mais R$ 3.600. O total de IRPJ devido no período, portanto, é de R$ 18.000.

Agora, imagine que o lucro real da empresa tenha sido de apenas R$ 50.000. Ainda assim, o imposto será calculado sobre R$ 96.000. Esse exemplo ilustra de forma clara como o regime tributário pode impactar diretamente o valor pago.

Como declarar o IRPJ

A declaração do IRPJ vai muito além de um simples preenchimento de formulário: ela é a consolidação de todas as informações financeiras, contábeis e fiscais da empresa ao longo do ano.

Para empresas no Lucro Presumido e no Lucro Real, essa declaração é feita por meio da Escrituração Contábil Fiscal (ECF), transmitida pelo Sistema Público de Escrituração Digital (SPED): Sistema Público de Escrituração Digital (SPED)

O processo envolve a organização prévia de dados, o preenchimento detalhado das informações, a validação pelo sistema, a assinatura digital e a transmissão à Receita Federal. Trata-se de uma obrigação técnica, que exige consistência entre todos os registros da empresa.

Para MEIs e empresas do Simples Nacional, a declaração ocorre por meio da DASN-SIMEI e da DEFIS, respectivamente, com processos mais simplificados, mas igualmente obrigatórios.

Documentos e organização: a base de tudo

A qualidade da declaração depende diretamente da organização da empresa ao longo do ano. Entre os principais documentos necessários estão o balanço patrimonial, a demonstração de resultados (DRE), notas fiscais, extratos bancários, relatórios de despesas e comprovantes de pagamento de tributos.

Essas informações não são apenas utilizadas para preencher a declaração. Elas são cruzadas pela Receita Federal com outras obrigações acessórias, o que exige total coerência. Pequenas inconsistências podem gerar questionamentos e, em alguns casos, autuações.

Prazos e rotina do IRPJ

Diferente do que pode parecer, o IRPJ não é um evento isolado no ano, mas sim um processo contínuo. Enquanto o pagamento pode ocorrer mensalmente ou trimestralmente, dependendo do regime, a declaração anual funciona como o fechamento dessas informações.

A dinâmica reforça a importância de acompanhar os resultados ao longo do ano, e não apenas no momento da entrega da declaração.

O que muda em 2026

A principal mudança relevante para 2026 está no Lucro Presumido. Empresas com faturamento anual superior a R$ 5 milhões passarão a ter um acréscimo de 10% nos percentuais de presunção sobre a parcela excedente.

Na prática, isso aumenta a base de cálculo e, consequentemente, o valor do imposto devido. Essa alteração exige atenção, especialmente para empresas em crescimento, que podem precisar reavaliar seu regime tributário.

Revisão final antes de declarar

Antes de concluir a apuração do IRPJ, é importante verificar se o regime tributário ainda é adequado, se a base de cálculo foi corretamente apurada, se o adicional de 10% foi considerado e se há consistência entre os dados contábeis e fiscais.

Esse cuidado reduz significativamente o risco de erros e garante maior segurança no cumprimento das obrigações.

O IRPJ não deve ser tratado apenas como uma obrigação anual, mas como parte da gestão financeira da empresa. Ele reflete decisões, estrutura e organização.

Empresas que compreendem esse cenário conseguem reduzir riscos, melhorar sua previsibilidade e tomar decisões mais estratégicas. Já aquelas que tratam o tema de forma reativa tendem a lidar com custos maiores e menos controle.

Nesse contexto, a Delfinance atua como parceira estratégica, traduzindo a complexidade tributária em clareza e apoiando empresas na construção de uma gestão financeira mais eficiente, segura e alinhada ao crescimento do negócio.

Entre em contato conosco e se torne um cliente Delfinance.

Você abre o aplicativo do banco, digita a chave, confere o valor e confirma. Em poucos segundos, o dinheiro sai da sua conta e aparece na conta de outra pessoa. Simples, rápido, quase automático. Tão instantâneo, na verdade, que raramente paramos para pensar no que acontece nesse pequeno intervalo entre o “confirmar” e o “concluído”.

A sensação é de que o dinheiro simplesmente atravessa de uma conta para outra, como se tudo acontecesse dentro da própria interface bancária. Mas essa rapidez só existe porque há uma estrutura inteira funcionando nos bastidores, coordenando cada etapa com precisão.

E se você pudesse “ver” esse caminho?

Ao longo deste artigo, o convite é justamente esse: ir além da tela do seu dispositivo e entender o que realmente acontece por trás de cada transferência, explorando a engrenagem que permite que o Pix funcione em segundos, com segurança e consistência.

O que garante que o Pix aconteça em segundos?

Por trás de cada Pix existe uma infraestrutura operada pelo Banco Central do Brasil (BCB) chamada Sistema de Pagamentos Instantâneos (SPI).

É esse sistema que garante que o dinheiro não apenas “pareça” transferido, mas que, de fato, mude de titularidade entre instituições financeiras naquele mesmo instante.

Aqui está um detalhe importante: uma transferência não se resume a uma autorização. Ela só se completa quando ocorre a chamada liquidação financeira, que é o momento em que o valor deixa oficialmente uma instituição e passa a pertencer a outra.

No Pix, essa liquidação acontece em tempo real. É exatamente isso que sustenta aquela sensação de instantaneidade que você já tomou como garantida.

Pix e SPI são a mesma coisa?

Não, o Pix é o que você vê. É o arranjo de pagamento: as regras, a chave, o QR Code, a experiência no aplicativo. É tudo aquilo com que você interage.

O SPI é o que faz tudo funcionar. Ele não aparece na tela, não interage com o usuário, mas é responsável pela etapa mais crítica de toda a operação: a liquidação entre as instituições.

Uma analogia simples: o Pix é o idioma que todos falam para fazer um pagamento. O SPI é o sistema que garante que a mensagem chegou e que o dinheiro foi, de fato, entregue.

O caminho invisível do seu dinheiro

Agora imagine novamente aquela transferência que você fez em poucos segundos.

Enquanto você confirma a operação, a sua instituição envia uma ordem ao SPI. Nesse momento, o sistema realiza um movimento simultâneo: debita o valor de uma conta institucional da sua instituição e credita esse mesmo valor na conta institucional da instituição que vai receber.

Só depois dessa etapa é que o valor aparece para o destinatário.

Percebe a diferença? O dinheiro não “vai direto” de uma conta para outra. Antes disso, ele passa por uma liquidação entre instituições.

A engrenagem invisível: o que é a Conta PI

Para que todo esse processo funcione, existe um elemento quase desconhecido do público geral, mas absolutamente essencial para o sistema: a Conta PI.

Essa conta não é sua. Não é do seu destinatário. Ela pertence às instituições financeiras e é mantida dentro do próprio Banco Central. Sua única função é registrar as movimentações entre essas instituições a cada Pix realizado.

Ou seja, quando você transfere um valor, não é a sua conta que conversa diretamente com a conta de outra pessoa. São as instituições que fazem esse ajuste entre si e isso acontece dentro do SPI, via Conta PI, em tempo real.

Quem realmente participa desse sistema

Nem todas as instituições operam da mesma forma dentro do sistema.

Algumas possuem acesso direto ao SPI e realizam a liquidação por conta própria. Outras dependem de uma instituição participante para executar essa etapa.

Na prática, isso significa que uma instituição pode oferecer Pix ao cliente mesmo sem estar conectada diretamente ao sistema, desde que exista uma estrutura por trás garantindo essa liquidação.

Para o consumidor, essa diferença não é visível. Mas, para o funcionamento do sistema, ela é essencial.

O que mudou com a Resolução BCB nº 554/2026

A Resolução 554 representa uma evolução clara do modelo regulatório: o Banco Central transferiu mais protagonismo para as próprias instituições na gestão de riscos. As principais mudanças foram:

• Ampliação do SPB-Web como ferramenta operacional central, com acesso restrito a operadores formalmente autorizados por cada instituição.
• Introdução do limite mínimo de saldo operacional, que é diferente do simples saldo mínimo de alerta. Enquanto o saldo mínimo gera um aviso, a violação do limite operacional pode impedir operações inteiras e acionar o bloqueio automático da Conta PI.
• Bloqueio automático da Conta PI como salvaguarda em situações de insuficiência crítica de liquidez, um mecanismo que antes não existia de forma automatizada.
• Monitoramento em tempo real com exigências mais rígidas de acompanhamento contínuo da posição de liquidez e dos controles internos.

A direção é clara: o regulador quer instituições que monitorem e controlem seus próprios riscos, em vez de depender de intervenções externas.

O que isso tem a ver com você?

Talvez você nunca tenha ouvido falar em SPI ou Conta PI, mas eles impactam diretamente a sua experiência. Se tudo funciona bem, você não percebe. O Pix acontece em segundos, sem atrito.

Mas, se há qualquer falha operacional, insuficiência de saldo institucional ou necessidade de contenção de risco, o sistema pode reagir. E essa reação pode se refletir em indisponibilidades, atrasos ou até interrupções momentâneas de serviços.

Ou seja, aquele “não foi possível concluir a operação” pode ter uma explicação muito mais profunda do que parece à primeira vista.

Segurança, velocidade e responsabilidade: o equilíbrio do sistema

O sucesso do Pix não está apenas na rapidez, mas na combinação entre velocidade e segurança.

Para que uma transação aconteça em segundos, é necessário que exista uma estrutura robusta, com regras claras, monitoramento constante e mecanismos de controle capazes de agir imediatamente diante de qualquer risco.

E quanto mais o sistema evolui, maior é a responsabilidade das instituições que participam dele. A Delfinance atua diretamente nesse ecossistema e acompanha de perto a evolução regulatória e tecnológica do sistema de pagamentos instantâneos, contribuindo para um ambiente cada vez mais eficiente, seguro e alinhado às necessidades de quem está do outro lado da tela.

Entre em contato conosco e se torne um cliente Delfinance.

• MED 2.0: você já imaginou rastrear o dinheiro do golpe mesmo depois que ele já mudou de conta?
• Imposto de Renda da Pessoa Jurídica (IRPJ): o que sua empresa precisa saber em 2026
• Você realmente sabe o que acontece quando faz um Pix? Entenda o que existe por trás da transferência instantânea
• Quando sua API começa a travar: o momento certo de parar de responder e começar a enfileirar
• Do monolito ao microsserviço: escalando só o necessário

Autor: Mirer Balbino

APIs normalmente nascem no modelo síncrono: uma requisição entra, o sistema processa e devolve uma resposta. Esse modelo é simples, direto e funciona bem para operações rápidas. 

Com o tempo, porém, o sistema cresce. Novas regras de negócio surgem, integrações são adicionadas e algumas requisições deixam de ser triviais. O que antes levava milissegundos passa a levar segundos, ou até minutos. É nesse ponto que insistir no modelo síncrono começa a comprometer a previsibilidade e a experiência do sistema. 

No início, otimizações pontuais resolvem boa parte dos problemas: melhorias em consultas ao banco, uso de cache e ajustes de performance. Essas mudanças não alteram o modelo da aplicação. O fluxo continua síncrono. 

O problema aparece quando o próprio fluxo de negócio muda. 

Imagine uma requisição que precisa criar registros, atualizar dados, gerar um relatório e enviar um e-mail. Esse tipo de operação pode levar tempo significativo para ser concluído. Nesse cenário, manter o processamento dentro da requisição deixa de ser uma decisão técnica e passa a ser um problema operacional. 

O ponto de virada

Na prática, o usuário nem sempre precisa da resposta completa imediatamente. Ele precisa acionar a operação, saber que a solicitação foi recebida e continuar usando o sistema. Se isso for suficiente, não há motivo para manter todo o processamento dentro da mesma requisição.

É aqui que entra o modelo assíncrono.

Em vez de executar tudo no momento da requisição, a aplicação recebe a solicitação, valida o necessário e delega o trabalho para ser processado depois. E isso pode ser feito com o uso de filas: estruturas que permitem armazenar tarefas e processá-las conforme houver disponibilidade. Uma boa analogia para entender o funcionamento das filas é a de um supermercado: os itens são colocados na esteira e processados no ritmo do operador. A aplicação deixa de tentar resolver tudo de uma vez e passa a organizar o trabalho para ser executado de forma controlada.

O que muda quando você desacopla o processamento

Na prática, isso significa transformar a requisição em uma mensagem, colocá-la em uma fila e permitir que outro componente a processe posteriormente. Independentemente da tecnologia utilizada, o papel da fila é sempre o mesmo: intermediar o envio e o processamento, desacoplando quem solicita de quem executa.

Com isso, o comportamento da aplicação muda. A resposta da API fica mais rápida, o sistema passa a lidar melhor com picos de carga e o processamento deixa de competir diretamente por recursos dentro da mesma requisição. Em vez de confirmar o resultado, a API passa a confirmar o recebimento da solicitação. 

Esse modelo, no entanto, não vem sem custo. Ao desacoplar o processamento, você adiciona complexidade: passa a lidar com mais componentes, precisa investir em monitoramento e observabilidade e deve tratar falhas de forma mais estruturada. O que antes era um fluxo linear passa a ser um fluxo distribuído. 

Por isso, filas não são uma solução universal. Elas fazem sentido quando o processamento é demorado, quando não há necessidade de resposta imediata ou quando o sistema precisa absorver carga de forma previsível. Em operações simples e rápidas, o modelo síncrono continua sendo a melhor escolha. No fim, a decisão entre síncrono e assíncrono não é sobre preferência arquitetural, mas sobre contexto. Insistir no modelo síncrono além do ponto certo não é simplicidade, é limitação. 

Esse tipo de abordagem é especialmente relevante em sistemas financeiros, onde cada operação precisa ser processada com previsibilidade, mesmo sob carga. Arquiteturas que desacoplam processamento permitem lidar melhor com picos, falhas e integrações externas sem comprometer a experiência do usuário. 

Operações em escala com a Delfinance

Se sua API já apresenta sinais de latência crescente, picos de carga concentrados ou operações que “seguram” a resposta por tempo demais, provavelmente o problema não é só performance, é modelo de execução.

A Delfinance opera APIs financeiras críticas em produção, incluindo fluxos de Pix, boletos e Banking-as-a-Service, onde previsibilidade e estabilidade não são opcionais. Decisões como quando manter síncrono ou migrar para processamento assíncrono fazem parte do desenho dessas plataformas.

Se quiser avaliar como esse tipo de arquitetura se aplica ao seu cenário, fale com nosso time:

Leituras recomendadas

Para evoluir a integração com uma visão mais completa de engenharia em sistemas financeiros, confira nossos outros artigos:

• Idempotência: por que reprocessar não deveria ser perigoso
• O dia em que precisamos trocar os trilhos de um dos trens mais rápidos do mundo: o Expresso Pix

Autor: George Silva

“Monolito ou microsserviços?” é uma daquelas perguntas clássicas de arquitetura de software que aparece em diversas discussões técnicas. Quase sempre ela vem carregada de opinião, experiência pessoal e, às vezes, um pouco de moda. O problema é que, no mundo real, a resposta raramente nasce de um debate teórico; ela aparece quando o padrão de carga, o modelo de escala e o custo operacional começam a divergir. Foi exatamente isso que aconteceu com a nossa API Pix.

QR Codes Pix

Quem já utilizou o Pix (ou seja, quase toda a população brasileira) sabe que é possível realizar os pagamentos através da leitura de um QR Code. Se formos mais a fundo no funcionamento desses QR Codes, veremos que eles são separados em dois tipos principais: estáticos e dinâmicos.

Os QR Codes estáticos são apenas uma forma conveniente de informar uma chave Pix em um formato 2D, não textual. Por isso, estes QR Codes costumam ser decodificados do lado da própria aplicação cliente (o aplicativo do seu banco, por exemplo), sem a necessidade de uma consulta ao servidor.

Os QR Codes dinâmicos, por sua vez, são mais ricos em atributos e informações, e por isso requerem que uma consulta ao servidor seja realizada para que possam ser decodificados.

QR Codes Pix na Delfinance

No ciclo de vida de cada QR Code Pix, existem no mínimo três ou quatro requisições:

1. Criação
2. Consulta/decodificação
3. Consulta de status para conclusão
4. E a própria conclusão

Inicialmente, as operações de QR Codes viviam dentro do mesmo serviço que concentrava todo o ecossistema Pix, e essas operações sozinhas dominavam o uso de CPU e memória e faziam o autoscaling elevar a quantidade de instâncias da aplicação inteira. Foi aí que a pergunta “monolito ou microsserviços?” deixou de ser filosófica e virou engenharia aplicada: por que escalar o sistema inteiro se a pressão está concentrada em uma responsabilidade específica? 

O contexto: um monolito Pix com escala acoplada

A API Pix era uma aplicação única em Java com Spring Boot, rodando em serviços serverless na cloud, responsável por processar cash-ins, cash-outs, devoluções, gestão e portabilidade de chaves Pix, além da geração e decodificação de QR Codes, e outras rotinas correlatas. Era um monolito no sentido literal: um único deploy e um único ciclo de escala. Mesmo com uma arquitetura interna bem estruturada, tudo subia e descia junto. E como o autoscaling estava configurado por consumo de CPU e memória, bastava um conjunto de rotas elevar o uso desses recursos para que o o servidor aumentasse a quantidade de instâncias do serviço inteiro.

Aqui vale um ponto técnico que geralmente fica escondido no debate “monolito vs microsserviços”: o acoplamento de escala. Quando várias responsabilidades vivem no mesmo processo, você não escala “funções”, você escala “o processo inteiro”, com tudo que ele carrega. Em infraestruturas de hospedagem serverless, esse acoplamento costuma se traduzir em custo direto quando a carga é assimétrica (isto é, uma parte da aplicação recebe uma carga significativamente maior que as outras).

O diagnóstico: quando um único fluxo “puxa o bonde”

As métricas obtidas através dos serviços de observabilidade deixaram o diagnóstico claro: o pico noturno era puxado, majoritariamente, pelo ato de criar e decodificar QR Codes, com maior pressão por volta da meia-noite. Em alguns períodos, esse conjunto de rotas representava a maior parte do tráfego e do consumo de recursos. Isso não significava que o monolito estivesse “malfeito”; significava que o perfil de carga evoluiu e o modelo de escala ficou desalinhado.

Antes de partir para uma extração, é comum tentar “resolver por dentro”: cache, filas, otimizações, índices, fine tuning, etc. No nosso caso, essas peças não eram novidade. Já atuávamos com filas e cache, e o armazenamento dos QR Codes era feito no MongoDB devidamente indexado; então não se tratava de um gargalo clássico de índices. O ponto principal não era um “bug de performance”; era uma questão de arquitetura operacional: enquanto QR Code estivesse dentro do mesmo processo, o pico de CPU e memória continuaria provocando upscaling do serviço inteiro. Otimizar poderia melhorar números, mas não mudaria a pergunta central do tema “monolito vs microsserviços”: quem está definindo o tamanho e o custo do seu runtime?

A decisão: dividir para conquistar, o nascimento da QR Code API

A decisão foi extrair a gestão de QR Codes para uma API dedicada. A recém-nascida QR Code API passou a concentrar geração, decodificação e consultas relacionadas, incluindo o payload JWS (cadeia de caracteres em Base64 que carrega diversas informações essenciais de um QR Code). Ela ganhou ciclo de deploy, observabilidade e autoscaling próprios, e passou a escalar de forma independente do restante do Pix. A comunicação entre os dois serviços foi desenhada conforme a necessidade de cada fluxo: em alguns casos por HTTP e em outros via AMQP, mantendo a flexibilidade onde fazia sentido.

Esse é um ponto em que o debate “monolito vs microsserviços” costuma confundir duas coisas diferentes: arquitetura de código e arquitetura de deploy. A extração que fizemos foi, antes de tudo, uma decisão de deploy e escala: separar o domínio que dominava recursos para que a infraestrutura deixasse de escalar o sistema inteiro por causa dele.

Para reduzir risco e acelerar a entrega, seguimos uma evolução incremental e não uma “versão purista” de microsserviços. Mantivemos o mesmo MongoDB e a mesma instância de cache, organizando o uso de forma separada quando necessário. Isso evitou reescritas e migrações de dados que não eram essenciais para resolver o problema principal naquele momento: escala e custo.

Migração sem quebrar integrações

A migração precisava preservar compatibilidade. Como a QR Code API era um serviço novo, aproveitamos a oportunidade para resolver débitos técnicos antigos, mas também construímos uma réplica compatível do que existia dentro da API Pix, para que a mudança pudesse ocorrer sem quebra de integração. Atualizamos a documentação e direcionamos novos clientes apenas para o endpoint novo, enquanto clientes existentes migravam de forma gradual e controlada. 

O rollout foi feito com feature toggle por número de conta, escolhendo clientes específicos como alvo. Esse mecanismo nos deu previsibilidade e, principalmente, rollback simples: bastava desabilitar o feature toggle e retornar ao caminho anterior. Como o armazenamento continuava no mesmo banco, o comportamento de idempotência e consistência que já sustentava o fluxo permaneceu válido, sem introduzir uma nova classe de problemas nesse aspecto. 

Resultados: escalar só o necessário (principalmente à meia-noite)

O resultado foi o que esperávamos: a API Pix deixou de escalar durante a madrugada por causa dos QR Codes. Além disso, conseguimos reduzir o tamanho e quantidade das instâncias da aplicação Pix, porque o seu perfil de CPU/mem passou a refletir apenas os fluxos que realmente lhe pertenciam. A QR Code API nasceu naturalmente menor e passou a escalar conforme sua própria demanda, sem carregar o restante do ecossistema junto. Em latência, também vimos melhora, especialmente por reduzir competição por recursos dentro de um mesmo processo durante o pico noturno. 

Naturalmente, nada disso vem de graça. Separar serviços adiciona complexidade operacional: mais um deploy para cuidar, mais pontos para monitorar, mais correlação de logs, métricas e rastreamento entre serviços. No nosso caso, esse trade-off foi positivo porque a assimetria do tráfego era clara, recorrente e custosa. Se o fluxo noturno caísse repentinamente e deixasse de justificar o investimento, provavelmente não valeria manter essa separação. Da mesma forma, se o domínio dos QR Codes tivesse dependências transacionais profundas com outros fluxos do Pix, o custo e o risco da separação poderiam superar o benefício. 

Conclusão: microsserviços quando a matemática manda 

No fim, ficou claro que a discussão “monolito vs microsserviços”, quando feita de forma madura, é menos sobre preferência e mais sobre critérios técnicos: acoplamento de escala, hotspots de tráfego e custo operacional. Microsserviços não são um objetivo; são uma ferramenta. Quando uma responsabilidade específica domina consumo e obriga você a escalar capacidades que não estão sob pressão, extrair uma fatia do monolito pode ser o caminho mais pragmático para reduzir custo e melhorar performance, desde que você tenha métricas para justificar a decisão, uma estratégia de migração compatível e um plano de rollback simples. 

Se o seu produto depende de Pix e precisa crescer sem comprometer custo, latência e previsibilidade, decisões como essa fazem diferença no dia a dia. 

A Delfinance opera APIs Pix em produção com foco em estabilidade e evolução contínua. Entre em contato conosco para discutir o seu cenário e entenda como podemos ajudar a escalar a sua operação de forma sustentável.

Leituras recomendadas

Para evoluir a integração com uma visão mais completa de engenharia em sistemas financeiros, confira nossos outros artigos:

• Idempotência: por que reprocessar não deveria ser perigoso
• O dia em que precisamos trocar os trilhos de um dos trens mais rápidos do mundo: o Expresso Pix

Autor: Tayrine Monteiro

A sensação de surpresa rapidamente se transforma em preocupação, depois em desgaste, ligações, protocolos e horas tentando desfazer algo que sequer deveria ter acontecido.

Agora imagine o cenário inverso: a tentativa ocorre, mas antes de qualquer confirmação, a instituição financeira consulta o sistema do Banco Central do Brasil e, em segundos, recebe a resposta “bloqueado”. A conta simplesmente não é aberta.

É exatamente essa lógica de prevenção que fundamenta o BC Protege+.

Você já imaginou o impacto disso na prevenção a fraudes? Em vez de agir depois do problema, discutindo responsabilidades e tentando reverter danos, o bloqueio ocorre na origem, impedindo que a relação contratual sequer se forme. Trata-se de uma inversão importante na lógica tradicional de proteção: sai o modelo reativo, entra o modelo preventivo.

O que é o BC Protege+?

O BC Protege+ é um mecanismo oficial que permite você registrar, de forma voluntária, uma restrição para impedir a abertura de novas contas em seu nome ou sua inclusão como titular ou representante em contas de terceiros.

Em termos simples: você registra a sua decisão, e o sistema financeiro é obrigado a respeitá-la.

Regulamentado pela Instrução Normativa BCB nº 661/2025, o sistema integra o conjunto de medidas voltadas ao fortalecimento da segurança no Sistema Financeiro Nacional e dialoga diretamente com as exigências previstas na Resolução CMN nº 4.753/2019 e na Resolução BCB nº 96/2021, que tornam obrigatória a consulta prévia pelas instituições financeiras antes da abertura de determinados tipos de contas.

Como funciona na prática (e por que a resposta vem em segundos)

Na prática, isso significa que, antes de abrir uma conta corrente, conta poupança ou conta de pagamento pré-paga, ou ainda incluir um novo titular ou representante, as instituições autorizadas a funcionar pelo Banco Central devem consultar o sistema.

Essa consulta é realizada de forma motivada e registrada, conforme determina a regulamentação. O retorno é praticamente imediato: em segundos, o sistema informa se a operação está “permitida” ou “bloqueada”. Caso exista restrição ativa, a conta não pode ser aberta. E, se houver indisponibilidade momentânea do sistema, a instituição deve aguardar, não podendo simplesmente ignorar a verificação.

E quando se trata de empresas?

Para pessoas jurídicas, a proteção é ainda mais robusta. A consulta deve abranger não apenas o CNPJ da empresa, mas também o CPF de todos os seus titulares e representantes, criando uma camada adicional de verificação e reduzindo o risco de estruturas fraudulentas mais complexas.

É gratuito?

Sim.

O registro da restrição no BC Protege+ é totalmente gratuito. Não há tarifa para ativação, manutenção ou consulta pelo cidadão.

É uma ferramenta pública de proteção, acessível a qualquer pessoa que cumpra os requisitos de autenticação.

Como ativar a proteção?

A ativação é feita diretamente no ambiente “Meu BC”, por meio de conta Gov.br com nível prata ou ouro e verificação em duas etapas habilitada.

O processo é online, simples e o efeito é imediato.

Caso você precise abrir uma nova conta no futuro, é possível desativar a restrição, inclusive de forma temporária. O controle permanece com você.

O que muda e o que não muda na sua vida financeira

É importante destacar que o BC Protege+ não interfere nas contas já existentes. Ele atua exclusivamente sobre novas aberturas ou inclusões, funcionando como um escudo prévio, e não como um bloqueio generalizado da sua vida financeira.

Você continua movimentando suas contas normalmente. A diferença é que novas relações só nascem se você permitir.

A Delfinance acompanha de perto as iniciativas do Banco Central que aumentam a segurança do sistema financeiro e a proteção dos consumidores. Conheça mais sobre nossas soluções, iniciativas e a trajetória da nossa instituição aqui.

Entre em contato conosco e se torne um cliente Delfinance.

• MED 2.0: você já imaginou rastrear o dinheiro do golpe mesmo depois que ele já mudou de conta?
• Imposto de Renda da Pessoa Jurídica (IRPJ): o que sua empresa precisa saber em 2026
• Você realmente sabe o que acontece quando faz um Pix? Entenda o que existe por trás da transferência instantânea
• Quando sua API começa a travar: o momento certo de parar de responder e começar a enfileirar
• Do monolito ao microsserviço: escalando só o necessário

Autor: Wesley Santana.

Em operações estruturadas, o desafio nem sempre é “fazer o pagamento acontecer”; é garantir que o dinheiro seja liberado do jeito certo, na hora certa e para a parte certa, com regras claras e tratamento de exceções quando algo sai do plano.

A Conta Escrow existe para isso. Ela funciona como uma conta de garantia, ou conta de custódia: os recursos ficam retidos sob regras previamente definidas e só são liberados quando as condições acordadas são cumpridas. Se houver divergência, cancelamento ou necessidade de devolução, o fluxo também segue o que foi combinado.

O que é uma Conta Escrow

Conta Escrow é uma conta usada para reter recursos sob custódia e liberá-los de forma condicional, conforme regras previamente definidas em contrato. Em vez de o valor cair diretamente para o recebedor, ele permanece retido até que as condições acordadas sejam cumpridas, com caminhos claros para liberação, devolução ou tratamento de divergências.

Quando faz sentido usar

Conta Escrow costuma ser útil quando existe risco relevante de descumprimento, necessidade de controle ou quando o repasse depende de eventos verificáveis. Exemplos típicos:

• operações financeiras estruturadas (FIDCs, securitizadoras, instituições)
• transações imobiliárias
• acordos e operações jurídicas
• prestação de serviços por etapas
• projetos de médio e grande porte, com entrega e aceite

Exemplo prático: uma empresa contrata um projeto em três etapas. O pagador deposita o valor total na Escrow. Após a entrega e aprovação da etapa 1, libera-se 30%. Na etapa 2, mais 30%. Na entrega final e aceite, libera-se o restante. Se houver divergência em alguma etapa, o valor daquela etapa permanece retido até a resolução prevista em contrato.

Em geral, sempre que o pagamento precisa seguir regras e não pode depender de confiança informal entre as partes, a Escrow se encaixa bem.

O que melhora na prática

Uma Conta Escrow bem desenhada melhora o fluxo em quatro frentes:

1. Segurança e previsibilidade: a liberação acontece apenas após as condições acordadas.
2. Redução de risco operacional e jurídico: menos margem para disputas, falhas de processo e interpretações ambíguas.
3. Segregação e custódia: o valor fica retido de forma segregada durante a operação.
4. Conformidade e controles: aplicação de controles que ajudam a sustentar operações sensíveis (como KYC e PLD-FT), dependendo do arranjo.

Como funciona em um fluxo típico

O modelo costuma seguir um roteiro simples:

1. Definição das condições: valores, prazos, eventos de liberação, responsabilidades e exceções ficam formalizados.
2. Depósito dos recursos: o pagador deposita o valor e ele permanece retido sob custódia.
3. Validação das condições: as regras de liberação são verificadas conforme o que foi combinado (ex.: documentação, marcos do projeto, aceite, evento objetivo).
4. Liberação ou destinação final: o valor é liberado ao beneficiário, pode haver liberação parcial, devolução, ou retenção em caso de divergência, conforme previsto.

O que considerar para estruturar bem

A Conta Escrow reduz riscos, mas não resolve tudo sozinha. O que faz a diferença é a clareza do acordo e o desenho das regras. Vale atenção especial para:

• critérios objetivos de liberação (o que comprova que a condição foi cumprida)
• prazos e responsabilidades (quem faz o quê e em quanto tempo)
• exceções (cancelamento, devolução, disputa, liberação parcial)
• auditoria e rastreabilidade (como comprovar o que aconteceu, quando e por qual motivo)

Quanto mais ambíguas forem as regras, mais o fluxo tende a virar disputa.

O que a Conta Escrow da Delfinance entrega

A Conta Escrow da Delfinance foi desenhada para viabilizar operações com retenção e liberação condicional de recursos, com governança e rastreabilidade. Na prática, você conta com:

• estruturação da operação e definição das regras de liberação
• custódia e retenção dos valores
• movimentações via Pix, TED e boletos
• relatórios, extratos e controles de acesso/alçadas
• suporte especializado para exceções (cancelamento, devolução, divergências)

O que a Conta Escrow da Delfinance não entrega

A Conta Escrow existe para dar previsibilidade a fluxos de retenção e liberação condicional de recursos. Ela não foi desenhada para “driblar” regras, esconder patrimônio ou servir de atalho para finalidades indevidas. Em especial, ela não entrega:

• Blindagem jurídica: A finalidade do produto não é criar mecanismos para proteger valores vinculados a atividades ilegais. A Conta Escrow é um instrumento operacional e contratual, não uma forma de blindagem patrimonial.
• Passagem de valores sem lastro em operação real: A Conta Escrow não é um “corredor de dinheiro” para circular recursos sem relação com um contrato, entrega, marco ou obrigação verificável. Uso sem lastro aumenta risco operacional e regulatório e contraria o propósito do produto.
• Burlar regras de compliance e controles de risco: Não é um caminho para evitar validações de KYC/PLD-FT, limites operacionais, trilha de auditoria ou controles internos. Se a operação exige governança, a Escrow reforça governança; não contorna.

Quando usada do jeito certo, a Conta Escrow melhora a confiança entre as partes, reduz disputas e dá previsibilidade para operações que dependem de condições claras de liberação. E, justamente por ser um instrumento poderoso, ela precisa ser aplicada com finalidade legítima, regras bem definidas e governança. É isso que transforma “reter e liberar” em operação profissional, sustentável e segura.

Para entender os custos, vantagens e como contratar a Conta Escrow da Delfinance, clique no botão abaixo:

Leituras recomendadas

• MED 2.0: você já imaginou rastrear o dinheiro do golpe mesmo depois que ele já mudou de conta?
• Imposto de Renda da Pessoa Jurídica (IRPJ): o que sua empresa precisa saber em 2026
• Você realmente sabe o que acontece quando faz um Pix? Entenda o que existe por trás da transferência instantânea
• Quando sua API começa a travar: o momento certo de parar de responder e começar a enfileirar
• Do monolito ao microsserviço: escalando só o necessário

Autor: Wesley Santana
Co-autor: Alisson Neves

Integração B2B em sistemas que levam segurança a sério não deveria depender só de tokens/chaves de API e “boa fé”. À medida que você adiciona parceiros, ambientes e diferentes stacks, a API vira uma fronteira: mais caminhos de entrada, mais variações de configuração e mais pressão por controle de acesso consistente.

mTLS (mutual TLS) é uma forma pragmática de subir o nível: além do servidor provar quem é, o cliente também precisa provar sua identidade no handshake, ou seja, antes mesmo da sua API processar qualquer requisição.

TL; DR: mTLS adiciona autenticação no transporte (TLS). Não substitui autorização, rate limiting ou observabilidade, mas dificulta a exploração de acessos indevidos e ajuda a restringir o perímetro da API.

TLS: O que o cadeado no seu navegador de fato significa

Quando você chama uma API via HTTPS, ou acessa um site e vê o ícone do cadeado ao lado da URL no navegador, você está usando TLS por baixo. O TLS garante principalmente:

• Criptografia em trânsito (ninguém “lê” o tráfego no caminho).
• Integridade (o conteúdo não é alterado sem ser detectado).
• Autenticação do servidor (você valida que está falando com quem diz ser).

No TLS convencional, o servidor apresenta um certificado, e o cliente valida a cadeia de certificação até uma CA (Certificate Authority, Autoridade Certificadora) confiável. Quando a validação do certificado é feita corretamente, o TLS mitiga ataques do tipo man-in-the-middle, porque o cliente autentica o servidor antes de estabelecer o canal seguro.

O que muda no mTLS

No mTLS, o servidor também exige que o cliente apresente um certificado. Ou seja, o servidor autentica o cliente durante o handshake e a requisição só chega na aplicação se o cliente superar essa barreira.

Isso é especialmente útil quando:

• você quer limitar o acesso à API apenas a clientes autorizados.
• você quer combinar camadas, como mTLS + IP allowlist + token, para reduzir a superfície de ataque.
• você quer que sua infraestrutura filtre conexões antes mesmo de rodar validações de aplicação.

O que mTLS resolve bem (e o que NÃO resolve)

Resolve bem:

• Barreira pré-aplicação: a conexão pode ser bloqueada no handshake, antes mesmo de chegar à aplicação.
• Identidade forte: você adiciona autenticação baseada em certificado + chave privada.
• Reduz abuso de credenciais expostas: ter acesso apenas ao token não basta se a conexão exige o certificado do cliente.

Não resolve:

• Comprometimento do cliente: se a máquina/app do cliente for comprometida e a chave privada estiver acessível, o atacante pode usar o certificado.
• Autorização: mTLS autentica “quem é”, não “o que pode fazer”.

Em outras palavras: mTLS eleva o custo do ataque e restringe quem consegue estabelecer conexão com a API, mas não é bala de prata. O cliente continua responsável por manter uma gestão segura de segredos (tokens, certificados e chaves privadas).

mTLS na prática: como normalmente é implementado

Em integrações reais, o desenho costuma ser:

1. Um API Gateway / Load Balancer estabelece o canal seguro de comunicação e valida o certificado do cliente.
2. Só então o tráfego segue para os serviços internos.
3. A aplicação mantém uma segunda camada de controle, como chave de API ou token (JWT/OAuth), para autorização, escopo e auditoria.

Esse modelo dá o melhor dos dois mundos:

• mTLS filtra conexões antes da requisição chegar à API.
• Chave de API/token decide o que aquele cliente pode fazer e registra trilha de auditoria.

Conceitos e terminologias

Quando falamos de mTLS, muitos termos técnicos surgem. Para evitar confusão, aqui vai um guia rápido sobre os principais conceitos:

CA (Certificate Authority / Autoridade Certificadora)
Entidade (ou cadeia de entidades) responsável por assinar certificados. O cliente/servidor valida um certificado verificando a cadeia de assinatura até uma CA confiável.

Certificado (Client/Server Certificate)
Arquivo público, geralmente com extensões .crt ou .cer, que contém a chave pública e metadados (identidade, validade, etc.), assinado por uma CA. Pode ser compartilhado com parceiros de integração, suporte técnico, times internos e qualquer parte que precise validar o certificado ou a cadeia de certificação. Se for vazado, o risco costuma ser baixo: em geral expõe apenas metadados (domínios, nomes de ambiente, emissor), mas não concede acesso sem a chave privada.

Private Key (Chave privada)
Chave usada para provar posse do certificado, geralmente presente em arquivos com a extensão .key ou .pem. Não deve ser compartilhada com ninguém, em hipótese alguma, nem mesmo com o parceiro com quem será feita a comunicação com mTLS. Se vazar, o risco é crítico: quem tiver a chave privada pode se passar pela integração e autenticar no mTLS como se fosse o titular do certificado, até que o certificado seja revogado e a chave rotacionada.

CSR (Certificate Signing Request)
Não é o certificado em si, mas um pedido de emissão de certificado que contém a chave pública e os dados de identificação, assinado com a chave privada correspondente. Deve ser compartilhado com o parceiro para emissão dos certificados.

PEM (extensão .pem)
Formato de codificação, com cabeçalho e rodapé, usado para representar certificados, CSRs, cadeias e também chaves privadas. Pode ser compartilhado apenas quando o conteúdo for certificado, CSR ou cadeia (por exemplo, quando contém BEGIN CERTIFICATE ou BEGIN CERTIFICATE REQUEST). Não deve ser compartilhado se contiver chave privada (por exemplo, BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY ou BEGIN EC PRIVATE KEY). Se vazado, o risco varia conforme o conteúdo: um PEM com certificados/CSR tende a expor apenas metadados; um PEM com chave privada é equivalente a vazamento de credencial e é crítico.

Na Delfinance, uma vez gerado os certificados públicos, estes são enviados via .pem, contendo única e exclusivamente o certificado público.

Segurança como requisito: mTLS nas APIs da Delfinance

Nas APIs da Delfinance, o mTLS é obrigatório em qualquer integração. Isso reflete uma escolha de produto: segurança não é “configuração opcional”, é requisito obrigatório. Para quem se integra conosco, o ganho está em mais previsibilidade e confiança. E para quem opera em escala, significa uma plataforma preparada para parcerias robustas, com controles consistentes desde o primeiro contato com a API.

Se você quer se integrar com a Delfinance usando mTLS, o caminho mais rápido é seguir o nosso guia oficial de emissão e teste do certificado: visite a nossa documentação!

Se você ainda não é cliente, e quer iniciar uma conversa com nosso time e receber o passo a passo para virar parceiro e integrar com segurança e robustez, comece por aqui:

Leituras recomendadas

Para evoluir a integração com uma visão mais completa de engenharia em sistemas financeiros, confira nossos outros artigos:

• Idempotência: por que reprocessar não deveria ser perigoso
• O dia em que precisamos trocar os trilhos de um dos trens mais rápidos do mundo: o Expresso Pix

Com o crescimento explosivo do Pix, também aumentou a necessidade de aprimorar os mecanismos de segurança da ferramenta. Só em 2024, por exemplo, o BC registrou R$ 6,5 bilhões em perdas por fraudes via Pix, um aumento de 80% em relação ao ano anterior. Esses números mostram que, quanto mais popular a ferramenta, mais os criminosos buscam explorar a rapidez e a praticidade das transações digitais.

Nesse sentido, a segurança financeira é um trabalho em equipe. De um lado, a Delfinance monitora suas transações 24 horas por dia; do outro, você precisa saber identificar sinais de perigo. Hoje, vamos explicar como funcionam os golpes mais comuns e quais práticas ajudam a se proteger.

Golpe do Pix: como funciona

O golpe do Pix se apresenta de várias formas, mas geralmente começa com mensagens ou ligações falsas em que o criminoso se passa por um banco ou instituição financeira. Ele tenta convencer a vítima de que há algo errado na conta e exige um Pix para “corrigir” a situação.

Algumas táticas usadas incluem:

• Phishing: envio de mensagens ou e-mails que imitam comunicação oficial do banco, pedindo que você registre suas chaves Pix (CPF, telefone ou e-mail) em sites falsos.
• Malware: links ou apps que, quando instalados, permitem que o criminoso acesse suas informações e até realize transações sem que você perceba.
• Promoções falsas: lojas e grandes varejistas são usadas como isca. Apenas após realizar o pagamento via Pix a vítima percebe que foi enganada.

Outro golpe que tem se tornado recorrente é o chamado “Pix errado”. Nessa prática, o criminoso realiza uma transferência para a conta da vítima e, logo em seguida, entra em contato alegando que o envio foi um engano. Com um discurso convincente e apelo à urgência, ele tenta induzir a devolução imediata do valor.

O ponto de atenção é que, paralelamente, o fraudador pode acionar o Mecanismo Especial de Devolução (MED), ferramenta instituída pelo Banco Central no âmbito do Pix para viabilizar a restituição de valores em casos de fraude. Se houver uma nova transferência para “devolver” o dinheiro e, ao mesmo tempo, o golpista registrar o MED, existe o risco de que ele receba duas vezes: pela devolução direta e pelo procedimento formal do sistema financeiro.

É fundamental distinguir as situações:

• No golpe do Pix (quando a vítima é induzida a realizar a transferência): ocorre quando a própria pessoa envia o valor ao criminoso, acreditando estar efetuando um pagamento legítimo, seja por um produto, serviço ou solicitação fraudulenta. Nesse caso, as medidas essenciais são solicitar imediatamente o MED pelo aplicativo da Instituição Financeira e registrar o Boletim de Ocorrência, documento indispensável para formalizar o crime e subsidiar as investigações.
• No golpe do “Pix errado” (quando o valor é recebido indevidamente): não se deve realizar uma nova transferência. A devolução deve ser feita exclusivamente pela transação recebida, acessando o comprovante no aplicativo e selecionando a opção “devolver” ou “devolução”. Dessa forma, o valor retornará pelo mesmo canal em que entrou, dentro do sistema do Pix, evitando pagamento em duplicidade.

Em ambos os casos, agir com rapidez e utilizar apenas os mecanismos oficiais disponíveis no aplicativo da sua Instituição Financeira é essencial para reduzir prejuízos. Informação, cautela e procedimento correto são as principais formas de prevenção.

Saiba mais sobre o MED

Vale lembrar que, a Delfinance não entra em contato direto com você fora dos canais oficiais e nunca pedirá informações sensíveis, como senhas ou códigos de autenticação, por mensagens, redes sociais ou aplicativos de terceiros. Caso receba qualquer tentativa suspeita, você pode reportar a situação diretamente pelo nosso Canal de Denúncias, ajudando a proteger você e outros clientes.

Golpe do falso advogado

Outro golpe muito comum mira pessoas com processos judiciais. O criminoso se passa por advogado ou representante de tribunal e afirma que você tem um valor a receber, mas exige um Pix para liberar o pagamento.

É importante reforçar: advogados e tribunais nunca pedem Pix para liberar valores de processos. Nunca use o número de WhatsApp que entrou em contato primeiro. Ligue sempre para o telefone oficial do escritório ou tribunal contratado para confirmar qualquer solicitação.

Como identificar sinais de alerta

Fique atento a situações suspeitas: mensagens urgentes de perfis desconhecidos, pedidos de Pix relacionados a processos judiciais e promessas de dinheiro que “dobra em minutos”.

Se algo se encaixa nesses casos, é golpe. Bloqueie a mensagem, confirme pelos canais oficiais e não envie nenhum valor sem ter certeza.

Por que estamos compartilhando isso?

Como instituição financeira autorizada pelo Banco Central, a Delfinance tem o dever de informar e proteger você. A educação digital é a melhor ferramenta contra o crime. Conhecendo os sinais de alerta e adotando práticas simples, você pode navegar no mundo digital com segurança e confiança.

Este conteúdo reforça o compromisso da Delfinance em garantir que você tenha controle sobre suas finanças. Saiba mais sobre nossos serviços, iniciativas e a trajetória da nossa instituição aqui.

• MED 2.0: você já imaginou rastrear o dinheiro do golpe mesmo depois que ele já mudou de conta?
• Imposto de Renda da Pessoa Jurídica (IRPJ): o que sua empresa precisa saber em 2026
• Você realmente sabe o que acontece quando faz um Pix? Entenda o que existe por trás da transferência instantânea
• Quando sua API começa a travar: o momento certo de parar de responder e começar a enfileirar
• Do monolito ao microsserviço: escalando só o necessário

Autor: Alisson Neves

Sistemas financeiros precisam ser idempotentes por padrão

Em quaisquer sistemas, falhas são inevitáveis. Redes caem, serviços ficam indisponíveis, mensagens são reenviadas e operações precisam ser reprocessadas. Mas o que não pode ser tido como inevitável é o efeito colateral dessas falhas.

É nesse ponto que a idempotência deixa de ser um detalhe técnico e passa a ser um requisito estrutural.

Mas o que é “idempotência”?

Idempotência é a propriedade de uma operação que garante que sua execução repetida, uma ou várias vezes, produz o mesmo efeito final que uma única execução.

Em sistemas financeiros, isso significa que uma mesma requisição, mesmo que reenviada por falhas de rede, retentativas automáticas ou reprocessamentos manuais, não pode gerar efeitos colaterais adicionais, como cobranças duplicadas, saldos incorretos ou estados inconsistentes.

Na Delfinance, utilizamos idempotência na API de Pix, por exemplo, para garantir que nenhuma operação seja erroneamente realizada mais de uma vez.

Falhas são normais, reprocessamento também

Em arquiteturas distribuídas, especialmente aquelas baseadas em eventos, filas e chamadas assíncronas, o reprocessamento não é exceção, é parte do fluxo habitual.

Alguns cenários comuns: 

• Timeout após o processamento efetivo, levando o cliente a reenviar a requisição 
• Retry automático de mensagens em filas
• Replays manuais para correção de falhas operacionais
• Recuperação após indisponibilidade parcial de serviços terceiros
• Envio duplicado de requisição única

Nesses cenários, executar a mesma operação mais de uma vez é esperado e aconselhável. O erro não está no reprocessamento, mas em sistemas que não foram projetados para lidar com ele.

Por que sistemas financeiros exigem idempotência por padrão

Diferente de sistemas puramente informacionais, sistemas financeiros lidam com dinheiro real, responsabilidade legal, auditoria e confiança do usuário. Um erro financeiro raramente é apenas técnico, ele se converte rapidamente em impacto financeiro direto, custos operacionais para correção, risco regulatório e perda de credibilidade.

Por isso, em sistemas financeiros bem desenvolvidos a pergunta correta não é “se haverá reprocessamento”, mas “quando“.

Muitos sistemas partem de premissas frágeis, como: “essa fila não duplica mensagens”, ou “esse endpoint só será chamado uma vez”, ou ainda “esse cliente não vai reenviar a requisição”. Na prática, nenhuma dessas garantias se sustenta em ambientes reais.

Protocolos de mensageria amplamente usados (como Kafka, RabbitMQ, SQS) operam com entrega pelo menos uma vez. Do ponto de vista de consistência financeira, isso significa que duplicatas são uma certeza estatística, não uma possibilidade remota.

Idempotência como mecanismo de segurança, não de otimização

Um erro comum é tratar idempotência como otimização, boa prática opcional ou responsabilidade do usuário. Mas em sistemas financeiros, idempotência é um mecanismo necessário de segurança de estado.

Ela protege o sistema contra retries automáticos, processamentos concorrentes e erros humanos em replays manuais. Assim como em transações de banco de dados, idempotência existe para preservar o domínio.

Idempotência nas APIs da Delfinance

Chave de idempotência

Toda operação sensível a efeitos colaterais, a exemplo de pagamentos e transferências, aceita uma chave única no cabeçalho da requisição, IdempotencyKey. Essa chave define a identidade da tentativa: se a mesma requisição for reenviada com a mesma chave, a API reapresenta a resposta já gerada e não executa o efeito novamente.

Um exemplo prático é a requisição de transferência na API de Core Bancário. Uma vez que a requisição é recebida por nossa API, a idempotência operacional é garantida, evitando débitos duplicados, além de prover rastreabilidade ponta a ponta.

Persistência antes do efeito

A regra é simples: registre a intenção antes de acionar qualquer efeito externo (ex.: iniciar um Pix). Ao persistir a intenção logo no início, a API consegue: 

• detectar duplicatas mesmo após timeout, queda de serviço ou retry agressivo; 
• retomar o processamento com segurança; 
• provar o que aconteceu (ou não aconteceu) em auditoria. 

Na API Pix da Delfinance, a intenção de envio é registrada antes do processamento efetivo. Isso significa que até tentativas interrompidas no meio do caminho continuam idempotentes: o sistema reconhece o pedido, sabe o estado, e evita repetir efeitos. 

Conclusão

Reprocessar não deveria ser perigoso. Se uma operação financeira não pode ser executada duas vezes sem causar dano, o problema não está no retry, mas no design. Sistemas financeiros maduros não tratam idempotência como exceção. Eles a adotam por padrão, como parte da própria definição de correção.

É essa visão que orienta o desenvolvimento das APIs da Delfinance, projetadas desde a origem para operar com segurança, previsibilidade e consistência, mesmo sob falhas, reprocessamentos e alta escala.

Deseja conhecer mais sobre nossas APIs de Pix, Cobrança, Bancarização e outros produtos?

Agora, se quiser saber como migramos o banco de dados da API de Pix com zero downtime e sem impacto negativo para nossos clientes, leia: O dia em que precisamos trocar os trilhos de um dos trens mais rápidos do mundo: o Expresso Pix.