MoneyLion AI
Transfer $20 to my Managed Investment account
Got it. Here’s a quick summary before I send:
From
Wells Fargo · 1430
Savings Account
To
Managed Investment
Amount
$20.00
Fee
$0.00
Arrives
Instantly
Button text
I just need to verify this transaction to ensure you have initiated it.
Enter the 4-digit code
We sent you via text to (123) 301-0951
1
2
3
4
Resend code
Button text
Button text
Ask me about money matters...
MoneyLion AI can make mistakes, so double-check it. Learn more
Enabling money movement within AI conversation
MoneyLion's AI could already explain a user's finances in chat, but the moment a user wanted to act on that insight, the conversation broke. They'd form intent ("move $200 to savings"), then get kicked out to re-navigate and re-enter details they'd already stated. I designed the end-to-end flow that let the AI actually execute the payment, in-thread.
AI chat with an inline transaction card, from stated intent to confirmed payment.
Problem
1
Intent formed, but action required leaving the conversation
1
Users expressed clear financial intent inside AI chat, but execution required leaving the conversation entirely.
2
Every re-entry point was a chance to lose the user
1
Navigating away and re-typing amounts or recipients introduced friction and room for error at exactly the moment intent was clearest.
3
No pattern for AI-authored transactions
1
No existing pattern for how an AI-authored action becomes an authenticated, confirmed transaction.
Problem statement
How might we let a user go from stated intent to completed payment without ever leaving the conversation?
Key design decision
1
Kept the transaction card system-rendered, not via conversation
1
The payment confirmation UI is a distinct, structured component the system renders, visually separated from the AI's free-text output:
- AI's free-text output: conversational, generated, can vary in wording
- System-rendered card: fixed structure, always the same trusted format
This means a user can never mistake an AI suggestion for a confirmed transaction.
A stated intent becomes a system-rendered card, never AI free text.
2
Anchored step-up authentication to the existing session
1
Rather than treating payment auth as a new flow, MFA step-up was designed to inherit from the user's already-authenticated chat session. This reduced friction while keeping the identity boundary explicit.
Step-up authentication inherits the existing chat session instead of starting a new flow.
3
Rejected the lower-effort deep-link handoff
1
The obvious cheaper build was a deep-link handoff: detect intent in chat, then route the user to the existing (already-compliant) payment screen with fields pre-filled.
- Deep-link handoff: reused proven, audited surfaces, shipped faster, but the user still left the conversation, just with less typing
- In-thread execution (chosen): required new surface area (session/identity integration, wallet service integration, explicit alignment with risk/payments on what the AI may never infer or execute), but preserved the continuity the project existed to deliver
I rejected the deep-link path because it preserved the exact problem the project existed to solve. The whole thesis was continuity over familiarity: reusing a known screen wasn't worth reintroducing the context break.
Initial low-effort propose is to link out all transactions
MVP PROPOSAL
From prompt to complete transaction in one interface
FINAL DESIGN
Drawer-mode chat vs. full-screen alternative
4
Discovered and catalogued every response scenario before any copy was written
1
Rather than letting copy get written scenario-by-scenario as edge cases surfaced, I mapped the full space of situations the transfer agent needed to handle and defined the exact structure, trigger logic, and copy for each.
- Covered progress states, blockers, redirects, and safety guardrails
- Defined structure and trigger logic per scenario, not just the happy path
- Shared this as the response specification the PM and engineering built the system prompt against
GUARDRAILS
BLOCKERS
PROGRESS
REDIRECTS
Every response scenario mapped before copy was written: progress, blockers, redirects, guardrails.
5
Rejected the upsell-driven draft in favor of neutral reporting
1
The team's early direction for scenarios like "user doesn't have this account yet" leaned into product marketing, pitching the benefits of opening a new account rather than simply stating the fact and the option.
I pushed back and authored the correction instead:
- Answer comes first, no preamble
- One job per message, no scope creep into benefits copy
- A banned-word list (seamlessly, unlock, enjoy, leverage, empower, and similar) enforced across every scenario
Chat is reporting a transaction, not selling a product, and blurring that line risks the trust the feature depends on.
A sample response from the initial LLM was too sales-y
SAMPLE RESPONSE
Straight forward and actionable response
FINAL RESPONSE
Early upsell-driven draft next to the corrected neutral-reporting version.
6
Defined a hard boundary on AI inference
1
- Amount, recipient, and any ambiguous instruction must always be confirmed via forced choice, never guessed
- Account labels are always masked, never a raw number or a model-invented ID
- Every submission runs an idempotency check against in-flight transfers before executing
Worked with risk and payments teams to lock these in, directly closing two named risks: wrong-account hallucination and duplicate transfers.
🎉 Final Design
The completed transaction state, confirmed and logged in-thread.
Key learnings & takeaways
The hardest design work happened off-canvas: defining when the AI must stop, what it may never infer, and how authentication anchors to identity. Catching the upsell drift before it shipped mattered just as much, since a chat feature that sells at the moment someone is moving their own money erodes the trust it needs to work.
- End, thank you for reading! -