Transaction Policies
Introduction
Transaction policies enable organizations to enforce strict oversight and control over outgoing transactions. Any time a user creates a request, the system checks the proposed action against the criteria listed here:
- Who creates transaction requests and who approves them.
- From/To where accounts funds can be sent and to which destinations.
- How much can be transferred.
- Which assets over which blockchains and in which currencies.
- Which types of blockchain interactions are allowed (for protocols that allow multiple types of interactions).
- If approval is required and by whom.
If there is a policy that corresponds to the requested transaction, the system goes through the action configured in the policy's approval workflowsapproval workflows.
Transaction Policy Types
Transaction Policies come in four types, briefly outlined below:
- Transfer: Governs asset transfers from one address to another. Policy covers transfers originating from addresses within the Custody Infrastructure system, whether those transfers are destined for another address within your system, or to an external destination.
- Smart Contract: Manages interactions with smart contracts. This policy breaks down into two major (and mutually exclusive) sub-types:
- Deploy any smart contract: This policy option covers designated users deploying smart contracts from specified accounts.
- Signature type: This option covers smart contract transactions (other than deployment). There are two options, either or both of which can be chosen for the same policy.
- Personal Sign: Personal signing allows you to confirm ownership of data but cannot be used to transfer assets.
- EIP-712 sign: This is required for policies dealing with dapps. It is the safer and more structured signing option.
- Raw Signing: Controls operations that involve signing raw data created offline and uploaded to the uMPC.
- Staking: Enforces rules for staking assets via the uMPC. Assets can only be staked to validator addresses.
While each type of transaction policy covers a different scenario, they all share the same configuration process, covered in detail in Create Transaction PoliciesCreate Transaction Policies.
View Transaction Policies
You can view transaction policies by opening the Policy Management area from the left-side navigation menu and clicking the Transaction Policies tab at the top of the screen.
The following information is displayed:
- Name: The name of the policy
- Initiators: Who can trigger transactions under this policy
- From/To: Where actions can originate and end
- Currencies: What coins and/or tokens are covered by this policy
- Allowed Operations: What specific action is covered by this policy (i.e., what type of policy is it):
- Transfer: Governs asset transfers from one address to another.
- Smart Contract: Manages interactions with smart contracts, ensuring compliance with operational rules.
- Raw Signing: Controls operations that involve signing raw data created offline and uploaded to the uMPC.
- Staking: Enforces rules for staking assets via the uMPC.
- Last Updated: When was the last time this policy was modified.
A policy only applies to transaction requests that meet all the criteria above. If no policy applies to a transaction request, the system automatically cancels it.
Policies enable organizations to control who initiates transactions, where funds can be sent, transfer amounts, and more, providing strict oversight for blockchain interactions.
Prerequisites
Creating policies via the uMPC desktop policy requires your system to be deployed in uMPC-driven mode. See Cold-driven vs. MPC-driven Modes for information about the system's two operating modes, and System Preferences for instructions regarding setting the mode.
Only users with admin privleges can create and edit policies.
Before certain elements can be added to a policy, they must first exist as entities in the system. These entities include:
- Approval Workflows: Which approvers need to confirm transactions is configured in the MPC Approval WorkflowsMPC Approval Workflows area.
- Contacts: Both ordinary contacts and validator addresses need to be in the address book before they can be added to a policy. See Addresses and Address Groups for more information.
- Roles: Different approval flows can be required depending on the initiators' roles. See User, Role, Group, and Policy Logic.
- Users/User Groups: These must exist before they can be added to a policy. User groups can be used to add new users to a policy at any time, just by adding the user to the included user group. See User Management for details.
Create Transaction Policies
Each policy type has its unique aspects, but the flow, overall, is similar:
- Operations: Here, you define the policy transaction type, currency or currencies included, and the transaction sources and destinations. The destinations and currencies must be aligned with the policy type, i.e., you can only use a validator as a destination in a staking policy, but cannot make a staking policy to cover Bitcoin, for example.
- Initiators: Here, you indicate who can make transaction requests under this policy.
- Approvals: Here, you set the financial boundaries of the policy along with oversight rules.
- Review: Here, you double-check every element of the policy you created.
To create a new policy:
Click the + button at the top of the screen. Select a policy type:
You can change the policy type later using the policy type dropdown:
A given policy can only be of one type. If you want to use the same addresses, initiators, ranges, etc. for a different type of operation, you can copy your current policy and adjust it from there.
Create a name for the policy. It is best to use an identifying name indicating what the policy does.
Click the toggle to allow this policy to govern smart contract calls:
Add your From accounts and wallets. This policy will only govern transaction requests that call for sending funds out from the included from accounts and wallets.
Click the blue + to add an item to the list. Click Show selected to view the sources list.
Smart contract and Raw signing policies only have a from option, not a to option.
Add your To destinations. This policy will only govern transaction requests that call for sending funds to the included to contact or validator addresses.
Click ->| To and the panel expands.
Click the blue + to add items to the list. A counter indicates how many destinations are currently included in the policy. Click Show selected to view the destinations list.
Click the toggle to allow this policy to govern transactions to any destination, including contacts not in the address books:
The destination contact type must match the policy type. A staking policy can only use validators as destinations.
Click Next after setting the sources and destinations. The Currencies menu opens.
Staking policy doesn't include Currencies options, and will advance directly to Initiators.
All the relevant currencies for your included contacts are automatically listed.
To apply the policy to additional activated currencies, select them using the Add currency dropdown:
- To choose a specific currency, start typing its name or select it from the drop-down list.
- Click the checkbox to add currency to the list
- To choose all currently active currencies, choose Select All
Click the toggle to allow this policy to govern transactions in any currency, including currencies not yet on the system:
Click Next after setting the currencies. The Initiators menu opens.
Choose the Initiators, the users that can initiate a transaction under this policy. These can be user groups or individuals.
Click the blue + to add items to the list. Click Show selected to view the initiators list.
Click the toggle to allow this policy to govern all users, including users added in the future:
Click Next after setting the initiators. The Approvals menu opens.
Approvals work by measuring a policy's cumulative transaction value over a rolling window of time.
The window of time is called the frequency, and the total fiat value allowed per time period is called the range.
A single policy has one frequency and can govern transactions across any number of financial ranges within that period, up to "unlimited". Each range can be assigned a unique approval flow.
You can further introduce granularity to your policy by giving different approval flows according to user role.
Set the Frequency by selecting Daily, Weekly, or Monthly.
The time is counted backward from when the transaction request is initiated. For example, if transactions of up to $10,000 are set as daily and a transaction is made at 09:00 am, the system will add together the fiat value of all transactions that occurred back to 09:00 am the day before. For a request to be allowed, the total fiat value of the proposed request plus all other transactions within the set frequency, must be below the range maximum.
Set ranges for the policy.
You can set the upper limit of the range by either clicking and dragging the slider or clicking the value in the text box and inputting a new value. Additionally, after clicking the range box, you can set the range's upper limit to unlimited or delete the range entirely.
If you want your policy to cover more than one range, click + Add a range. If you want to set a range's upper limit to a value higher than that shown, adjust Set bar maximum.
Once you have configured your ranges, click Apply to populate the approval flows table.
You assign each range an approval flow. Approval flows must be populated from the lowest range up; you cannot allow higher-value ranges if there is no flow in place for lower-value ranges. Set each range's approval flow via the corresponding drop-down menu. To explore all possible approval flows, click View Approval Workflows.
Optional Role-Based Approvals:
Users’ roles can optionally be involved. For example, low-level employees can be required to get supervisor approval, while supervisors can be trusted to move funds without additional oversight.
Click the toggle to set different approval flows for each range depending on a user's role:
Once toggled on, each range will have a separate approval workflow dropdown for each role on the system:
Click Next after setting the approvals. The Review menu opens.
Review the new policy. Any rule can be expanded by clicking the title on the review screen.
Click Create to create the policy. This will trigger a change request that must be approved according to the organization's policies.