Bitpanda Enterprise Custody uses wallet policies and configurable transaction controls to govern how transactions are authorised and when they can proceed towards final blockchain signing.
The wallet acts as the primary governance and signing-policy boundary. It defines the applicable approval requirements, while additional transaction controls can apply conditions such as approved destinations, value thresholds and time delays.
These controls operate together to support institutional transaction governance without exposing or transferring control of the underlying custody key.
Wallet policy as the governance boundary
with:
At a high level, the custody structure follows:
Organisation → Wallet → Sub-wallets
The organisation provides the wider user and access-governance context.
The wallet defines the applicable transaction-authorisation and signing-policy controls.
Sub-wallets sit beneath the wallet and provide blockchain- or asset-specific segregation while operating within the applicable wallet governance model.
Wallet governance can be considered through four questions.
Who can approve?
The wallet policy defines the approval structure required for transactions.
This can include:
- quorum or multi-party approval requirements; and
- role-based approval structures.
A transaction must obtain the approvals required by the applicable wallet policy before it can proceed towards final signing.
What can be approved?
Additional controls can apply conditions to transactions.
Depending on the configured operating model, these can include:
- transaction-value thresholds;
- asset-specific controls; and
- other configured transaction conditions.
These controls can be used to apply different approval behaviour to different transaction scenarios.
Where can assets be sent?
Destination controls can restrict where transactions may be sent.
The Address Book can be used to define approved destinations and support transaction workflows where destination approval forms part of the transaction-control model.
When can a transaction execute?
Time-delay controls can introduce an additional review period before execution.
This provides an additional control between transaction authorisation and execution where configured.
From wallet policy to final signing
Wallet policy forms part of a wider transaction-authorisation process.
At a high level:
Transaction
→ Wallet Policy
→ Required Approvals
→ HSM Validation
→ Final Blockchain Signing
The wallet policy determines the applicable authorisation requirements.
Once those requirements have been satisfied, the transaction can proceed towards the cryptographic enforcement stage.
The HSM then validates the transaction, applicable wallet policy and required cryptographic approvals before custody-key use and final blockchain signing.
This separation means that transaction governance and final cryptographic signing are distinct control layers.
Wallet policy and transaction controls
It is important to distinguish between the wallet policy and the additional rules that can form part of the transaction workflow.
Wallet policy
The wallet policy defines the cryptographic approval structure governing the wallet.
It determines which authorised signing entities can contribute approvals and what combination of approvals is required.
For example, a policy may require approval from multiple authorised participants before a transaction can proceed.
Transaction controls
Transaction controls evaluate additional conditions surrounding the transaction.
These can include contextual information such as:
- destination;
- transaction value;
- asset;
- wallet relationship; and
- other configured transaction conditions.
These controls can influence the approval path but do not replace the underlying wallet policy.
Spending rules
Spending rules allow additional controls to be applied according to transaction value or other configured conditions.
For example, an institution may configure different approval requirements for routine operational transactions and higher-value transactions.
This allows the approval model to reflect the risk or operational significance of the transaction rather than applying an identical workflow to every transaction.
Threshold sending rules
Threshold sending rules apply value-based conditions to transaction workflows.
For example:
Below a configured threshold
A transaction may follow a predefined approval path.
Above a configured threshold
Additional approvals or a different transaction workflow may be required.
The exact thresholds and approval behaviour depend on the configured wallet and transaction-control model.
Threshold rules do not replace wallet policy. They determine which configured approval path applies to the transaction.
Approved-destination rules
Destination controls can be used to determine whether a transaction is being sent to an approved address.
Where configured, the Address Book provides the approved-destination information used by the transaction workflow.
A rule can therefore distinguish between:
- transactions to approved destinations; and
- transactions to destinations that have not been approved.
Different approval requirements can then be applied according to the configured policy and transaction controls.
Internal transfer rules
Transaction controls can also identify recognised internal transfers.
These can include transfers between wallets or addresses belonging to the same organisation.
Internal-transfer rules can support controlled automation for activities such as:
- treasury movements;
- wallet rebalancing;
- asset consolidation; and
- transfers between operational wallet structures.
The applicable approval requirements remain determined by the configured wallet policy and transaction controls.
Combining transaction rules
Transaction controls can evaluate more than one condition.
For example:
Destination is approved AND transaction value is below the configured threshold
The configured workflow can require both conditions to be satisfied before the corresponding approval path applies.
This allows institutions to create more granular transaction-control models than a single value or destination check.
Using TCSS with transaction rules
The Threshold Co-Signing Service (TCSS) can be used to contribute an approval signature when configured transaction rules are satisfied.
TCSS operates alongside the wallet policy.
For example, a wallet policy could require:
Customer approval + TCSS approval
TCSS may contribute its approval signature when its configured rules pass, but the other approvals required by the wallet policy must still be provided.
TCSS rules can evaluate conditions such as:
- approved destinations;
- value thresholds;
- recognised internal transfers; and
- combinations of configured transaction conditions.
TCSS does not replace the wallet policy and does not perform final blockchain signing.
For a detailed explanation, see What is the Threshold Co-Signing Service (TCSS)?
Where are transaction rules evaluated?
Contextual transaction rules are evaluated outside the HSM.
This is because these rules can require information such as:
- destination-address information;
- approved-destination configuration;
- wallet ownership;
- transaction value;
- asset information; and
- other operational context.
The HSM has a different responsibility.
It provides the final cryptographic enforcement boundary, validating the cryptographic conditions required before custody-key use.
This separation allows configurable business and transaction controls to operate alongside protected cryptographic signing.
What happens when a rule is not satisfied?
The outcome depends on the applicable wallet policy and configured transaction workflow.
Depending on the configuration, a transaction may:
- require another approval;
- remain pending;
- fail to satisfy the applicable transaction policy; or
- be cancelled where automatic cancellation behaviour has been configured.
A transaction rule does not independently override the wallet policy.
Changing wallet policies and transaction rules
Changes to wallet policies and transaction controls can affect how transactions are authorised.
Examples include:
- changing approval requirements;
- changing approval quorums;
- adding or removing destination rules;
- changing transaction thresholds;
- modifying time-delay controls;
- changing internal-transfer rules; or
- changing the wallets to which particular controls apply.
Institutions should therefore treat these as sensitive operational changes and apply appropriate internal review and governance.
Where a change affects cryptographically governed wallet policy, the applicable policy-change and approval process must also be completed.
Key principles
The important distinctions are:
- The wallet is the primary governance and signing-policy boundary.
- Wallet policy defines the required approval structure.
- Transaction controls apply contextual conditions to the transaction workflow.
- Approved destinations, thresholds and time delays can influence the applicable approval path.
- TCSS can contribute an approval signature where configured rules permit it.
- TCSS does not replace the wallet policy.
- Contextual business-rule evaluation is separate from HSM cryptographic enforcement.
- Required approvals must be satisfied before final custody-key use.
- Final blockchain signing remains a separate HSM-protected cryptographic operation.
Further information
For more information about wallet structure, approvals and transaction controls, see: