B.BlockAxis⌕ Search
Menu

Provider due diligence and exit planning

A provider assessment should follow the service dependency rather than its product name.

AdvancedContent revised · 14.09.20263 min reading · allow 5–10 more minutes for the workshopBlockAxis

Your learning plan

Prove portability rather than assume it

By the end, explain the diagram in your own words, solve the case and justify the correction.

Prerequisites : Digital asset custody: beyond key storage · MPC wallets and threshold signing

Level 3 · Advanced →

Reading path · 14 / 17 · Advanced

Key takeaway

A provider assessment should follow the service dependency rather than its product name.

The essentials

A provider assessment should follow the service dependency rather than its product name. Identify which party controls signing, policy administration, data access and recovery. Include subcontractors and shared infrastructure where their failure could affect the service. A contract description is a starting point for verification, not the test result.

How it works

An exit plan distinguishes access to records from the ability to operate assets elsewhere. Exported statements may support reconciliation while remaining insufficient to reconstruct wallet policy or signing capability. Specify formats, dependencies, personnel and expected transfer durations.

What to watch

Test both an orderly migration and a stressed exit where the provider is unavailable. Keep dual-running reconciliation, cancellation rules for pending requests and a controlled cut-over. Exit readiness needs periodic reassessment when keys, contracts, infrastructure or service scope change.

Build your analysis

Data portability and operational portability answer different questions. A file may preserve balances while leaving the institution unable to sign, identify client entitlements or monitor pending transfers independently. Trace dependencies on provider software, authentication, key shares, network access and contract administration. Ask which dependencies remain after the service contract ends.

Extend the workshop

Draft an exit rehearsal with a limited fictional asset set. State the starting balances, destination arrangements, permissions, records and acceptance checks. Run two narratives: a cooperative migration and an unavailable provider. A successful export in the first narrative is not evidence that signing or recovery works in the second.

Understand the details

A test report should state exactly what was recovered, by whom, using which independent resources and in how much time. A provider-assisted demonstration does not establish recovery without that provider. Document remaining dependencies so decision makers can assess the residual exposure.

Boundaries and common mistakes

Do not copy real signing secrets into an exercise document. Use a controlled test arrangement and retain attestations or results rather than confidential key material.

The mechanism at a glance

  1. Map dependency
  2. Define exit evidence
  3. Test unavailability
  4. Reconcile migration
Prove portability rather than assume it. Conceptual map: read these four landmarks together with the explanation above.
Applied workshop · work at your own pace

Apply the lesson to a case

A fictional provider offers daily CSV balances and promises “full portability”. Your institution cannot recreate signing policy without a service it hosts. Compare the evidence for data portability and operational exit. Define a test that would expose the dependency.

Does a balance export prove operational exit capability?

Choose one answer.

Prepare a correction note

Describe the passage and the proposed correction. This creates a local note for you to share; it sends nothing. Do not include personal or confidential information.