That modularity is useful, but it creates a problem that an API diagram does not solve: who owns the outcome when two services disagree?

Each vendor can satisfy its own contract while the end-to-end workflow still fails. Engineering teams therefore need an accountability model alongside the integration model.

Start with decisions, not endpoints

An endpoint tells us which system can perform an action. It does not tell us which system is authoritative.

For every critical workflow, document five things:

1. Decision authority: which service or internal team decides whether the action is allowed?
2. Execution authority: which component signs, submits or settles the action?
3. System of record: where is the final state recorded?
4. Evidence owner: which component retains the policy inputs and approvals used at decision time?
5. Exception owner: who resolves mismatched or incomplete states?

For example, a transfer might pass identity checks but fail wallet screening. The tokenization platform may construct the transaction while a custodian signs it. A policy service may approve the destination while an on-chain contract rejects it. Without a declared authority order, retries can create duplicate instructions or misleading status updates.

Model the workflow as a state machine

Avoid treating vendor callbacks as the business state. Normalize them into states owned by your application.

type TransferState =
  | "requested"
  | "identity_verified"
  | "policy_approved"
  | "signing_pending"
  | "submitted"
  | "confirmed"
  | "rejected"
  | "manual_review";

type DecisionEvidence = {
  decisionId: string;
  policyVersion: string;
  provider: string;
  checkedAt: string;
  result: "allow" | "deny" | "review";
};

The integration layer translates vendor-specific events into this model. That prevents one provider's terminology from becoming the operating model for the whole platform.

Preserve evidence at every boundary

An audit trail needs more than the final transaction hash. At minimum, retain:

• the policy version used;
• the identity and wallet-screening decision references;
• the asset and jurisdiction rules applied;
• the signer or approval workflow invoked;
• timestamps for requests, callbacks and retries;
• the human intervention record for overrides;
• correlation IDs across every provider.

Store references and normalized outcomes rather than unnecessary personal data. The goal is to reconstruct why an action was permitted, rejected or escalated without duplicating sensitive records across the stack.

Test disagreement and recovery

Happy-path demos are not enough. Integration tests should cover situations such as:

• KYC passes while wallet screening fails;
• payment settles after a subscription window closes;
• the custodian changes a destination address during an open instruction;
• a webhook is delayed, duplicated or delivered out of order;
• one provider is unavailable during a redemption deadline;
• a record requires correction without erasing its prior state.

These tests expose whether the system has deterministic recovery rules or merely a collection of connected APIs.

Build procurement around the same boundaries

The responsibility map should become part of vendor evaluation and contracting. Service levels should cover cooperation during cross-provider incidents. Exit terms should include data export, evidence portability and transition support. Internal owners should be named for controls that no vendor can own on the buyer's behalf.

FluidRWA's framework for building an RWA vendor shortlist begins with operating responsibilities before narrowing the provider market.

The most resilient stack is not the one with the longest feature list. It is the one in which decision authority, evidence and exception ownership remain clear when components fail or disagree.

That is backwards.

Recovery is an alternate path to control. If it is weaker than normal signing, it becomes the most attractive path for an attacker. If it is too rigid, a lost device, unavailable signer or failed provider can make institutional assets inaccessible.

The goal is not to make recovery easy. It is to make recovery possible, authorized, observable and testable.

Begin With Authority, Not Cryptography

Before choosing a recovery mechanism, map who can cause a valid transaction to occur.

The map should include key shares, hardware devices, credentials, API keys, policy administrators, approvers, recovery material, provider support roles and the legal entity that owns each account. It should also show dependencies on identity providers, cloud regions, telecom channels and external wallet infrastructure.

This exercise often reveals that the advertised signing threshold is not the real control boundary. An administrator may be able to replace an approver. A provider may be able to reset credentials. A cloud identity account may grant access to the policy console. Those paths belong in the same threat model as the cryptographic keys.

Separate Recovery Scenarios

"Key recovery" is too broad to be one procedure. At minimum, distinguish:

• a lost or damaged device;
• an unavailable signer;
• an employee departure;
• suspected credential compromise;
• a compromised endpoint;
• a provider outage;
• a regional infrastructure outage; and
• provider insolvency or service termination.

Each scenario has a different risk. Replacing a known lost device is not the same as responding to a suspected account takeover. The latter may require freezing activity, revoking sessions and moving assets before restoring routine access.

The FluidRWA implementation guide for digital-asset key recovery and business continuity treats these scenarios as a combined control, operations and provider-exit problem rather than a backup-seed exercise.

Use Recovery Quorums That Do Not Mirror Daily Operations

If the same people who approve daily transactions can also initiate and approve recovery, compromised routine credentials may unlock both paths.

A stronger model separates recovery authority. It may require representatives from security, treasury and legal or compliance, with independent verification through trusted channels. High-risk recovery can include a waiting period, notification to additional officers and reduced transaction limits after restoration.

The exact quorum depends on the institution, but four principles are broadly useful:

1. No single individual can complete recovery.
2. Recovery evidence is verified independently of the compromised channel.
3. Emergency power is narrow and expires automatically.
4. Every action is recorded for independent review.

Protect Recovery Material From Routine Access

Recovery material should not sit beside production credentials in the same password manager, cloud account or office.

Use separation across people, systems and locations. Protect physical backups against theft, fire and unauthorized copying. Protect digital backups with encryption and independent access controls. Document how integrity is checked without exposing the secret during routine audits.

For MPC systems, understand whether recovery reconstructs a full private key, replaces a share or creates a new wallet. These approaches have different exposure and migration implications. "The provider handles it" is not an adequate architectural description.

Design for Provider Failure

A business-continuity plan that depends on the primary provider being responsive does not cover provider failure.

Ask whether the institution can export account history, policy configuration, signer relationships and audit evidence. Determine whether key material or shares are portable, whether addresses can remain in use after migration and which contractual assistance is required.

Some architectures cannot migrate an address without the original provider. That may be acceptable, but the institution should know the consequence and maintain a tested process for moving assets to replacement accounts.

Exercise the Real Controls

Tabletop discussions are useful for finding unclear responsibilities. They do not prove that recovery works.

Use a low-value account that mirrors the production architecture. Run at least four exercises:

1. One signer and device are unavailable.
2. An administrator credential is suspected compromised.
3. The primary provider or region is unreachable.
4. The organization must migrate to a replacement arrangement.

Require the actual teams to use the real approval, notification and evidence procedures. Measure recovery time, failed steps, unauthorized attempts, stale sessions and reconciliation errors.

After access is restored, confirm balances, pending transactions, address books, policy limits, webhooks and accounting records. Revoke old credentials and rotate affected material. Recovery is incomplete until the organization knows what authority still exists.

Treat Emergency Access as Production Code

Recovery procedures deserve the same engineering discipline as normal transaction flows. Version them. Review changes. Test dependencies. Monitor use. Assign owners. Define service levels and failure conditions.

Most importantly, remove undocumented shortcuts. A helpful support intervention during testing can become an invisible master bypass in production.

Institutional custody is not proven by how securely a system signs when everything is healthy. It is proven by whether the organization can survive loss, compromise and provider failure without abandoning the controls that protect the assets.