A system-level abstraction that makes complex financial states interpretable, consistent, and scalable across the product.
IMPACT
Established a canonical transaction lifecycle across 100+ backend status variations
Redefined how financial activity is interpreted by introducing a transaction abstraction layer that maps 100+ backend status variations across transaction families into 5 canonical lifecycle states, governing every financial event across fiat, crypto, trading, staking, and compliance workflows.
By shifting complexity out of the UI and into system rules, this created a predictable and scalable model adopted across Design, Engineering, Product, Compliance, and CX. The system was validated by over 100K monthly interactions at peak, sustaining consistent engagement through early 2026.
CONTEXT
Financial activity lacked a shared system for interpreting what happened to user money
Newton is a regulated financial platform where users rely on transaction records to understand what happened to their money and why.
During a feature freeze tied to CIRO (Canadian Investment Regulatory Organization) registration, I used the window to investigate something no one had formally scoped: how transactions were being represented across the product.
Transactions originate from multiple domains:
Fiat transfers (eTransfer, wires)
Crypto deposits and withdrawals
Trades
Staking and rewards
Compliance workflows (e.g. Travel Rule, LVCT, KYC)
These systems evolved independently over time.
Backend states were shaped by provider and regulatory requirements
Frontend representations were built per feature
There was no shared abstraction governing how financial events should be interpreted.
Audit of transaction states across systems.
I mapped 100+ backend status variations across transaction families, revealing duplicated meanings, legacy states, and inconsistent lifecycle logic.
PROBLEM EVOLUTION
UI standardization failed because there was no shared definition of lifecycle across transactions
I reframed what initially appeared as a UI standardization problem into a system-level modelling problem.
When I placed all transaction flows and their corresponding designs side by side, it became clear:
Each transaction type followed a different system model
Statuses were inconsistent in meaning and level of detail
Similar lifecycle stages were expressed differently across flows
Examples included:
“Delay/issue” vs “pending” vs “completed”
Transfer-specific states that didn’t translate across other transactions
The moment the previous approach broke was:
When we attempted to standardize transaction sheets and realized there was no shared definition of lifecycle across the system
Without a unified model, standardization at the UI level was not possible.
Fragmented transaction models across the product.
Each flow represented lifecycle differently, making it impossible to standardize the UI without first defining a shared system model.
CORE INSIGHT & GOVERNING PRINCIPLE
The solution was to define a system that translates backend complexity into consistent user meaning
The key insight was: The problem was not backend complexity, it was the absence of a shared model translating that complexity into user meaning.
I reframed the problem from simplifying backend complexity to defining a stable system for interpreting it.
Governing Rule
All financial events must be interpreted through a stable lifecycle abstraction:
Every backend state maps to a canonical lifecycle state
Lifecycle communicates progress and outcome, independent of transaction type
Conditional requirements are expressed as flags, not new states
Defining a stable interpretation layer
Backend complexity translated into a canonical lifecycle model.
The lifecycle abstraction became the interpretation layer between backend states and product behaviour, allowing complexity to remain intact while presenting consistent user meaning.
IMPLEMENTATION
#1 Audited backend transaction states
Identified 100+ backend status variations, duplicates, and inconsistencies
#2 Defined lifecycle mappings
Mapped all backend states to canonical lifecycle categories
In Progress
Action Required
Completed
Failed or Cancelled
Funds Returned
#3 Standardized transaction interpretation
Introduced a consistent transaction sheet model.
Aligned teams across engineering, product, compliance, and CX
Backend-to-lifecycle mapping examples.
Different backend states now resolve into consistent lifecycle categories, ensuring predictable interpretation across transaction types
Transaction Sheet Standardization
A consistent transaction model replaced fragmented views, enabling users to interpret any financial event using the same structure.
THE OUTCOME
The system scaled to meet real demand when users needed transaction clarity most
The transaction sheet scaled from 1,800 interactions at soft launch to a peak of 107.7K in October 2025, coinciding with crypto's largest recorded liquidation event.
Introduced through external marketing with no in-app prompts, the sheet retained 62% of peak engagement through early 2026, forming habits faster than the existing transaction list.
REFLECTION
Financial interfaces scale through stable abstractions, not feature-level solutions.
Transaction design initially appeared to be a UI consistency problem.
In reality, the issue was structural.
By introducing a canonical lifecycle abstraction, we established a shared foundation for interpreting financial activity across fiat, crypto, and compliance workflows.
The work reinforced a principle central to financial product design:
In complex financial systems, clarity comes from stable models that translate operational complexity into predictable user meaning.