I'm a product designer. I have no security background — only a surface understanding of it.
So I didn't try to fix the perimeter.
I changed the angle.
When a treasury-approval attack landed in front of me, the security answer was the obvious one: more authentication, or more hardware. I couldn't out-engineer that team, and I won't pretend to. But I could ask a designer's question — if you look at this problem from a different angle, does it become a different problem? This study is that exploration, seen through the eyes of one person: Seo-yeon, a Head of Treasury Ops.
not the optimal answer
Head of Treasury Ops
of the operator
the edge of my domain
What this is. A design study, prompted by a well-documented class of treasury attack. It is not a security product, not a description of any specific incident, employer or figure, and not a claim to be the correct or optimal solution. I do not offer security as a service. The value here is the reframing — and the honesty about where a designer's thinking stops and a security team's begins. This is a subjective exploration, not an objective security assessment: I have only surface knowledge of the field. Limits are stated in full below.
The attackers never broke the crypto. They broke the human moment.
A high-privilege treasury workstation gets a remote-access trojan. The malware waits, hijacks the clipboard to swap a wallet address, and lets a real, validly-signed approval carry a malicious payload straight through. Password, one-time code, the logged-in session — all satisfied. All useless.
The instinctive fix is to add a factor: another code, another device, a hardware token on every transfer. But anyone who has watched an operations team work knows where that ends — security fatigue. Ask a person to authenticate forty times a day and by the fortieth they are tapping "approve" without reading. The control becomes theatre.
That was the moment I stopped thinking like someone trying to add security, and started thinking like a designer. The failure wasn't a missing factor. The failure was in the interaction — the few seconds where a human confirms what they're signing, and can't actually tell. That's not a security problem I'm unqualified to touch. That's a design problem.
So I stopped designing for a threat, and designed for a person.
I can't hold a whole security architecture in my head. But I can hold one person in it. Every decision in this study was made by asking what it would mean for her.
Seo-yeon signs money all day. Her risk isn't the once-a-year phish drill — it's the hundredth routine approval, the one that looks exactly like the ninety-nine before it. Her real job is judgment under repetition, and repetition is precisely what dulls judgment.
She's also carrying risk she can't see on the screen: is this really the vendor she thinks it is? Is this a normal hour to be moving this amount? Is the machine in front of her still hers right now? A traditional approval screen asks none of that — it just asks "are you sure?" and waits for a reflex.
"My clients don't call me when a transfer goes through. They call me when it doesn't. I'm the early-warning system — so I can't afford to go numb."
The risk that isn't on the screen.
The study's core question: what if the interface helped Seo-yeon weigh the layers of risk a "Confirm" button hides from her — the environment, the timing, the behaviour, the second opinion?
Environment
Is this the device and network she signs from, or something that only looks like it? The screen should know the difference before she has to.
Timing
Is this a normal hour, a normal amount, a normal counterparty? An atypical pattern is a question, not a rubber stamp.
Behaviour
Does the way this session moves match how Seo-yeon actually moves? A script doesn't share her hands. (A signal, not a verdict.)
The second opinion
Above a threshold, one person shouldn't be the whole control. A second officer, on their own device, weighs in.
Same problem, turned ninety degrees.
"How do we prove it's really her?"
Answered with more factors, more devices, more prompts. Each one adds friction and, eventually, fatigue — the thing that made the human the weak link in the first place.
"How do we make her genuine intent hard to forge?"
Answered by moving the judgment to where humans are strong — recognising a pattern — and away from where they're weak — staying vigilant under repetition. Ask her less, not more.
Hide the truth in plain sight.
The idea I kept coming back to: don't give the attacker a single address to overwrite. When a transfer is ready, there's no editable field and no lone "Confirm" — the destination lives inside a lattice of high-fidelity decoys, and Seo-yeon finds the real one by recognition.
4 × 4 lattice · 1 real (◆) · 15 decoys · illustrative
No single field to swap. The clipboard-hijack attack works because there's one address the malware can overwrite. Remove that field and the attack loses its target.
Decoys that look real. The fifteen decoys borrow from historical data — allowlisted addresses, near-identical amounts — so a script can't pick the real one out statistically.
She recognises; she doesn't type. A private cue only Seo-yeon set that day marks the true cell. Automation can screen-scrape the grid, but it can't know her cue. Recognition takes seconds; vigilance takes willpower she shouldn't have to spend.
The best prompt is the one she never sees.
The insight I'm proudest of in this study isn't the lattice. It's that most of the defence should happen before a decision ever reaches Seo-yeon — so her attention is spent only where it's genuinely needed.
A quick four-cell match. Behaviour is read quietly in the background. Friction stays near zero — because spending her vigilance here is how you lose it for later.
This never became a prompt Seo-yeon had to dismiss. Three passive signals disagreed before any lattice was shown, so the request was held for security review instead of reaching her queue. The design's job was to protect her attention, not just her signature.
The full sixteen-cell lattice — the moment that genuinely deserves her full attention gets it, precisely because the routine ones didn't waste it.
A second officer, on an independent device, solves a complementary fragment before funds release. One compromised endpoint — even hers — can't move the money alone.
Sign a transfer as Seo-yeon
A working prototype of her approval console — the queue, the pre-queue interceptions, the lattice, the risk tiers, the second-officer fragment, and the audit trail. No install, no signup.
Not better than everything. Different where it counts.
Honestly scored. This approach is strong against automated, scaled attacks and light on the operator's attention — but it is not a hardware root of trust. Read the findings after the table.
| Dimension | Traditional 2FA (OTP / push) | Hardware wallet / U2F | This study — Echo Lattice |
|---|---|---|---|
| Client hardware needed | Phone | Proprietary device | None on client — signing would use a server-side TEE |
| Demand on the operator | High — repetitive codes | Medium — plug & press | Low — recognition, and fewer prompts |
| Automated clipboard / MitB swap | Fails | Conditional | Strong — no lone field to swap; decoys |
| Automated / AI screen-parsing | Fails | Isolated | Strong — obfuscation + private cue |
| Targeted human-in-the-loop on an owned host | Fails | Resistant — hardware isolation | Raises cost — not a cryptographic guarantee |
The honest edge — where I hand it back to the experts.
- A browser can't guarantee what-you-see-is-what-you-sign on a fully compromised host. If the machine is owned, an attacker can screen-capture the lattice; with a live human operator they may try to solve it. This design defeats automated, scaled attacks and raises the cost of targeted ones — it is not a cryptographic guarantee.
- The behaviour signal is probabilistic. It flags and escalates; it should never be the sole gate on money movement. I learned to describe it as a signal, not a verdict.
- "No hardware" means no client hardware. The signing path still leans on a trustworthy server-side TEE — a real dependency I'm not qualified to secure.
- It doesn't replace standard defence-in-depth. Address allowlists, out-of-band verification, endpoint monitoring and hardware signing for the highest tier still belong to the security team. This is the layer that sits on top.
- It's a study, not an audited product. The TEE / zero-knowledge architecture is a direction to validate with people who do this for a living — it needs red-teaming before anyone trusts it with real money.
Knowing exactly where my competence ends is part of the design. The study's honesty is the point, not a footnote.
What I think the job actually is.
A product designer's job isn't to keep adding features, or to invent problems that were never there. It's to do the most with the least — and to help a real person reach the best solution available right now.
Design is not addition
The reflex to solve a problem by piling on more — more features, more steps, more prompts — usually creates the next problem. The harder, better move is subtraction: deliver what the client actually needs within real constraints. Here, that meant asking Seo-yeon for less, not more.
Sit in the user's seat
You can't design the truth of a moment by guessing at it. You have to become the user — sign the transfer, feel the fatigue, live the friction — before you understand it. This whole study is me trying to sit where Seo-yeon sits, not theorise about her.
Know the edge of what you know
I have surface knowledge of security, not expertise — so this study can't claim to be objective, and I won't pretend it is. Naming exactly where my competence ends is not a weakness in the work. It is part of the work.
This was never really about security.
It's about a way of working. Take a problem — even one outside your expertise — and refuse to accept that it only has the shape the last person gave it.
I don't have a security background, and this study doesn't pretend otherwise. What I do have is a habit: when a problem arrives with an obvious answer attached, I ask whether a change of angle turns it into a different problem with a better answer. Here, "add more authentication" became "design the moment so genuine intent is hard to forge, and spend the operator's attention only where it counts."
That instinct — put a real person at the centre, question the framing, and stay honest about the edges — is the same one I bring to a trading terminal, a KYC flow, or a compliance surface. The domain changes. The way of looking doesn't.
Seo-yeon isn't real. But the discipline of designing as if she were — of refusing to ship a "Confirm" button to someone whose whole job is to not go numb — is exactly what I'd bring to your hardest problem, whether or not it looks like a design problem on the surface.
Hand me a problem that "isn't a design problem." Let me change the angle.
This is what it looks like when a product designer takes an unfamiliar, high-stakes problem seriously — leading with a real person, reframing instead of reaching for the obvious tool, and staying honest about the limits. If that's the kind of thinking your team needs, let's talk.