Create Transaction Policy Flow
FINTECH · B2B SAAS · PRODUCT DESIGN
Turning complex institutional security rules into a guided policy-creation flow. The platform provides digital-asset security solutions for financial institutions. One of its most important capabilities is allowing administrators to define policies that control how company funds can move. I designed a guided transaction-policy builder that helps administrators define permitted operations, currencies, initiators and approval requirements across different transaction amounts.
AT A GLANCE
Simplified transaction rules into a five - step policy builder.
Five-step policy builder
Amount-based approvals
Full policy review
ROLE
Research, UX architecture, UI design, handoff, design QA
TEAM
PM, front-end and back-end engineers, security, compliance and blockchain specialists
USERS
System administrators, security officers, institutional managers
WHEN
Jul - Sep 2023
STATUS
Shipped in the GK8 Enterprise Console
The challenge
Banks and large financial organizations manage significant digital assets across many accounts, employees and approval roles.
Every transaction must follow the institution’s internal security policies. Administrators need to control:
Which operations are permitted.
Where funds can move from and to.
Which currencies can be used.
Who can initiate transactions.
Who must approve different transaction amounts.
A configuration error could block legitimate transactions or allow funds to move without the required oversight.
The challenge was to make these rules manageable without oversimplifying the security requirements behind them.
One policy must coordinate permissions across users, accounts, currencies and approval roles.
Research & Inspiration
No product offers this exact flow to learn from, so I researched flows with similar complexity such as permission builders and approval workflows. I broke the policy flow into its individual tasks and researched how others solve each one:
Task | What I looked for | What it led to |
|---|---|---|
Selecting accounts and addresses | How large lists are selected and reviewed | Tables was the most common practice to reflect a lot of data on each item |
Setting amount thresholds | How ranges are defined and edited | Sliders were the best practice for amounts |
Assigning approvers | How roles and approval counts are configured | Multi-selected dropdowns |
Reviewing before committing | How sensitive actions are confirmed | Review step (not editable) |
The design approach
I divided policy creation into five focused steps:
Operations
Currencies
Initiators
Approvals
Review
The sequence moves from broad transaction rules to more specific authorization logic.
Why a pop-up with five steps? This is a very complicated flow, so I wanted to make it as intuitive as possible. I designed it as a pop-up with a few decisions per step, because smaller surfaces with fewer choices lower cognitive load. A compact pop-up leaves little room, so each task needed its own step. That also separates the tasks and helps users focus on one decision at a time. I found four tasks, and the fifth step is a review.
Why a review step? In a flow this sensitive, users want to double-check every decision. Instead of making them go backwards, the final step reflects the full policy in one summary before creation.
Why this order? It follows how administrators think about a rule: first the type of transaction, then where funds move from and to, in which currencies, who can initiate it, and finally who must approve and at what amounts. Each step narrows the one before it.
A persistent step indicator communicates progress, and the policy is automatically saved as a draft while it is being configured.
A complex security policy becomes a clear sequence of decisions.
Designing With Engineers
This flow was technically complex to develop, so I worked closely with the front-end and back-end engineers during the design process, not only at handoff. I made sure each step was buildable before finalizing it.
1. Defining permitted operations
The first step establishes which transaction types the policy controls and where funds may move.
Administrators can select multiple accounts, contacts and addresses using structured tables. Supporting actions make large datasets easier to manage:
Select all.
Show only selected items.
View the total selection count.
Include addresses that are not registered in the system.
Review selected rows separately.
This allows administrators to manage large selections without losing visibility into what the policy includes.
Large selections remain visible and manageable throughout the configuration.
2. Selecting allowed currencies and initiators
Administrators can define which currencies are permitted under the policy and remove selections directly from the selected-currency list.
The Initiators step determines who is allowed to begin a transaction. Users can select specific people through a multi-select table or enable Any initiator when the policy should apply to everyone.
Keeping these decisions in separate steps makes two different types of permission explicit:
What assets may be moved.
Who may initiate the movement.
3. Building approval logic around transaction amounts
Approval requirements often change according to transaction size. A small transfer may need one approval, while a larger one may require several roles.
I designed a visual amount-range builder that allows administrators to create ranges by entering values or adjusting them on a bar. Ranges can represent individual transactions or cumulative daily and weekly amounts.
After the ranges are applied, administrators define the approval workflow for each one.
They can:
Use an unlimited upper amount.
Configure several transaction ranges.
Apply a general approval workflow.
Set different requirements for each company role.
Define how many approvals are required within each range.
This translates abstract financial rules into a visual model that can be inspected and adjusted.
Transaction thresholds are defined visually before approval requirements are assigned.
Each amount range can trigger its own approval workflow.
4. Reviewing the complete policy
Before creating the policy, administrators reach a read-only summary of every decision.
The Review step organizes the policy into expandable sections matching the earlier steps. Administrators can confirm the complete configuration without navigating through multiple forms.
If something needs to change, they can return directly to the relevant step.
The final review turns a complex rule set into one auditable summary.
The final outcome
The resulting flow transforms a dense security configuration into a structured policy-building experience.
Administrators can now:
Build a policy through five understandable steps.
Manage large account and contact selections.
Limit policies to specific currencies and initiators.
Create approval rules for different transaction amounts.
Configure approvals by organizational role.
Review the complete policy before activation.
Continue unfinished work through automatic draft saving.
Impact
This was a new feature, so adoption was the first signal: since launch, 10 transaction policies have been created.
After launch I interviewed a client who was very enthusiastic about the feature. He was very excited about how the new feature capabilities and how easy they were to be done. His one suggestion related to timing, which I recorded as a next step: adding time frames for creating the transaction.
The main design lesson was that complex financial workflows should not hide important rules. The better approach is to reveal those rules in the order users need to make decisions and provide a clear summary before they take effect.