Scoutinternal

Transaction and User Approvals on BitGo Wallets

Transaction and User Approvals on BitGo Wallets

Problem

Customers frequently contact BitGo Support requesting that pending transactions be approved, that user accounts or organizations be approved (including Civic identity verification), or that approval policies be modified (e.g., changing the number of required approvers, adding/removing final approvers, or updating the list of video-verified users on an enterprise). These requests span custody wallets, self-managed hot/cold wallets, and enterprise-level user management. Customers may also ask about historical approval records, mobile approvals, or how the approval process works in general.

Diagnostics

  • Identify the type of approval request. Determine whether the customer is asking about:
    • A pending transaction approval (send, issuance, cold transaction signing)
    • A user/organization approval (adding new users, Civic app verification, video ID verification)
    • A policy change (updating number of required approvals, adding/removing a final approver)
    • A user update on an enterprise (removing users, changing video ID users)
  • Check the enterprise and wallet context. Open the enterprise in the admin tool using the enterprise ID. Confirm which wallets are affected and what policies are currently in place.
  • Check pending approvals. In the BitGo admin tool or UI, review the Pending Approvals list for the relevant wallet or enterprise to see if there are outstanding items awaiting action.
  • Check wallet policy configuration. Review the wallet's policy settings, including:
    • Number of required approvals for transactions
    • Whether a final approver is configured
    • Which users are designated as admins, spenders, or viewers
  • Confirm user roles. Verify which users are enterprise admins, wallet admins, or final approvers. Policy changes require approval from other enterprise or wallet admins.
  • For user update requests (add/remove users, video ID changes): Confirm the request is authorized by an enterprise admin or authorized contact (e.g., CFO). Check if a wallet ID list is needed for removal requests scoped to specific wallets.

Resolution

Scenario: approvals-approval-approve-final#pending-tx-approval

Trigger: Customer requests that BitGo approve or cosign a pending transaction (send, issuance, cold transaction).

Signals: approve tx, pending approval, issuance tx, cold tx, please approve, approval required, urgent approval

Steps:

  1. Confirm the customer's identity and enterprise context.
  2. Locate the pending transaction in the admin tool under the relevant wallet's Pending Approvals.
  3. Verify that all required approvals from wallet admins and/or final approvers have been obtained. BitGo cosigns only after all required approvals are satisfied.
  4. If the transaction is pending because it violates a wallet policy, inform the customer that a wallet administrator must approve the policy exception before BitGo can cosign.
  5. If a final approver is configured on the wallet, remind the customer that the final approver must also approve the transaction even after admin approval.
  6. Once all approvals are in place, BitGo will cosign automatically. No manual action from BitGo Support is typically required unless there is a system issue.

Notes: BitGo does not manually approve customer transactions on their behalf. The approval must come from the customer's own designated approvers. If the customer believes the approval flow is stuck, escalate to engineering.

Scenario: approvals-approval-approve-final#user-enterprise-update

Trigger: Customer requests adding or removing users from an enterprise, or updating which users are video ID verified.

Signals: user update, remove user, add video user, video ID, enterprise user, remove from enterprise

Steps:

  1. Confirm the request is authorized by an enterprise admin or authorized signatory (e.g., CFO or equivalent).
  2. For user removal: Request the list of affected wallet IDs if the removal is scoped to specific wallets. Process the removal in the admin tool.
  3. For adding new video ID users: The new users must complete a video conference with BitGo for identity verification. Direct them to schedule using the KYC Calendly link: https://calendly.com/bitgo-client-delivery/kyc
  4. An authorized contact from the enterprise (e.g., CSM or enterprise admin) must be on the video call with the new users.
  5. Confirm completion of the removal and inform the customer. For additions, confirm once the video ID session is completed and the users are added.

Notes: If the request involves unlocking a wallet policy, a separate video ID verification is required using: https://calendly.com/bitgo-client-delivery/videoid. The customer should reference their ticket number when scheduling.

"To add Doroteja and George as video users, they will need to meet over video with us. Please use the following link to schedule a time for this: https://calendly.com/bitgo-client-delivery/kyc We will need you on the call with them." (ticket #217805)

"We have received your request to unlock your wallet policy. For security purposes, we will need to schedule a video conference to verify your Identification. Please use the following link to schedule a time to meet with us and verify the request: https://calendly.com/bitgo-client-delivery/videoid" (ticket #217805)

Scenario: approvals-approval-approve-final#civic-app-approval

Trigger: Customer requests approval or verification of their Civic app identity so they can access the platform (e.g., webdev environment).

Signals: civic, civic app, civic approval, civic verification, access webdev

Steps:

  1. Confirm the customer's enterprise and the specific environment they are trying to access.
  2. Check whether the user's Civic identity verification is pending in the admin tool.
  3. If the Civic verification is pending, process the approval in the admin tool.
  4. Notify the customer once the Civic approval is complete so they can proceed with access.

Notes: Civic-based approvals were part of an older identity verification flow. If the customer is on a newer enterprise setup, they may need to use the current video ID process instead.

Scenario: approvals-approval-approve-final#policy-change-approvals

Trigger: Customer asks how to change the number of required approvals, add/remove a final approver, or modify approval policies on a wallet.

Signals: number of approvals, change approvals, final approver, approval policy, update policy, dual approvals, approval process

Steps:

  1. Explain that approval thresholds and final approver settings are configured in the wallet's policy settings within the BitGo UI.
  2. Any policy change requires approval from other wallet or enterprise admins. Only one in-progress policy change is allowed at a time.
  3. To add a final approver: open the wallet settings, navigate to the final approval section, select a user from the drop-down menu, click "add as approver," then click "save."
  4. A final approver must approve every send transaction on that wallet, regardless of whether it violates a policy. This is different from a wallet administrator, who only needs to approve transactions that violate policies.
  5. If the enterprise has only one admin on the wallet, that admin can configure policies without requiring additional approvals.
  6. If the customer wants to update the required number of approvals, remind them the setting must be n - 1 relative to the number of admins, and if admins are removed below that threshold, policy updates will be automatically rejected.

Notes: V1 wallets are not supported in the new Policy Engine. Policies for V1 wallets must be managed on the V1 wallet policies page. "All Wallets" policies also do not cover V1 wallets.

Scenario: approvals-approval-approve-final#historical-approval-view

Trigger: Customer asks to view historical approvals or past approval records for their wallet or enterprise.

Signals: historical approval, past approvals, approval history, approval view

Steps:

  1. Direct the customer to the Approvals section in the BitGo UI for the relevant wallet or enterprise.
  2. If the UI does not display sufficient historical data, check the admin tool for audit logs related to the enterprise or wallet.
  3. If further historical records are needed beyond what is available in the UI or admin tool, escalate to engineering for a data pull.

Notes: The depth of historical approval data visible in the UI may vary. Enterprise admins generally have broader visibility than wallet-level users.

Related

  • final-approval — Explains the final approver role and how it differs from wallet admin approval
  • policy-structure — Covers the four parameters of wallet policies including approval actions
  • policies-faqs — Answers common questions about policy changes, required approvals, and admin thresholds