A routine UI cleanup during a compliance freeze uncovered a bigger problem:
no shared definition of what a transaction's lifecycle actually was.
IMPACT
Replaced 100+ inconsistent backend statuses with 5 canonical lifecycle states, adopted across Design, Engineering, Product, Compliance, and CX, and validated by 100K+ monthly interactions at peak.
Newton users rely on their transaction history to know what happened to their money. There was no shared system for interpreting that, until this.
PROBLEM
Four core transaction types evolved their own backend states and their own UI, with no shared model for what "in progress" or "failed" actually meant.
Newton's transactions span four core domains, cash transfers, crypto transfers, trades, and staking, plus a handful of smaller types like manual credits and rewards. Each evolved its own backend states and UI on its own timeline. Transfers were the worst offenders, carrying compliance workflows (e.g. Travel Rule, LVCT, KYC) layered directly on top. Trades and staking had their own inconsistencies too, just less severe.
With new feature work frozen pending CIRO registration, the ask was simple: clean up the UI, standardize it, build templates. Pulling together every transaction screen, some didn't even exist, made it clear this wasn't just a missing-screens problem. A trade sheet looked nothing like a transfer, and a cash transfer looked like a different product than a crypto one.
The plan broke the moment I tried to apply a template: there was no shared definition of lifecycle to standardize against.
The real problem was one level down: a missing system model, not an inconsistent interface.
I sat down with engineers, PMs, and finance to audit the actual backend statuses: 100+ variations, duplicated meanings, legacy states, no consistent logic. "Delay/issue," "pending," and "failed" meant different things depending on which flow you were in.
Audit of transaction states across systems.
Representative sample from mapping 100+ backend status variations. Several of which meant different things depending on transaction type, or nobody could confidently explain anymore
THE INSIGHT
Backend complexity wasn't the problem. The absence of a model that translated it into consistent meaning was.
So instead of trying to simplify the backend, I defined a stable interpretation layer between it and the product:
Every backend state maps to one canonical lifecycle state
Lifecycle communicates progress and outcome, independent of transaction type
Conditional requirements (KYC holds, compliance flags) are expressed as flags on a state, never as new states
This let backend complexity stay exactly as complex as it needed to be, while everything the user or another team saw stayed consistent.
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.
HOW IT WORKED
Audited every backend state, defined a canonical mapping, then rebuilt the transaction sheet as the single source of truth across teams.
Audited: mapped all 100+ backend states across every transaction family, flagging duplicates and legacy statuses.
Defined the mapping: collapsed everything into 5 canonical states (In Progress, Action Required, Completed, Failed or Cancelled, Funds Returned), each paired with contextual UI messaging so the specific reason still surfaced without adding new states.
Standardized: rebuilt the transaction sheet on top of the canonical model and aligned Engineering, Product, Compliance, and CX around it as the source of truth.
Every transaction type had its own status vocabulary.
Before standardization, transaction flows carried overlapping but inconsistent language for the same underlying outcomes.
Transaction Sheet Standardization
A consistent transaction model replaced fragmented views, enabling users to interpret any financial event using the same structure.
THE OUTCOME
The rebuilt transaction sheet scaled 59x from soft launch to its highest-traffic moment, with zero in-app prompts driving it.
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, with zero in-app prompts driving that traffic. It retained 62% of peak engagement into early 2026, forming habits faster than the transaction list it replaced.
REFLECTION
Financial interfaces don't scale by fixing individual features. They scale through abstractions stable enough to hold as backend complexity keeps growing underneath them.
This looked like a UI consistency problem. It was actually structural.
Nobody asked me to audit 100+ backend states during a compliance freeze. I did it because that's how I work: when something's broken, I don't stop at the symptom, I go find where it actually breaks. This project is a clear example of a pattern that shows up across my work, I'm a systems thinker before I'm anything else.