Introdução
A Declaração de Autocustódia qualifica cada endereço de destino de saque de cripto — ou connection de contraparte — na Parfin Platform quanto à sua natureza: autocustódia do titular ou custódia de terceiro (outra PSAV).
A partir desta funcionalidade, todo destino de saque — cadastrado na Whitelist do Terminal, nos Withdraw Addressesdo CaaS ou em uma Connection de contraparte — precisa carregar essa declaração para continuar sendo usado em saques e transferências.
Endereços e connections já cadastrados não recebem a declaração automaticamente: precisam ser enriquecidos para seguir disponíveis como destino.
Essa declaração é a base para a extração de uma informação exigida pela Receita Federal (IN2291 — DeCripto) no relatório RFQ Funding; o detalhe dessa extração está no artigo [IN2291 (DeCripto): nova informação no relatório RFQ Funding].
O que muda
- Todo cadastro novo de um destino de cripto passa a exigir a declaração de autocustódia.
- Endereços de whitelist e connections já cadastrados precisam ser enriquecidos com essa declaração para continuarem disponíveis como destino.
- Endereços e connections sem a declaração completa ficam indisponíveis para seleção como destino de saques e transferências.
Como funciona
A declaração é um valor binário (autocustódia ou não) associado a um endereço de destino ou a uma connection de contraparte. Três propriedades valem para as três superfícies onde ela é capturada:
- É obrigatória em todo cadastro novo de um destino de cripto — exceto no cadastro de endereços via API para usuários finais de white-label, onde permanece opcional.
- É imutável uma vez definida. Não existe edição de Yes para No ou vice-versa; corrigir uma declaração exige recriar o destino (excluir e recadastrar um endereço, ou reconectar uma contraparte). Isso evita que uma reclassificação retroativa comprometa a rastreabilidade de saques já reportados.
- Não é preenchida retroativamente. Endereços e connections que já existem na base de um cliente permanecem sem a declaração até que alguém a informe explicitamente — não há inferência automática a partir do histórico de operações.
Um destino sem a declaração fica indisponível para seleção em saques e transferências. Essa é a peça central da funcionalidade: a plataforma impede que um destino seja escolhido sem que se saiba, na origem, se ele é autocustódia ou não.
Isso desloca o trabalho de classificação para o momento em que o destino é definido — seja no cadastro de um novo endereço ou connection, seja no enriquecimento de um endereço ou connection já existente — feito uma única vez por destino, em vez de repeti-lo a cada saque ou relatório.
Whitelist do Terminal
No back-office (Terminal), quem declara é o administrador da instância, ao cadastrar um endereço de whitelist. A declaração aqui representa o conhecimento da própria instância sobre os endereços que ela mesma movimenta — por isso, o cadastro e a alteração de declarações passam pela mesma política de governança que já se aplica ao whitelist. Completar a declaração de um endereço já existente (sem alterar os demais dados) é tratado como uma ação de baixo risco e não reabre o fluxo de governança — apenas confirma-se com autenticação de dois fatores.
Toda ação sobre a declaração — cadastro ou complementação — é registrada em log de auditoria, já que se trata de um dado com peso regulatório.
Withdraw Addresses no CaaS (white-label)
Aqui, quem declara é o cliente final do balcão OTC, sobre os próprios endereços de saque. Como esse cadastro é self-service, não há aprovação de governança envolvida — a autenticação de dois fatores é suficiente tanto para o cadastro quanto para completar um endereço já existente.
Quando o cadastro e o saque acontecem via API, a declaração é opcional, e a ausência dela não bloqueia o saque. Essa é uma exceção deliberada: o controle de bloqueio existe para proteger o fluxo self-service via interface, não para impor uma trava rígida sobre integrações de terceiros.
Connections de contraparte
Quando o destino de um saque não é um endereço individual, mas uma contraparte conectada (uma exchange, um custodiante, um balcão interno), a declaração vive na connection, não em cada endereço. Ela é declarada pelo administrador ao criar ou completar a connection — para qualquer tipo de contraparte de cripto, já que a natureza de autocustódia não pode ser inferida do tipo de contraparte em si (uma Custody, por exemplo, pode ser tanto autocustódia quanto de terceiro). Contrapartes exclusivamente fiat (Bank) não participam dessa lógica, por não serem destino de cripto.
Saques executados através de uma Connection de Internal OTC herdam automaticamente a declaração já feita naquela connection — não é preciso uma declaração própria para cada endereço de destino gerado nessas operações.
Ação necessária
Endereços de whitelist e connections cadastrados antes desta funcionalidade continuam existindo normalmente, mas não podem mais ser usados como destino de saque até que a declaração seja informada.
O Administrador da Instância deve revisar a Whitelist do Terminal e as Connections de contraparte; o cliente final do white-label deve revisar seus próprios Withdraw Addresses. Em ambos os casos, o enriquecimento é feito diretamente sobre o destino já cadastrado, sem necessidade de recadastro completo.
Regras e limites
| Situação | Comportamento |
|---|---|
| Cadastro novo de endereço ou connection (Terminal, CaaS via UI, Connections) | Declaração obrigatória |
| Cadastro de endereço via API (RFQ User de white-label) | Declaração opcional |
| Connection do tipo Bank | Não se aplica — contraparte fiat não é destino de cripto |
| Tentativa de alterar uma declaração já definida | Não é possível in-place; exige recriar o destino (recadastro ou reconexão) |
| Endereço ou connection já existente sem declaração | Não recebe preenchimento automático; não pode ser usado como destino até ser completado |
| Destino sem declaração completa | Fica indisponível para seleção em saques e transferências, exceto no fluxo via API mencionado acima |
| Saque via API para endereço sem declaração | Executado normalmente; a ausência de declaração impacta apenas a extração de relatórios (ver artigo sobre DeCripto) |
| Saque via Internal OTC | Herda a declaração da connection da contraparte |
Perguntas frequentes
Por que a declaração não pode ser alterada depois de definida?
Porque ela alimenta um relatório com peso regulatório. Permitir edição in-place abriria a possibilidade de uma reclassificação retroativa sem rastro claro do porquê. Exigir recriação do destino (recadastro ou reconexão) garante que qualquer mudança de classificação fique associada a um novo destino, com sua própria trilha de auditoria.
Por que endereços e connections já existentes não recebem a declaração automaticamente?
Porque a informação de autocustódia não existe nos dados históricos — inferi-la seria adivinhar, não declarar. Cabe à instância, ou ao cliente final no caso do white-label, informar explicitamente essa qualificação para cada destino já cadastrado, antes de voltar a usá-lo em saques.
Por que o fluxo via API permite saques sem a declaração, enquanto a interface bloqueia?
Porque o bloqueio existe para proteger o fluxo self-service, onde o próprio usuário final declara em tempo real. Em integrações via API, o cliente Parfin controla o cadastro e pode optar por gerenciar esse enriquecimento com sua própria lógica; a plataforma reflete a lacuna no relatório em vez de impor um bloqueio rígido sobre um fluxo que ela não controla diretamente.
Um saque via Internal OTC exige uma declaração própria para cada endereço de destino gerado?
Não. Esses endereços herdam automaticamente a declaração já feita na connection da contraparte, porque a autocustódia é, nesse caso, uma característica da relação com a contraparte — não de cada operação isolada.
Veja também
IN2991 (DeCripto): nova informação no relatório RFQ Funding — como essa declaração alimenta o relatório RFQ Funding e a montagem da DeCripto. (link a atualizar após a publicação do artigo no FreshDesk)