The BE Custody Address Book allows your organisation to securely manage whitelisted destinations for digital assets and automate compliance requirements like Anti-Money Laundering (AML) Travel Rule pre-filling.
Following our migration to the upgraded Address Book V2 service, several powerful new foundational features, structural chain updates, and enhanced security governance policies are now available.
Key Features & Rules of Address Book V2
Multiple Address Books: Your organization is no longer restricted to a single address book. You can now create multiple distinct address books and restrict them to specific wallets, or apply them globally across your entire account.
Wallet-Level Aggregation: If a wallet is assigned to multiple address books, BE Custody automatically aggregates all valid entries when performing transaction whitelist checks. If identical addresses exist across books, the system defaults to the most recently updated entry.
Batching Requests: You can batch up to 25 creation or deletion changes together inside a single change request to streamline administrative tasks.
No Ongoing Overlaps: To ensure security and prevent conflicting instructions, only one pending change request is permitted per address book at a time.
No Duplicates: The system strictly prevents the creation of duplicate entries sharing the same address, book ID, chain, and memo.
Modifying Entries ("No Direct Edits"): To maximise audit security, address book entries cannot be directly edited. To update an existing entry, simply batch a deletion of the old record and a creation of the new record together in a single request.
Address Book Fields Guide
When creating or referencing an address book entry via the BE Custody Web interface or API, the following fields apply:
| Field Name | Required | Description & Rules |
|---|---|---|
| Name | Yes | A unique identifier for the entry. Maximum 100 characters. |
| Address | Yes | The destination blockchain address. This must be structurally valid for your chosen chain. |
| Chain | Yes | Crucial Update: The legacy |
| Label | No | An optional internal note or description for the entry. Maximum 100 characters. |
| Memo | No | An additional destination tag. Currently, this applies to |
| Type | Yes | Must be supplied as an array • • |
| Counterparty | Conditional | Mandatory if the Type includes |
Advanced Security & Governance Approvals
Whenever changes are made to an address book (such as adding new whitelisted addresses or removing old ones), the updates must clear a predefined approval workflow before they take effect. Your organization can choose between three distinct approval settings:
1. Cryptographic Wallet Policy (WALLET)
For institutional-grade security, you can link an address book directly to a designated governance or admin wallet ID.
How it works: Any addition or deletion triggers a "change request" that must be approved and signed directly on-chain.
Cryptographic Proof: The proposed changes will remain pending and will only execute once your specific wallet policy or delegate schedule is completely satisfied. For example, if your governance wallet is secured by a 2-of-3 multi-sig layout, at least 2 authorized key-holders must cryptographically sign the request via the iOS app before the address book updates.
2. Email Approval Quorums (EMAIL)
If your team prefers an administrative workflow handled outside of cryptographic wallet keys, you can implement an email approval chain.
How it works: Modifications send out broadcast alerts to a pre-configured list of administrator emails.
Quorum Requirements: This workflow supports flexible thresholds. You can set a simple quorum requiring a specific ratio of team members to click accept (e.g., requiring 2 out of 5 listed admins to confirm) before the updates are automatically applied.
3. Immediate Execution (NONE)
If no safety workflow is enabled, changes made to the address book are executed immediately without any secondary verification layers.
⚠️ Security Note for Administrators
While full self-service address book change requests can be managed via the iOS app, certain global configuration changes must be routed through Support. For instance, if your organisation wishes to enforce a blanket rule mandating that all newly created address books must use a specific governance wallet for approval, this restriction must be implemented by a TrustOperator on your behalf.
Restricted Environments (Whitelist Only Mode)
For organisations requiring tight security perimeters, Support can toggle a dedicated backend feature flag for your platform layout called allowListOnlyEnabled.
When this feature flag is set to true, standard users inside your organisation are completely locked out from inputting custom, ad-hoc destination addresses when constructing a transaction. Instead, they are strictly forced to select from a verified dropdown list populated entirely by your pre-approved, authorised address books.