Uma transferência financeira costuma parecer uma operação simples do ponto de vista de quem usa o sistema:

1. informar o destino;
2. informar o valor;
3. confirmar;
4. receber uma resposta.

Por trás dessa experiência, naturalmente existe muito mais engenharia. Ainda assim, vários sistemas acabam carregando uma premissa implícita: aceitar a transferência e concluí-la são eventos muito próximos no tempo.

Em 7 de agosto de 2026, o Banco Central do Brasil publicou a Resolução BCB nº 584, ampliando os controles de prevenção a fraudes para abranger também a prestação de serviços de ativos virtuais.

A Resolução BCB nº 584 estabelece que determinadas ordens de transferência de ativos virtuais destinadas a entidades do mercado de ativos virtuais no exterior ou a carteiras autocustodiadas ficam sujeitas, como regra geral, a uma retenção cautelar de 24 horas, contada a partir do recebimento dos respectivos recursos de aporte na carteira, em reais ou em ativos virtuais, com possibilidade de encerramento antecipado nas condições previstas na regulamentação. Entre as situações alcançadas estão operações cujo valor supera o equivalente a US$ 10 mil, considerado individualmente ou pelo total de operações realizadas no mesmo dia em nome do cliente. A medida entra em vigor em 1º de janeiro de 2027.

A Reuters, ao noticiar a medida, destacou o atraso de até 24 horas, o limite superior ao equivalente a US$ 10 mil, sua avaliação por operação ou pelo total diário do cliente e a possibilidade de aplicação da retenção a outras operações que demandem análise adicional conforme as políticas de risco da instituição. Os detalhes jurídicos específicos — incluindo o marco temporal da retenção e as condições de encerramento antecipado — são tratados aqui com base na Resolução BCB nº 584.

A Resolução BCB nº 584/2026 é a fonte normativa primária da nova retenção cautelar. Ela altera a Resolução BCB nº 142/2021, que trata de procedimentos e controles de prevenção a fraudes. A Resolução BCB nº 520/2025 entra como contexto sobre a regulamentação e o funcionamento das prestadoras de serviços de ativos virtuais. Já a Resolução BCB nº 521/2025 é especialmente relevante para operações internacionais e com carteiras autocustodiadas, incluindo requisitos de identificação e verificação de origem e destino dos ativos.

A partir daqui, o impacto discutido é uma análise arquitetural das consequências possíveis dessa mudança temporal — não uma arquitetura prescrita pelo Banco Central.

À primeira vista, parece apenas uma regra adicional de risco.

Do ponto de vista de software, existe uma mudança mais profunda escondida aí:

uma regra de negócio que altera o tempo de uma operação pode alterar a arquitetura inteira dessa operação.

A partir do momento em que uma transferência pode permanecer legitimamente em análise por horas, o sistema precisa representar algo que antes talvez fosse apenas uma exceção: o tempo entre aceitar uma intenção e produzir seu resultado final.

E isso nos leva a state machines, concorrência, idempotência, ledger, eventos, reconciliação, experiência do usuário e observabilidade.

1. O que aconteceu

Segundo a Reuters, o Banco Central anunciou novas medidas antifraude relacionadas a transferências com ativos virtuais.

A reportagem destaca quatro pontos relevantes para esta análise:

• determinadas transferências dentro do escopo da medida podem sofrer atraso de até 24 horas;
• a regra alcança operações acima do equivalente a US$ 10 mil destinadas a entidades do mercado de ativos virtuais no exterior ou a carteiras autocustodiadas;
• o limite pode ser avaliado por transação ou pelo total transferido pelo cliente no dia;
• outras operações podem demandar análise adicional conforme as políticas de gerenciamento de risco da instituição.

O BC também afirmou, segundo a Reuters, que a medida não representa congelamento permanente dos ativos.

A Resolução BCB nº 584 traz os detalhes jurídicos adicionais: o marco temporal da retenção está associado ao recebimento dos respectivos recursos de aporte na carteira, em reais ou em ativos virtuais, e a regulamentação prevê hipóteses de encerramento antecipado da retenção.

Esse contexto se conecta à regulamentação já existente para prestadoras de serviços de ativos virtuais. A Resolução BCB nº 521/2025 passou a produzir efeitos em etapas. Para o ponto relevante aqui, desde 2 de fevereiro de 2026 a regulamentação já contempla requisitos relacionados à identificação do proprietário de carteira autocustodiada e à verificação da origem e do destino de ativos virtuais.

Essas normas, em conjunto, apontam para um movimento regulatório mais amplo de aumento de rastreabilidade, controles e capacidade de análise de risco em operações envolvendo ativos virtuais.

Mas o ponto interessante para engenharia não está apenas no motivo da regra.

Está no tempo.

2. O detalhe que parece pequeno

“Até 24 horas.”

É fácil ler essa frase como uma simples configuração:

risk_hold_timeout = 24h

Mas uma operação que pode permanecer válida durante 24 horas em um estado intermediário não é apenas uma chamada mais lenta.

Ela é um processo.

Imagine uma implementação extremamente simplificada:

POST /transfers
       |
       v
   validação
       |
       v
 processamento
       |
       v
   COMPLETED

Nesse desenho, existe uma correlação quase direta entre receber a solicitação e chegar a um resultado.

Agora introduza análise de risco:

POST /transfers
       |
       v
   validação
       |
       v
 análise de risco
       |
       +------------------+
       |                  |
       v                  v
 aprovação imediata    retenção
       |                temporária
       |                  |
       |              até 24 horas
       |                  |
       +---------+--------+
                 |
                 v
          decisão posterior

O sistema deixa de ter apenas uma operação.

Passa a ter um workflow temporal.

Essa diferença parece pequena no requisito, mas pode ser enorme na arquitetura.

3. Onde começa o problema

O problema começa quando o sistema confunde três coisas diferentes:

comando recebido
      =
operação aceita
      =
operação concluída

Em muitos fluxos rápidos, essa simplificação funciona bem o suficiente para parecer verdadeira.

Mas são eventos conceitualmente diferentes.

Na regulamentação, o marco das 24 horas está associado ao recebimento dos respectivos recursos de aporte na carteira, e não necessariamente ao instante em que uma ordem de transferência é criada. A timeline a seguir abstrai esse detalhe e representa o ciclo de vida conceitual de uma operação para discutir seu impacto arquitetural.

Uma aplicação pode receber uma solicitação em T0, aceitá-la em T1, reservar recursos em T2, enviá-la para análise em T3 e somente concluir a transferência em T4.

T0          T1           T2             T3                T4
|-----------|------------|--------------|-----------------|
request     accepted     reserved       risk review       completed

Se o intervalo total entre T0 e T4 normalmente é pequeno, várias dessas etapas podem acabar escondidas dentro de uma única abstração.

Quando esse intervalo pode chegar a horas, essa abstração começa a vazar.

O frontend precisa saber que existe um estado intermediário.

A API precisa representar esse estado.

O ledger precisa definir o que acontece com os recursos.

O motor de risco precisa conseguir retomar a operação.

Eventos precisam informar mudanças de estado.

Processos de reconciliação precisam diferenciar “não concluída” de “perdida”.

O suporte precisa conseguir explicar o status ao cliente.

E a observabilidade precisa distinguir uma transferência corretamente retida de uma transferência travada por falha.

Uma mudança de tempo pode atravessar o sistema inteiro.

4. A premissa escondida

A premissa que esse caso quebra pode ser escrita assim:

“Se o sistema aceitou a transferência, seu resultado final virá imediatamente.”

Não é uma regra de negócio explícita.

É pior: pode ser uma premissa espalhada por várias partes do sistema.

No frontend:

const result = await createTransfer(input)

if (result.success) {
  showSuccess()
} else {
  showError()
}

No backend:

type TransferStatus =
  | "COMPLETED"
  | "FAILED"

No banco:

transfer.status NOT NULL
CHECK status IN ('COMPLETED', 'FAILED')

No analytics:

CASE
  WHEN status = 'COMPLETED' THEN 'success'
  ELSE 'failure'
END

No suporte:

Se não concluiu, houve algum erro.

A nova realidade pode exigir:

type TransferStatus =
  | "CREATED"
  | "UNDER_REVIEW"
  | "APPROVED"
  | "PROCESSING"
  | "COMPLETED"
  | "REJECTED"
  | "FAILED"

Os nomes acima são apenas ilustrativos. O ponto não é propor a state machine “correta” para uma instituição específica.

O ponto é que um novo estado legítimo do domínio precisa sobreviver aos contratos e componentes que dependem do resultado dessa operação.

E é aí que aparece o blast radius.

5. O blast radius

Uma regra regulatória pode começar no motor de risco, mas dificilmente termina nele.

Se o estado intermediário não estiver modelado corretamente, ele começa a aparecer como comportamento estranho em outros lugares.

O frontend interpreta análise como erro.

O cliente tenta novamente.

O segundo comando cria uma duplicidade.

O ledger não sabe se os recursos continuam disponíveis.

O analytics mede queda de conversão.

O suporte abre incidente.

O monitoramento dispara alerta de latência.

A reconciliação encontra uma operação “incompleta”.

Nenhum desses componentes precisa estar individualmente errado.

Eles podem simplesmente continuar operando sobre uma premissa que deixou de ser verdadeira.

Esse é um dos padrões mais perigosos em evolução de sistemas:

o domínio muda em um ponto, mas a premissa antiga continua replicada em vários outros.

6. A engenharia por trás

6.1 A transferência passa a precisar de estados e transições explicitamente modelados

Uma state machine é uma forma natural de tornar esses estados e transições visíveis e verificáveis. Um fluxo mais realista poderia ser representado conceitualmente assim:

Novamente: isso é uma ilustração arquitetural, não uma especificação do BC.

A vantagem desse tipo de modelagem explícita é tornar visíveis transições que não fazem sentido e as regras que governam cada mudança de estado.

Por exemplo:

UNDER_REVIEW -> COMPLETED

talvez precise obrigatoriamente passar por:

UNDER_REVIEW -> APPROVED -> PROCESSING -> COMPLETED

A state machine deixa claro:

• quais estados existem;
• quem pode alterá-los;
• quais transições são válidas;
• quais efeitos colaterais cada transição produz;
• como recuperar uma operação interrompida.

Quando o tempo do processo aumenta, essas propriedades deixam de ser detalhes de implementação.

6.2 O threshold diário pode transformar validação em um problema de estado e concorrência

O detalhe mais interessante da regra talvez seja a possibilidade de considerar o total diário do cliente.

Considere:

Transferência A = US$ 4.000
Transferência B = US$ 3.000
Transferência C = US$ 4.000

Individualmente:

A < 10.000
B < 10.000
C < 10.000

Mas:

A + B + C = 11.000

Se o cálculo regulatório for materializado dessa forma, a decisão deixa de depender apenas do payload atual.

Ela passa a depender também de contexto acumulado.

Em vez de decidir apenas com base no valor da requisição atual, o problema conceitual passa a depender também do contexto acumulado:

if (meetsDailyReviewThreshold(customerId, transfer)) {
  review()
}

A função acima é deliberadamente abstrata. A fronteira exata do limite, a janela temporal, conversões e quais operações entram no acumulado dependem da definição regulatória e da implementação de cada instituição.

A implementação exata dependerá de como a regra definir o cálculo e de como cada instituição materializar esse acumulado. Mas, se decisões concorrentes dependerem do mesmo total diário, surge imediatamente um problema clássico de consistência.

O que acontece com concorrência?

Imagine:

exposição atual: US$ 8.000

Request A: + US$ 1.500
Request B: + US$ 1.500

Se A e B lerem o mesmo estado:

8.000 + 1.500 = 9.500

as duas podem concluir que ainda estão abaixo do threshold.

Mas o resultado combinado é:

8.000 + 1.500 + 1.500 = 11.000

Temos uma race condition.

O requisito antifraude passa a tocar em:

• consistência;
• serialização;
• locks;
• conditional writes;
• transações;
• particionamento por cliente;
• ordenação de eventos.

Algo que parecia um simples if agora exige decisão arquitetural.

6.3 O estado “pendente” não pode significar falha

Em sistemas síncronos existe uma tendência natural de mapear demora para erro.

rápido     = sucesso
demorou    = timeout
timeout    = falha

Mas um processo de análise pode estar demorando e, ainda assim, estar completamente saudável.

UNDER_REVIEW = comportamento esperado

Isso muda inclusive observabilidade.

Uma métrica como:

transfer_duration_seconds

pode deixar de ser suficiente.

Talvez o sistema precise separar:

processing_time
risk_review_time
settlement_time
queue_time

Da mesma forma:

pending_transfers > 0

não significa necessariamente problema.

O alerta precisa responder a algo mais útil:

transferências em análise acima do tempo esperado

ou:

crescimento anormal da fila de revisão

A observabilidade precisa representar o domínio, não apenas a infraestrutura.

6.4 Idempotência deixa de ser detalhe

Agora imagine a experiência do cliente.

10:00 -> transferência criada
10:01 -> UNDER_REVIEW
10:10 -> cliente verifica saldo
10:11 -> cliente acha que não funcionou
10:12 -> tenta novamente

Se a aplicação não deixa clara a existência do processo intermediário, ela pode incentivar retries humanos.

O problema passa a ser:

Request #1 -> UNDER_REVIEW
Request #2 -> ???

É por isso que idempotência se torna ainda mais importante em workflows demorados.

Uma API poderia adotar um mecanismo de idempotência de aplicação, por exemplo usando um header Idempotency-Key:

POST /transfers
Idempotency-Key: 27fb8b...

Com isso, a repetição da mesma intenção não precisa criar outra transferência.

Mas mesmo idempotência possui trade-offs:

• qual é a janela de deduplicação?
• a chave pertence ao cliente, conta ou operação?
• o payload precisa ser idêntico?
• por quanto tempo guardar a chave?
• o que retornar se a primeira execução ainda estiver em análise?

Por exemplo:

{
  "transferId": "trf_123",
  "status": "UNDER_REVIEW"
}

O retry não cria uma segunda operação.

Ele recupera a identidade da primeira.

O princípio é simples:

quanto maior o intervalo entre comando e conclusão, maior a importância de preservar a identidade da operação.

6.5 O contrato de integração precisa conseguir representar aceitação sem conclusão

Existe uma diferença semântica importante entre:

{
  "status": "completed"
}

e:

{
  "transferId": "trf_123",
  "status": "under_review"
}

Na segunda resposta, a API não está dizendo:

“a transferência terminou.”

Ela está dizendo:

“eu aceitei o processo e agora existe uma operação identificável em andamento.”

Essa diferença pode mudar o desenho do contrato de integração.

O cliente talvez precise conseguir consultar:

GET /transfers/trf_123

E receber posteriormente:

{
  "transferId": "trf_123",
  "status": "completed"
}

Ou receber uma notificação/evento quando o estado mudar.

Em termos arquiteturais:

request-response

passa a coexistir com:

command
   +
state
   +
event

Não significa que todo sistema precise adotar uma arquitetura orientada a eventos.

Significa que uma API precisa ser honesta sobre a duração real do processo que representa.

6.6 O ledger precisa responder: qual é o estado dos recursos durante a espera?

Esse talvez seja o ponto de domínio mais sensível.

Se uma transferência está em análise, qual é o estado econômico dos recursos?

Conceitualmente, podemos imaginar:

available_balance
reserved_balance
settled_balance

Ao iniciar uma operação:

available -> reserved

Depois da aprovação:

reserved -> settlement

Em caso de rejeição:

reserved -> available

Mas há várias alternativas possíveis.

Reservar cedo reduz o risco de o cliente consumir o mesmo saldo enquanto a transferência está em análise.

Por outro lado, manter recursos indisponíveis por um período maior afeta a experiência do cliente.

Reservar tarde pode melhorar disponibilidade de saldo, mas aumenta a complexidade para garantir fundos quando chegar a hora da execução.

Não existe decisão gratuita.

É um exemplo clássico de arquitetura como gestão de trade-offs.

6.7 Eventos também precisam evoluir

Talvez o sistema já publique algo assim:

{
  "event": "TransferCompleted",
  "transferId": "trf_123"
}

Com um workflow intermediário, outros eventos podem passar a ser relevantes:

TransferCreated
TransferSentToRiskAnalysis
TransferReviewStarted
TransferApproved
TransferRejected
TransferCompleted

Mas criar eventos para tudo também tem custo.

Mais eventos significam:

• mais contratos;
• mais consumidores;
• mais compatibilidade a manter;
• mais possibilidade de duplicidade;
• mais necessidade de ordenação ou versionamento.

A pergunta não é:

“Devemos criar eventos?”

A pergunta é:

quais mudanças de estado são relevantes fora do bounded context responsável pela transferência?

Notificação talvez precise saber que a operação foi para análise.

Analytics talvez precise medir duração de revisão.

Ledger talvez não deva conhecer detalhes internos do motor antifraude.

O modelo de eventos precisa preservar separação de responsabilidades.

6.8 Reconciliação passa a ser uma capacidade operacional de primeira classe

Quando uma operação pode durar horas, aumenta a chance de atravessar:

• restart de aplicação;
• deploy;
• indisponibilidade de dependência;
• retry;
• atraso de fila;
• perda temporária de conectividade;
• inconsistência entre sistemas.

Então surge uma propriedade importante:

o workflow não pode depender da memória do processo que o iniciou.

O estado precisa ser durável.

Se um worker morrer enquanto uma transferência estiver em análise, o sistema precisa conseguir recuperar ou reconciliar o estado da operação sem depender da memória do processo que a iniciou.

É aqui que aparecem padrões como:

• durable workflows;
• outbox;
• inbox/deduplicação;
• retries com backoff;
• reconciliation jobs;
• sagas em fluxos realmente distribuídos.

Não é necessário aplicar todos eles.

Mas a necessidade fundamental é simples:

processos longos precisam sobreviver aos processos computacionais que os executam.

7. Como eu abordaria

Eu começaria modelando o domínio antes de escolher tecnologia.

Passo 1 — separar intenção, aceitação e conclusão

Definir explicitamente:

TransferRequested
TransferAccepted
TransferCompleted

e entender o que cada etapa significa para o negócio.

Passo 2 — modelar estados e transições

Criar uma state machine mínima e definir:

• estados terminais;
• estados intermediários;
• transições permitidas;
• timeout de negócio;
• efeitos sobre saldo;
• ações de recuperação.

Passo 3 — definir a unidade de consistência do threshold

Se regras dependem de exposição diária por cliente, decidir onde esse estado vive e como atualizações concorrentes serão serializadas.

Opções podem incluir:

• banco relacional com transação;
• conditional update;
• particionamento por customerId;
• stream ordenado por cliente;
• contador/materialização com mecanismos de consistência adequados.

A escolha depende da escala e das garantias exigidas.

Passo 4 — tornar a operação idempotente

Toda transferência precisa possuir identidade estável.

Retries técnicos ou humanos não deveriam gerar novas operações sem intenção explícita.

Passo 5 — definir semântica do saldo

Responder formalmente:

quando o dinheiro deixa de estar disponível?

e:

quando ele volta a estar disponível em caso de rejeição?

Passo 6 — tornar o workflow recuperável

Nenhum estado relevante deve existir apenas na memória de um worker.

Passo 7 — observar estados de negócio

Além de CPU, memória e erros HTTP, medir:

transfers_under_review
review_duration
transfers_rejected
transfers_expired
reconciliation_mismatches
duplicate_attempts

Passo 8 — tornar o estado compreensível para o cliente

Um sistema tecnicamente correto ainda pode criar retries, chamados e percepção de falha se o usuário não entender que a transferência está em análise.

Arquitetura e UX se encontram aqui.

8. Trade-offs

Consistência forte vs. throughput

Se o limite depende do acumulado diário por cliente, garantir uma visão perfeitamente serializada pode exigir coordenação.

Coordenação tende a adicionar latência e pode limitar throughput ou escalabilidade.

Aceitar consistência mais relaxada pode melhorar escala, mas exige avaliar se o risco de decisões simultâneas incorretas é aceitável.

Em sistemas financeiros, essa escolha precisa ser deliberada.

Reserva imediata vs. disponibilidade de saldo

Reservar o recurso assim que o workflow começa simplifica algumas garantias financeiras.

Mas também pode manter o saldo indisponível durante horas.

Esperar pela aprovação melhora liquidez para o cliente, porém pode criar novas condições de corrida.

Eventos detalhados vs. acoplamento

Publicar cada transição aumenta observabilidade e integração.

Mas também transforma estados internos em contratos externos.

Uma vez que dezenas de consumidores dependem de TransferUnderReview, mudar a state machine pode ganhar um blast radius inesperado.

Workflow próprio vs. orquestrador durável

Implementar a state machine dentro do próprio serviço reduz dependências.

Mas workflows longos, retries e timers podem se tornar complexos.

Ferramentas de durable execution podem simplificar recuperação e timers, ao custo de uma nova plataforma operacional e novo modelo mental para o time.

Segurança vs. instantaneidade

Esse talvez seja o trade-off central da própria notícia.

Quanto mais rapidamente um ativo pode sair do alcance do sistema, menor a janela para interromper fraude.

Adicionar tempo cria oportunidade para análise.

Mas também muda uma característica que os usuários valorizam: velocidade.

Não existe solução que maximize simultaneamente segurança, velocidade, simplicidade e disponibilidade.

Arquitetura é decidir conscientemente qual propriedade ceder, quando e por quê.

9. O que esse caso ensina sobre construir software

A principal lição não é sobre cripto.

Também não é sobre uma regra específica do Banco Central.

É sobre tempo como parte do domínio.

Quando pensamos em contrato de software, normalmente lembramos de:

campos
tipos
schemas
status
endpoints

Mas sistemas também carregam contratos temporais:

quanto tempo uma operação leva
quando um recurso fica disponível
por quanto tempo um estado pode existir
em que momento uma decisão se torna final
quando um cliente pode tentar novamente

Essas propriedades frequentemente não aparecem no OpenAPI.

Ainda assim, aplicações, usuários e integrações começam a depender delas.

Quando, em um sistema, uma transferência que normalmente terminava em segundos passa a poder permanecer em análise por horas, não mudou apenas um SLA.

Mudou o significado da operação.

E quando o significado muda, o impacto pode chegar a:

Domínio
  ↓
API
  ↓
Frontend
  ↓
Serviços
  ↓
Eventos
  ↓
Ledger
  ↓
Reconciliação
  ↓
Analytics
  ↓
Integrações

A pergunta útil para arquitetos e engenheiros passa a ser:

quais partes do meu sistema assumem que esta operação termina imediatamente?

É essa pergunta que revela o verdadeiro blast radius.

10. Conclusão

Uma nova regra antifraude pode parecer apenas mais uma validação.

Mas validações tradicionais normalmente respondem algo próximo de:

permitir
ou
negar

Quando uma decisão pode levar horas, surge uma terceira dimensão:

ainda não sabemos

Representar corretamente esse “ainda não” exige estado.

Estado exige regras claras de transição.

Transições exigem decisões explícitas sobre consistência.

Processos demorados tornam idempotência e recuperação muito mais importantes.

E sistemas financeiros precisam manter o significado econômico dos recursos durante todo esse intervalo.

Por isso, o ponto mais interessante dessa mudança não é o número de 24 horas.

É o princípio que ele revela:

tempo também faz parte do contrato de um sistema.

Quando esse contrato muda, o problema raramente fica isolado em uma regra de negócio.

Ele pode atravessar toda a arquitetura.

Referências

Normas do Banco Central

1. Banco Central do Brasil — Resolução BCB nº 584, de 7 de agosto de 2026 — altera a Resolução BCB nº 142/2021 e inclui regras específicas de prevenção a fraudes na prestação de serviços de ativos virtuais, incluindo retenção cautelar de 24 horas em determinadas transferências.
2. Banco Central do Brasil — BC adota novas medidas de prevenção de fraudes em serviços de ativos virtuais, 7 ago. 2026 — comunicação oficial sobre a Resolução BCB nº 584/2026.
3. Banco Central do Brasil — Resolução BCB nº 142, de 23 de setembro de 2021 — procedimentos e controles para prevenção de fraudes, alterada pela Resolução BCB nº 584/2026.
4. Banco Central do Brasil — Resolução BCB nº 520, de 10 de novembro de 2025 — disciplina a constituição e o funcionamento das sociedades prestadoras de serviços de ativos virtuais e a prestação desses serviços.
5. Banco Central do Brasil — Resolução BCB nº 521, de 10 de novembro de 2025 — regulamenta atividades com ativos virtuais no mercado de câmbio e capitais internacionais e inclui requisitos relacionados a carteiras autocustodiadas, identificação e origem/destino.

Cobertura jornalística

1. Reuters — Brazil tightens crypto transfers to curb fraud, 7 ago. 2026 — cobertura jornalística contemporânea do anúncio e de seus principais parâmetros.