The Threshold Co-Signing Service (TCSS) is a Bitpanda Enterprise Custody capability that can contribute an approval signature to a transaction when predefined transaction rules are satisfied.
TCSS is designed to support controlled automation of transaction approvals. For example, an institution may configure a workflow where lower-value transactions to approved destinations can receive a TCSS approval, while transactions outside those conditions require a different approval path.
TCSS operates alongside the wallet policy. It does not replace the wallet policy and cannot independently approve or complete a transaction.
How TCSS works
At a high level:
Transaction created
→ TCSS evaluates configured rules
→ Rules pass
→ TCSS contributes its approval signature
→ Remaining wallet-policy approvals are evaluated
→ Transaction proceeds only if the full wallet policy is satisfied
If the configured TCSS conditions are not satisfied, TCSS does not contribute its signature.
TCSS and the wallet policy
The distinction between wallet policy and TCSS rules is important.
Wallet policy
The wallet policy defines who or what is authorised to contribute approval signatures and the combination of approvals required for a transaction.
Depending on the configured model, this can include customer-controlled signers, delegated signers and TCSS.
TCSS rules
TCSS rules define the conditions under which TCSS is permitted to contribute its approval signature.
For example, TCSS may be configured to sign only when:
- the destination is approved;
- the transaction is below a defined value;
- the transaction is an approved internal transfer;
- the asset or transaction type is permitted; or
- a combination of configured conditions is satisfied.
The wallet policy therefore defines the approval structure, while TCSS rules determine whether TCSS can participate in that structure.
TCSS cannot approve a transaction alone
TCSS is a delegated approval mechanism, not an independent transaction authority.
TCSS can contribute an approval signature only when:
- its signing key has been explicitly included in the wallet policy;
- the configured TCSS rules are satisfied; and
- the other approvals required by the wallet policy are also provided.
BE Custody does not configure wallet policies so that TCSS alone can satisfy the approval requirement for a transaction.
For example, a wallet policy could require:
Customer approval + TCSS approval
TCSS may provide its signature when the configured rules pass, but the transaction still cannot proceed without the required customer approval.
What rules can TCSS evaluate?
TCSS can support different types of transaction controls according to the customer's agreed configuration.
Approved destination rules
TCSS can evaluate whether a transaction is being sent to an approved destination.
If the destination does not satisfy the configured rule, TCSS does not provide its signature.
Threshold rules
TCSS can apply value-based approval logic.
For example, a workflow could permit TCSS co-signing below a configured threshold while requiring a different approval path for higher-value transactions.
Internal transfer rules
TCSS can support controlled automation for transfers between recognised wallets or addresses belonging to the same organisation.
This can be useful for activities such as treasury rebalancing and movement between operational wallet structures.
Combined rules
Multiple conditions can be evaluated together.
For example:
Destination is approved AND transaction value is below the configured threshold
Both conditions must be satisfied before TCSS contributes its approval signature.
Why use TCSS?
Without automated co-signing, routine transactions may require the same manual approval process regardless of their context.
TCSS allows institutions to apply a more granular approval model.
Typical use cases include:
- low-value operational transfers;
- transfers to approved destinations;
- internal treasury movements;
- wallet rebalancing;
- controlled asset consolidation; and
- other clearly defined transaction workflows.
This can reduce manual approval effort for predefined transaction flows while retaining stronger approval requirements for transactions outside those conditions.
Where are TCSS rules evaluated?
TCSS business rules are evaluated outside the HSM.
This is intentional because transaction rules can require contextual information such as:
- destination-address information;
- approved-destination configuration;
- wallet ownership information;
- transaction value;
- asset type; and
- customer-specific operational rules.
The HSM provides a different function: it protects custody-key operations and provides the final cryptographic enforcement boundary.
Keeping these functions separate allows configurable transaction rules to operate alongside the cryptographic controls governing final custody-key use.
TCSS approval and final blockchain signing are different
A TCSS approval signature is not the final blockchain signature.
TCSS contributes an approval within the applicable wallet policy.
Once the complete wallet policy has been satisfied, the transaction can continue through the custody workflow towards HSM validation and final blockchain signing.
In simplified terms:
TCSS approval signature ≠ custody-key signature ≠ final blockchain signature
TCSS does not hold or expose the blockchain custody key.
What happens when a rule does not pass?
If the configured TCSS conditions are not satisfied, TCSS does not contribute its approval signature.
What happens next depends on the configured wallet policy and transaction controls.
For example, the transaction may:
- remain pending for another required approval;
- fail to satisfy the applicable policy; or
- be cancelled where automatic cancellation has been configured.
TCSS does not bypass a failed rule or independently override the wallet policy.
How are TCSS rules changed?
TCSS configuration is managed through controlled operational processes.
Changes can include:
- adding or removing an approved-destination rule;
- changing value thresholds;
- modifying internal-transfer behaviour;
- changing the wallets to which rules apply; or
- changing configured cancellation behaviour.
Because these changes can affect when TCSS contributes an approval signature, institutions should treat them as sensitive operational changes and apply appropriate internal review and governance.
Key security principles
The TCSS model is based on several important principles:
- TCSS cannot approve or complete a transaction on its own.
- TCSS does not replace the wallet policy.
- TCSS can contribute a signature only when its signing key is included in the wallet policy.
- Configured TCSS rules must pass before TCSS contributes its signature.
- The other approvals required by the wallet policy must still be provided.
- TCSS does not bypass customer approvals.
- Business-rule evaluation is separate from HSM cryptographic enforcement.
- Final blockchain signing remains a separate custody-key operation.
Further information
For more information about transaction rules, approval workflows and final signing, see: