BE Custody Wallet Capabilities, Spending Rules, and Threshold Sending Rules

Overview

BE Custody supports configurable transaction controls that help customers define when a transaction can be approved automatically and when additional manual approval is required.

These controls are commonly used to support operational workflows such as:

• Allowing transfers only to approved addresses.
• Supporting internal transfers between wallets belonging to the same organisation.
• Applying value-based approval thresholds.
• Reducing manual approval effort for low-risk activity.
• Preventing or cancelling transactions that do not meet the configured rules.

The rules described in this article are evaluated by BE Custody’s co-signing capability. This service works alongside the wallet policy configured for a BE Custody wallet.

The co-signing service does not replace the wallet policy. It can only participate where its signing key has been explicitly included in the wallet policy approved for that wallet.

Relationship Between Wallet Policies and Rules

BE Custody separates two concepts:

Wallet Policy

A wallet policy defines which signers are required to approve a transaction.

The wallet policy may include:

• Customer-controlled signers.
• API-based signers.
• Delegated signers.
• BE Custody co-signing capability, where agreed with the customer.

Wallet policies are part of the wallet’s core authorisation model. They define who or what can contribute a valid approval signature.

Rules

Rules define the conditions under which the co-signing service may contribute its signature.

Examples include:

• The destination address must be approved.
• The transaction must be below a defined value.
• The transaction must be an internal transfer.
• The asset or transaction type must be permitted for that wallet.

This separation allows customers to define flexible operational rules without requiring a full wallet policy change each time a business rule needs to be updated.

Important Principle: TCSS Cannot Approve a Transaction Alone

TCSS cannot approve or complete a transaction by itself.

TCSS can only contribute one approval signature where:

- The TCSS signing key has been explicitly included in the wallet policy; and
- The configured TCSS rules have been satisfied; and
- The wider wallet policy still receives the other required approvals.

A TCSS signature is therefore only one part of the overall approval process. It does not override the wallet policy, bypass customer approvals, or provide independent access to customer wallets.

BE Custody does not configure wallet policies so that TCSS alone can satisfy the approval requirement for a transaction. A valid transaction must still meet the full wallet policy, including the required customer-side approval or approvals.

For example, where a policy requires both a customer approval and a TCSS approval, TCSS may sign only if the configured rules pass, but the transaction cannot proceed unless the customer-side approval is also provided.

Wallet Capabilities

Wallet capabilities define what a wallet is allowed to do.

They may be used to control whether a wallet can perform certain types of activity, such as:

• Sending transactions.
• Receiving assets.
• Sending to approved addresses only.
• Sending to internal wallets only.
• Interacting with specific asset types.
• Supporting token transfers.
• Supporting contract-related activity, where applicable.

Wallet capabilities help ensure that a wallet is used only for its intended operational purpose.

For example, a wallet intended only for treasury consolidation may be configured differently from a wallet intended for customer withdrawals.

Spending Rules

Spending rules allow transaction approval logic to be based on transaction value.

A spending rule may be used to define whether the co-signing service should approve a transaction below a specific value threshold.

Example use cases include:

• Automatically co-signing low-value operational transfers.
• Requiring additional human approval for higher-value transfers.
• Blocking or cancelling transactions above a configured maximum value.
• Applying different approval behaviour to different wallets or assets.

Spending rules can help reduce operational effort while maintaining stronger controls for higher-risk transactions.

Threshold Sending Rules

Threshold sending rules allow different behaviour depending on the value of the transaction.

For example:

The exact thresholds and behaviour depend on the customer’s approved configuration.

Threshold sending rules are useful where customers want to apply risk-based approvals instead of using the same approval requirement for every transaction.

Address Book Rules

Address book rules allow customers to restrict transactions to approved destination addresses.

When an address book rule is configured, the co-signing service evaluates whether the transaction destination matches the customer’s approved address controls.

If the destination does not satisfy the relevant address book rule, the co-signing service will not provide its signature.

Depending on configuration, the transaction may either:

• Remain pending for other required approvals.
• Fail to meet the required policy.
• Be cancelled automatically.

Approved Address Controls

Address book rules may be used to support controls such as:

• Only send to pre-approved external addresses.
• Only send to addresses associated with the customer’s organisation.
• Only send to addresses associated with specific wallets.
• Restrict transfers by asset, wallet, or transaction type.

These controls are designed to reduce the risk of assets being sent to unauthorised destinations.

Token Transfer Considerations

For token transfers, there may be more than one relevant address involved in the transaction.

For example, a token transfer may involve:

• The token contract address.
• The final recipient address.

Where applicable, the rule evaluation process may check the relevant addresses required for that transaction type.

This helps ensure that token transfers are evaluated against the intended approval rules and not only against the outer transaction structure.

Internal Transfer Rules

Internal transfer rules are used where a customer wants to permit automated co-signing for transfers between wallets or addresses belonging to the same organisation.

Instead of requiring every internal destination address to be manually maintained in a static list, internal transfer rules can evaluate whether the destination address is recognised as belonging to the customer’s organisation.

This can support workflows such as:

• Treasury rebalancing.
• Movement of assets between operational wallets.
• Transfers between warm and cold wallet structures.
• Internal settlement activity.
• Customer-controlled wallet consolidation.

Dynamic Internal Address Recognition

Dynamic internal address recognition is used to determine whether a destination address is associated with the relevant customer organisation.

At a high level, the process checks whether:

• The destination address is known to BE Custody.
• The address is associated with the correct customer organisation.
• The address was generated or registered through the expected BE Custody workflow.
• The address has the expected provenance metadata.

If these checks pass, the destination may be treated as an internal address for the purposes of the configured rule.

If the checks do not pass, the co-signing service will not treat the destination as an approved internal address. NB This feature is currently under development.

Address Provenance

Address provenance refers to information that helps confirm where an address came from and how it became associated with a customer’s wallet structure.

Provenance checks help distinguish between:

• Addresses generated or registered through approved BE Custody workflows.
• Addresses that are not recognised as belonging to the customer.
• Addresses that do not have sufficient supporting metadata.

This is particularly important for internal transfer rules, where the system needs to determine whether a destination address should be treated as part of the customer’s own wallet estate.

How Rule Evaluation Works

The following is a simplified description of the rule evaluation flow.

1. A transaction is created.
2. The transaction reaches the point where policy approvals can be evaluated.
3. The co-signing service receives a transaction event.
4. The service identifies the source wallet.
5. The service loads the rules configured for that wallet.
6. The service evaluates the transaction against those rules.
7. If the configured rule conditions are met, the service contributes its signature.
8. The transaction continues through normal wallet policy evaluation.
9. If the overall wallet policy is satisfied, the transaction can proceed.
10. If the policy is not satisfied, the transaction does not proceed.

The co-signing service only contributes a signature where the relevant rule conditions are met.

Example Rule Scenarios

Example 1: Approved Address Transfer

A wallet is configured so that the co-signing service may sign only when the destination address is in the approved address book.

If the destination address is approved, the co-signing service may sign.

If the destination address is not approved, the co-signing service will not sign.

Example 2: Internal Transfer

A wallet is configured so that the co-signing service may sign only for internal transfers.

If the destination address is recognised as belonging to the same customer organisation, the co-signing service may sign.

If the destination address is external or cannot be validated as internal, the co-signing service will not sign.

Example 3: Low-Value Transfer

A wallet is configured so that the co-signing service may sign transactions below a defined value.

If the transaction value is below the configured threshold, the co-signing service may sign.

If the transaction value is above the threshold, the co-signing service will not sign and additional approval may be required.

Example 4: Combined Address and Value Rule

A wallet is configured so that the co-signing service may sign only when:

• The destination address is approved; and
• The transaction value is below the configured threshold.

Both conditions must be satisfied before the co-signing service signs.

Transaction Cancellation

Some configurations may allow a transaction to be cancelled automatically when it does not meet the configured rules.

This can be useful where the customer wants failed rule checks to act as a hard control rather than allowing the transaction to remain pending.

For example:

• A transaction to an unapproved destination may be cancelled.
• A transaction above a permitted threshold may be cancelled.
• A transaction that does not match the permitted wallet capability may be cancelled.

Automatic cancellation behaviour must be agreed as part of the customer’s configuration.

Rule Configuration and Change Management

Rule configuration is managed through controlled operational processes.

The customer defines the intended rule behaviour, and BE Custody configures the rules in line with the agreed setup.

Changes to rules should be treated as sensitive operational changes because they can affect when the co-signing service contributes a signature.

Rule changes may include:

• Adding or removing an address book rule.
• Changing spending thresholds.
• Enabling or disabling automatic cancellation.
• Updating internal transfer behaviour.
• Changing which wallets a rule applies to.

Rule changes are subject to appropriate review and approval processes.

Customer Responsibilities

Customers are responsible for:

• Reviewing and approving their wallet policy structure.
• Understanding where co-signing is included in the approval model.
• Defining the intended rule behaviour.
• Ensuring that authorised administrators understand the impact of rule changes.
• Maintaining appropriate internal governance for address approvals.
• Reviewing any requested configuration changes before approval.

Customers should ensure that co-signing rules align with their own internal risk appetite and approval procedures.

BE Custody Responsibilities

BE Custody is responsible for:

• Operating the co-signing capability.
• Applying agreed rule configurations.
• Maintaining appropriate operational controls.
• Supporting address book and wallet capability rule evaluation.
• Ensuring that rule changes follow controlled procedures.
• Supporting customers in understanding the available configuration options.

Security Model

The co-signing service is designed as a delegated approval mechanism.

It is intentionally separate from the HSM-based wallet policy layer because business rules often need to evaluate transaction context that is not suitable for direct HSM evaluation.

For example, business rules may need to consider:

• Destination address metadata.
• Address book configuration.
• Wallet ownership metadata.
• Transaction value.
• Asset type.
• Customer-specific operational rules.

The HSM signs cryptographic payloads. It does not normally evaluate complex business context such as address books, organisational wallet relationships, or fiat value thresholds.

Keeping rule evaluation outside the HSM allows rules to be maintained and adapted more flexibly while still requiring the wallet policy to determine whether enough valid approvals have been provided.

Key Security Principles

The following principles apply to the co-signing model:

• TCSS cannot approve or complete a transaction on its own.
• BE Custody does not configure wallet policies so that TCSS alone can satisfy the transaction approval requirement.
• TCSS can only contribute a signature if its signing key has been explicitly included in the wallet policy.
• A TCSS signature only has effect where the wallet policy recognises TCSS as an eligible signer.
• The transaction must still satisfy the full wallet policy, including the required customer-side approval or approvals.
• TCSS does not override the wallet policy, bypass customer approvals, or provide unrestricted access to customer wallets.
• Rule evaluation is performed before TCSS contributes a signature.
• Transactions that do not meet the configured rules are not co-signed by TCSS.
• The wallet policy remains the final approval structure.
• Rule configuration is controlled through operational governance.
• Address book and internal address rules rely on recognised wallet and address metadata.

Limitations

Customers should understand the following limitations:

• Rules are not the same as wallet policies.
• Rule changes do not necessarily require a wallet policy update.
• The co-signing service evaluates configured business logic outside the HSM.
• Internal transfer recognition depends on BE Custody metadata and address provenance.
• The co-signing service only evaluates the rules that have been configured for the wallet.
• A transaction may still require other approvals depending on the wallet policy.

Recommended Use

These rules are most useful where a customer wants to automate clearly defined, lower-risk transaction flows.

Recommended use cases include:

• Internal wallet transfers.
• Low-value operational movements.
• Transfers to approved destinations.
• Treasury consolidation.
• Controlled rebalancing workflows.
• Asset movement within a known wallet estate.

They are not a replacement for customer governance, wallet policy design, or manual approval for higher-risk activity.

Summary

BE Custody wallet capabilities, spending rules and threshold sending rules provide customers with flexible controls over when transactions may be co-signed automatically.

The rules allow customers to define conditions such as:

• What a wallet is allowed to do.
• Which addresses are approved.
• Whether a destination is internal.
• Whether a transaction is below a value threshold.
• Whether a transaction should be cancelled if rules are not met.

The co-signing service supports operational efficiency by reducing manual approval requirements for transactions that meet predefined criteria, while the wallet policy remains the core approval mechanism for determining whether a transaction can proceed.