A Partially Signed Bitcoin Transaction can carry a payment proposal between systems without moving the private keys that will authorise it. That makes PSBT useful for institutional workflows with separate transaction builders, reviewers and signers. The format does not decide whether the proposed payment should be approved.
That distinction gives a treasury a precise design problem. It needs to connect a business instruction to a technical transaction, establish what every signer actually checked and retain enough evidence to explain the transaction eventually broadcast. A sequence of green approval buttons is insufficient if those buttons refer to different versions of the proposal.
The format carries signing information
BIP 174 defines PSBT and describes roles including creator, updater, signer, combiner, finaliser and extractor. Those are technical responsibilities. An institution can assign them to different systems or combine some within one system, but the protocol role names are not an organisational segregation of duties policy.
The practical benefit is a common object that can hold transaction and signing information as it moves through the workflow. An offline signer can receive the data it needs without direct access to a live wallet. That does not eliminate the need to verify the object or to maintain the signer's trusted configuration. A malicious or mistaken builder remains capable of proposing a payment the institution did not intend.
A useful architecture starts by identifying who creates the proposal, who supplies previous output information, who checks destinations, who adds signatures and who broadcasts the extracted transaction. Each handoff needs an owner and a rejection path. Otherwise a technical role can silently inherit a business decision simply because it is the last system able to stop the payment.
Approve the instruction and the transaction
The business instruction might name a beneficiary, invoice, amount and deadline. The transaction represents inputs, outputs, spending conditions and fee consequences. Review needs a documented bridge between the two. A signer can verify a transaction's destination without knowing whether the invoice is authentic; an invoice approver can authorise a payment without understanding an unexpected change output.
For a hypothetical supplier payment, the approval package could include the invoice reference, a beneficiary record retrieved through an approved process, the intended amount and the fully interpreted transaction. The package would distinguish beneficiary outputs from retained change. It would also record the policy version used to select inputs and the rule permitting the proposed fee. These are institution-specific records surrounding PSBT.
The approval record must identify the transaction content being approved. Extra metadata can change during a signing workflow without changing the payment, so a raw file comparison alone can be confusing. The system needs a defined comparison that recognises material transaction changes while preserving the evidence attached at each stage. That comparison must be compatible with the supported PSBT version.
A signature has a defined scope
Bitcoin signatures do not all authorise exactly the same set of fields. The developer guide's signature hash discussion explains how different hash types commit to different transaction components. The institutional implication is that an acceptable signature scope belongs in policy. Review should not assume that every valid signature binds every output in the way the business approval expects.
BIP 174 sets out checks involving previous transactions, scripts and acceptable signature hash types. Those checks protect the signing process at a technical level. The organisation still needs to decide which supported scopes it permits and how an exception is approved. A valid transaction can be outside an internal mandate even when the signatures and spending scripts are correct.
A useful test deliberately presents a transaction with an unexpected signature scope. The signer should reject it or route it through the institution's explicit exception process. Recording that behaviour gives better evidence than a statement that the device supports PSBT. The same approach applies to missing data, an unfamiliar script or an output that the signer cannot interpret confidently.
Verify change against trusted configuration
Change is often the output that receives least attention because a builder labels it as belonging to the wallet. That label should be checked against trusted wallet information. A proposed output is not safe merely because the incoming file supplies a derivation path or names it change. The signer must establish that the output matches the spending policy it recognises.
Multisignature workflows make this especially relevant. Returning change to an address controlled by one participant rather than the expected shared policy changes the institution's custody arrangement. The amount may remain inside an address associated with the organisation while the authority to move it has changed. Destination ownership and destination policy are therefore separate review questions.
The wider relationship between custody policy and signing technology is covered in MPC, multisig and HSM key management. PSBT offers a way to carry information across that architecture. It does not establish that the architecture, signer display or wallet registration process is correct for a particular institution.
Compatibility needs a transaction test
BIP 370 specifies PSBT version 2, including a structure that allows inputs and outputs to be added after initial creation when the relevant modification flags permit it. This is a versioned technical capability, not evidence that every connected wallet or hardware signer supports it. An institutional workflow needs an agreed version and a tested combination of builder, signer and finaliser.
Testing should cover the actual script families and transaction forms the treasury uses. A demonstration with one simple payment proves little about a mixed input transaction, a particular multisignature wallet or the institution's fee replacement process. Rejection messages also matter. Operators need to distinguish an unsupported format from a policy failure or an incomplete package before deciding what to do next.
Upgrades can change interpretation even when the interface looks familiar. The controlled record should retain the relevant software versions and the approved wallet policy. If a migration changes which transaction information is displayed to signers, that is an approval process change. It deserves a review of the workflow, not just a technical compatibility check.
Partial signatures remain operational commitments
An unfinished proposal can already contain valid signatures. Abandoning its approval ticket does not necessarily revoke them. The organisation needs a process for superseded proposals, duplicate input reservations and the circumstances in which an old transaction can still be completed. Deleting a file from the primary interface is not an explanation of that risk.
Consider a hypothetical payment that stalls after one signer approves. Treasury changes the beneficiary instruction and creates a new proposal. The next operator must know which signed object remains in circulation, whether the proposals conflict on inputs and what action establishes the intended outcome. The answer depends on the transaction construction and signing scope. It cannot be inferred from the newer ticket's creation date.
Fee changes need the same clarity. A revised transaction may require a new approval and fresh signatures. A process that silently preserves a business approval while changing technical payment content needs a defined rule for why that is permitted. Institutional wallet transaction policies provides the broader setting for these exception and authority decisions.
Retain the evidence of what was broadcast
The audit package should connect the original instruction, interpreted proposal, approval decisions, signing stages and final network transaction. The organisation may retain different artefacts for each stage, but their relationship should be explicit. The final transaction identifier alone does not explain who approved the proposal or what information those people saw.
Review metadata exposure at the handoff
A portable approval object can disclose information that recipients do not need for their assigned task. Derivation information, extended public keys or internal business references may reveal more about the wallet or its operating relationships than one payment requires. The organisation should review the actual fields its builder exports rather than treating every PSBT exchange as a minimal disclosure.
That review must preserve the information a signer needs to perform the intended checks. Removing fields simply to make the package smaller can weaken change recognition or compatibility. A controlled export policy can specify the recipient, purpose and required data, then test the resulting package across the approved workflow. The record should also identify storage and deletion responsibilities for intermediaries that handle the file without signing it.
A practical review samples completed payments and asks another operator to reconstruct them using only the retained record. Can that operator account for every output, identify the change policy and explain any revision? Can the operator show why the transaction met the mandate at signing time? If not, the issue is evidence continuity, even if all payments reached their intended destinations.
PSBT makes separation of preparation and signing technically possible. Institutional control comes from the checks around that separation: a stable payment instruction, verified transaction interpretation, supported versions and a record that follows the proposal through completion. Those checks turn a portable signing object into a reviewable treasury workflow.