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.
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.
This abstraction governs every financial event surfaced in the product, across fiat, crypto, trading, staking, and compliance workflows.
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.
PRODUCT TENSION
Transactions needed to be standardized without breaking backend and compliance complexity
We needed to standardize how transactions are interpreted across the product while preserving backend complexity required for compliance and provider integrations.
The system was already fragmented across transaction types, exposing inconsistent states and lacking a shared model across teams.
This created a tension between:
maintaining system correctness
providing a clear, consistent user understanding
This resulted in users experiencing:
confusion when similar transactions behaved differently
difficulty understanding transaction status
reduced trust in the system’s accuracy
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.
WHY OBVIOUS SOLUTIONS FAILED
One approach was to standardize backend states. However, this was not feasible due to:
provider-specific requirements
regulatory constraints
existing system dependencies
Another approach was to normalize inconsistencies at the UI layer per feature. This led to:
duplicated logic
inconsistent interpretations
increasing divergence over time
Neither approach created a scalable or maintainable solution.
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.
To operationalize this, I introduced a lifecycle abstraction by:
Separated lifecycle, type, and conditional logic
Defined a fixed set of lifecycle states
Mapped backend complexity into a consistent interpretation layer
This allowed backend systems to evolve independently while maintaining a predictable user-facing model.
KEY DECISIONS AND TRADEOFFS
Prioritized consistency over specificity and scannability over density
Tradeoff #1: Specificity vs Clarity
Reduced highly specific backend states into broader lifecycle categories
Example: “delay with this transaction” → “Action Required”
This reduced cognitive load at the cost of losing granular, system-specific detail that could be useful in edge cases
Tradeoff#2: Density vs Scannability
Introduced a standardized transaction sheet instead of exposing all data inline, which required users to tap open a detail view to access full information.
We accepted initial friction from users expecting inline detail, in exchange for:
faster information parsing
consistent layout across all transactions
a model that scales across all financial activity
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
SYSTEM BEHAVIOUR
Transactions now behave predictably regardless of type, provider, or regulatory requirements
The system now behaves predictably across all financial events:
The system guarantees that every transaction maps to a consistent lifecycle state at any point in time
The system prevents backend-specific or provider-specific states from leaking into user-facing interpretation
The system assumes lifecycle meaning should remain stable, even as transaction types and regulatory requirements evolve
This allows new transaction types to integrate without redefining how users interpret them.
THE OUTCOME
A unified transaction model replaced fragmented views across the product
Following implementation:
100+ backend status variations mapped into 5 canonical lifecycle states
Transaction meaning became consistent across all activity types
New transaction types integrate without redefining status logic
Frontend rendering logic simplified significantly
Transaction Sheet Standardization
A consistent transaction model replaced fragmented views, enabling users to interpret any financial event using the same structure.
ORGANIZATIONAL IMPACT
The lifecycle abstraction became the shared system model across teams and future features
Behaviour change
Users could interpret transactions more quickly and confidently
Reduced need to infer meaning from inconsistent states
Reduced ambiguity in interpreting transaction outcomes
System-level improvement
The system now enforces consistency through a shared model
Instead of relying on feature-level decisions
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.