Support Portal

Introduction

The Self-Custody Declaration qualifies each crypto withdrawal destination address — or counterparty connection — on the Parfin Platform according to its nature: self-custody of the account holder, or custody by a third party (another VASP).

Starting with this functionality, every withdrawal destination — registered in the Whitelist of the Terminal, in the Withdraw Addresses of CaaS, or in a counterparty Connection — needs to carry this declaration to remain usable in withdrawals and transfers. Addresses and connections already registered do not receive the declaration automatically: they need to be enriched to remain available as a destination.

This declaration is the basis for extracting information required by Brazil's Receita Federal (IN2291 — DeCripto) in the RFQ Funding report; the detail of that extraction is covered in the article [IN2291 (DeCripto): New Information in the RFQ Funding Report].

What changes

• Every new registration of a crypto destination now requires the self-custody declaration.
• Whitelist addresses and connections already registered need to be enriched with this declaration to remain available as a destination.
• Addresses and connections without a complete declaration become unavailable for selection as a withdrawal or transfer destination.
  
  

How it works

The declaration is a binary value (self-custody or not) associated with a destination address or a counterparty connection. Three properties apply across the three surfaces where it is captured:

• It is mandatory on every new registration of a crypto destination — except for address registration via API for white-label end users, where it remains optional.
• It is immutable once set. There is no editing from Yes to No or vice versa; correcting a declaration requires recreating the destination (deleting and re-registering an address, or reconnecting a counterparty). This prevents a retroactive reclassification from compromising the traceability of withdrawals already reported.
• It is not backfilled retroactively. Addresses and connections that already exist in a client's base remain without the declaration until someone explicitly provides it — there is no automatic inference from operation history.
  
  

A destination without the declaration becomes unavailable for selection in withdrawals and transfers. This is the core of the functionality: the Platform prevents a destination from being chosen without knowing, at the source, whether it is self-custody or not.

This moves the classification work to the moment the destination is defined — whether at the registration of a new address or connection, or at the enrichment of an address or connection that already exists — done once per destination, instead of repeating it at every withdrawal or report.

Terminal Whitelist

In the back office (Terminal), the Instance Administrator is the one who declares, when registering a whitelist address.
The declaration here represents the instance's own knowledge about the addresses it moves. Completing the declaration of an address that already exists (without changing the other data) is treated as a low-risk action and does not reopen the governance flow — it only requires confirmation with two-factor authentication.

Every action on the declaration — registration or completion — is recorded in the audit log, given that this is a data point with regulatory weight.

CaaS Withdraw Addresses (white-label)

Here, the end client of the OTC desk is the one who declares, on their own withdrawal addresses. Since this registration is self-service, no governance approval is involved — two-factor authentication is sufficient both for registration and for completing an address that already exists.

When registration and withdrawal happen via API, the declaration is optional, and its absence does not block the withdrawal. This is a deliberate exception: the blocking control exists to protect the self-service flow through the interface, not to impose a rigid gate on third-party integrations.

Counterparty Connections

When a withdrawal's destination is not an individual address but a connected counterparty (an exchange, a custodian, an internal OTC desk), the declaration lives on the connection, not on each address. It is declared by the administrator when creating or completing the connection — for any type of crypto counterparty, since the nature of self-custody cannot be inferred from the counterparty type itself (a Custody counterparty, for example, can be either self-custody or third-party). Counterparties that are exclusively fiat (Bank) do not participate in this logic, since they are not a crypto destination.

Withdrawals executed through an Internal OTC Connection automatically inherit the declaration already made on that connection — no separate declaration is required for each destination address generated in these operations.

Required action

Whitelist addresses and connections registered before this functionality continue to exist normally, but can no longer be used as a withdrawal destination until the declaration is provided. 

The Instance Administrator should review the Terminal Whitelist and the counterparty Connections; the white-label end client should review their own Withdraw Addresses. In both cases, enrichment is done directly on the destination that is already registered, with no need for a full re-registration.

Rules and limits

Frequently asked questions

Why can't the declaration be changed once it's set? Because it feeds a report with regulatory weight. Allowing an in-place edit would open the possibility of a retroactive reclassification with no clear trail of why. Requiring the destination to be recreated (re-registration or reconnection) ensures that any classification change is tied to a new destination, with its own audit trail.

Why don't addresses and connections that already exist receive the declaration automatically? Because the self-custody information does not exist in historical data — inferring it would mean guessing, not declaring. It is up to the instance, or to the end client in the case of white-label, to explicitly provide this qualification for each destination already registered, before using it again in withdrawals.

Why does the API flow allow withdrawals without the declaration, while the interface blocks them? Because the block exists to protect the self-service flow, where the end user declares in real time. In API integrations, the Parfin client controls the registration and can choose to manage this enrichment with their own logic; the Platform reflects the gap in the report instead of imposing a rigid block on a flow it does not control directly.

Does a withdrawal via Internal OTC require its own declaration for each destination address generated? No. These addresses automatically inherit the declaration already made on the counterparty's connection, because in this case self-custody is a characteristic of the relationship with the counterparty — not of each individual operation.

See also

IN2991 (DeCripto): New Information in the RFQ Funding Report — how this declaration feeds the RFQ Funding report and the construction of the DeCripto. (link to be updated once the article is published on the Support Portal)