A completed trade can leave a contract authorised to spend tokens that arrive in the wallet tomorrow. That authority may be absent from the balance report, the trade blotter and the payment approval queue. For an institution, ERC-20 allowances should be managed as standing permissions with an owner, a purpose and a review date.
This is a narrower question than whether a transaction was properly signed. The original signature may have been valid, the trade may have settled correctly and the remaining permission may still exceed the institution's intended exposure. A control that closes the ticket at settlement misses what persists afterward.
The approval and the movement are different actions
The ERC-20 specification defines approve, allowance and transferFrom. Approval sets spending authority for a specified spender; transferFrom uses that authority to move tokens. The basic interface does not include an expiry date. An application may add more controls, but the institution should verify them rather than infer them from a trading deadline.
Suppose a treasury wallet approves a router for a planned conversion. The router is the spender, the token contract records the permission and the wallet remains the owner. A permission for an amount larger than the conversion can remain after the trade. The control question is not simply whether the router has a reputable name. It is whether that exact address should retain that exact authority over this wallet.
Capture the network, owner address, token contract and spender address as the identifying tuple. Token symbols and application names are useful labels, not keys. Where a spender is upgradeable, its present implementation and change-monitoring requirements should form part of its approval record. The same destination address can continue to operate while the code behind it changes.
Choose the allowance deliberately
A finite approval can match an intended transaction amount. A larger approval may reduce repeated operational work, but it also extends the period or quantity for which the spender has permission. The institution should make that tradeoff explicit. Convenience should appear as a reason in the approval file, not as a hidden default selected by a website.
OpenZeppelin's ERC20 implementation documents that the maximum unsigned integer is treated as an infinite approval and is not reduced during transferFrom. That is implementation-specific behaviour worth checking in the deployed token. The OpenZeppelin ERC20 reference also shows why event-only allowance accounting can be incomplete: its transferFrom does not emit a fresh Approval event for the allowance reduction.
The institution should read the actual allowance at an identified block when reconciling active permissions. An initial approval log proves that an instruction was processed; it does not establish the current remaining amount. Store raw integer values and verified decimals so that a human-readable limit does not conceal a scaling error.
A suitable policy might require finite approvals for occasional activity and a separately authorised standing allowance for an established workflow. That is a proposed operating design, not a requirement of ERC-20. Each exception should identify which wallet can receive new deposits while the standing allowance remains open.
A zero balance does not retire the permission
A balance limit and an allowance limit constrain different things. With no token balance, there may be nothing available for the spender to move. The permission can still matter when a later deposit arrives. A wallet marked dormant in the cash report can therefore retain useful spending authority for a contract it no longer uses.
The inventory should show current token balances alongside active allowances without treating one as a substitute for the other. Highlight permissions on wallets scheduled for reuse, deposit collection or settlement. A balance-driven dashboard can otherwise make stale approvals disappear precisely when operators think the wallet has been cleared.
This complements institutional wallet transaction policies. The pre-signature check asks what a proposed operation authorises. The allowance register asks what authority already exists. Both are needed because a later transferFrom can draw on an earlier permission without presenting another owner approval for the same economic movement.
Signed permits need their own queue
ERC-2612 defines a signed permit with a nonce and deadline that can set an allowance. The deadline limits acceptance of the permit signature; it should not be read as an expiry time for the resulting ordinary allowance. The distinction is small in an interface and material in an operating policy.
A treasury process should therefore distinguish an unsubmitted signed permit, an executed permit and the remaining allowance. Revoking a permission observed onchain does not, by itself, describe every signature that has been released. Engineering should determine whether an outstanding signature remains usable, using the particular permit scheme and current nonce state.
Keep a record of signed messages released to external systems. Identify their scope, permitted spender, token, quantity, deadline and submission status. This does not require putting secret signing material into the register. It requires retaining enough evidence to know which authority may still be activated.
Revocation is a transaction with a result
Closing the approval ticket should require evidence of the onchain state change. A click on a revoke button, an unsigned proposal or a transaction sitting in a queue does not establish that the allowance has changed. Record the transaction identifier, execution result, observed allowance and the confirmation standard applied.
Changing a nonzero allowance also needs care. The ERC-20 specification discusses setting an allowance to zero before setting a replacement value because transaction ordering can affect allowance changes. The operating implication is to plan and monitor the intermediate state. A two-step process should not be represented as a single completed change when only the first or second instruction is visible.
If revocation fails, assign a specific response. Options might include preventing further deposits, disabling the associated workflow or escalating to the security team. Moving tokens may reduce immediate available balance, but it should not silently count as permanent retirement of the permission. Any alternative should explain the remaining state.
Review the spender, not just its label
The spender register should include what the contract can do, which workflow requires it and what change would trigger reapproval. A router, lending pool, vault and fee collector may have different reasons to request authority. Bundling them under one application name can make a broad approval look narrower than it is.
For an upgradeable spender, the review should connect to operational monitoring. If the implementation changes, the allowance remains a permission recorded by the token even though the spender's behaviour may need reassessment. The institution can define a response threshold based on the affected wallet and quantity. This is a reason to monitor dependency changes after initial diligence.
The existing account of protocol control and diligence addresses who can change a system. Allowance management adds the holder's side of the relationship: which of those systems has been given continuing access to the institution's tokens, and what the institution does when circumstances change.
Assign each standing allowance to a business owner who can explain its continuing purpose. A security team can verify the contract and an operations team can verify the state, but neither should have to guess whether the commercial workflow still exists. When that owner changes roles, the permission should enter the same review queue as a retired application.
For managed accounts, clarify whether the manager, custodian or client is responsible for requesting and confirming revocation. Shared responsibility without a final verifier can leave each party believing the other closed the authority.
Reconcile permissions as a portfolio of authority
Build the review around exceptions rather than a long list of approved applications. Useful exceptions include an allowance with no current business owner, a spender outside the current contract inventory, an amount above the authorised limit, a retired workflow and a permission on a newly funded wallet that was assumed to be inactive.
Do not sum every allowance and call the result an expected loss. Several spenders can have authority over the same token balance. The register measures overlapping permissions, not independent pools of assets. Exposure analysis should show the wallet's assets, each permission and the scenarios in which authority could be exercised.
An illustrative monthly review might reconcile the register to identified block reads, ask owners to reconfirm standing permissions and track revocations to completion. A more active wallet may need event-triggered review as well. Frequency should follow the rate of new approvals, incoming assets and contract changes, rather than a universal calendar interval.
The final deliverable is a readable answer to a simple question: who can spend each token in this wallet without a new owner instruction? A balance reconciliation cannot answer it. An allowance process can, provided it covers creation, use, amendment and retirement of the authority.