All Case Studies

JPMC Digital Wallet

Led the design strategy and UX for an AI-powered digital wallet, enhancing B2B marketplace payments, unlocking a $500M market opportunity

BUYERERP (AP)Accounts PayableExternal BankOutgoing paymentsSUPPLIERERP (AR)Accounts ReceivableExternal BankIncoming paymentsSAP ARIBABusiness Wallet for SAPHouse account managed by JPMBUYER WALLETSWallet AWallet BWallet CINSTANTSETTLEMENTSELLER WALLETSWallet XWallet YWallet ZEnabled by JPMorgan ChaseInvoice dataFunds outRemittanceFunds in

In 2022, JPMorgan Chase and SAP sat down to solve a problem they both recognized: buyers and suppliers transacting on SAP Ariba had no strong payment solution. The data pointed to a $500M market opportunity. The brief was to design a digital wallet for B2B marketplace payments.

I was brought in as design lead. My job was to figure out what the product actually needed to be.

The brief was a starting point. The research pointed somewhere else.

What the Research Revealed

B2B payments aren't hard because of payment rails. They're hard because of data quality.

When a buyer sends a batch payment to a supplier, the remittance data that comes with it is often incomplete, malformed, or just missing. AR teams on the supplier side spend hours — sometimes days — reconciling payments manually, chasing down buyers to figure out which invoice a payment was even supposed to cover.

The wallet concept was meant to address this through ledger technology — rich, structured payment data that travels with the money. AI would handle the last mile, the small percentage of cases where even good data couldn't automatically match invoices to payments. Think of it like UPS package tracking, but for money. At any point, both sides could see exactly where a payment was, what it covered, what still needed resolution.

That was the vision. What the research revealed was a harder problem underneath it.

The Problem

The reconciliation pain was real. AR teams on the supplier side were drowning in manual work — chasing buyers for remittance details, matching payments to invoices by hand. They would have adopted a solution immediately.

But reconciliation was the supplier's problem, not the buyer's. AP teams on the buyer side didn't have the same pain. Their workflow was straightforward — send payment, move on. Asking them to adopt a new wallet system, change their processes, and enrich their payment data for someone else's benefit was a fundamentally different ask.

This was the adoption asymmetry. One side had every reason to adopt. The other had almost none.

I raised this early. The question wasn't whether the wallet concept was sound — it was. The question was whether we could find a compelling buyer-side value proposition before scaling the build. Or design for a supplier-led model where buyers could be enrolled without needing to change their behavior significantly.

Product leadership wanted to push forward with the proof of concept and figure out GTM later.

We pushed forward. Before we could test whether the asymmetry was as fatal as I suspected, organizational changes on both sides — reorgs at JPMorgan Chase and SAP — ended the partnership. We never got the chance to find out.

My Role

I led design and research across a cross-functional team spanning JPMorgan Chase and SAP. I ran 20+ discovery interviews with AP and AR teams, synthesized findings into strategic recommendations, and designed the end-to-end product experience — critical user journeys for both buyer and supplier workflows, a vision storyboard for executive alignment across both organizations, and a high-fidelity prototype.

The design was built on SAP's Fiori design system — a constraint of the partnership, not a choice. It got the concept across. The visual execution was functional rather than refined, and I knew that at the time.

The more important work was what the research uncovered — and what I did with it.

What We Did

Finding the asymmetry

We started with existing AP and AR research to map the as-is state — how buyers and suppliers currently handled payments and reconciliation on Ariba. Then I ran validation interviews with finance teams to pressure-test the wallet concept against real workflows.

What came back was consistent. AR teams on the supplier side lit up when we described the concept. AP teams on the buyer side were polite but unmoved. The wallet solved a problem they didn't feel they had.

That pattern — enthusiasm on one side, indifference on the other — was the signal. It shaped every strategic recommendation I made from that point forward.

Designing the concept

With the adoption risk on the table, we moved into product design. I created end-to-end user journeys for both AP and AR workflows, then designed the wallet experience itself.

The central metaphor was payment tracking — think UPS for money. Both buyer and supplier could see exactly where a payment was, what invoices it covered, what still needed resolution. Rich remittance data traveled with the payment. AI handled the edge cases where even structured data couldn't automatically match an invoice to a payment.

I built a high-fidelity prototype to make the concept tangible across two large organizations with very different contexts. To align executives at both JPMorgan Chase and SAP, I built a vision storyboard showing the end-to-end experience — from a supplier receiving a payment through to automated reconciliation. Same logic as the banking case: the storyboard wasn't for users. It was for the people who needed to commit resources to build it.

The Scenario

What buyers and suppliers were actually dealing with

Storyboard panel 1
Storyboard panel 2
Storyboard panel 3
Storyboard panel 4
Storyboard panel 5
Storyboard panel 6
Storyboard panel 7
Storyboard panel 8
Storyboard panel 9
Storyboard panel 10
Storyboard panel 11
scroll

Pressure-testing with compliance

We ran two compliance workshops where legal reviewed the user journey end to end — I facilitated the first, attended the second as the design representative. The constraints that surfaced initially felt like friction. Most of them turned out to be improvements.

Bringing compliance in early gave us the chance to stress-test the flows beyond the happy path. Edge cases we'd underweighted got surfaced and designed for properly. I've seen this pattern now across multiple projects — compliance teams aren't obstacles to good design. They're design partners if you bring them in early enough.

Results

What we shipped was a high-fidelity proof of concept — payment tracking, remittance data, AI-assisted reconciliation, compliance-tested flows for both sides.

What we didn't ship was a product. Before we could take the concept to market, organizational changes on both sides ended the partnership. Reorgs at JPMorgan Chase and SAP dissolved the team before we got there.

The $500M opportunity was real. The concept was sound. What remained unvalidated was the GTM model — specifically whether we could find a compelling enough reason for buyers to change their behavior.

That's an honest place to end. Not every project ships. The value of this one was in what the research revealed and what it taught me about designing for two-sided adoption in enterprise markets.

What I Learned

Identify the adoption risk before building the product.

The reconciliation problem was real. The wallet concept was technically sound. What we didn't validate early enough was whether both sides of a two-sided market had sufficient reason to change their behavior. In enterprise B2B, the party with the pain isn't always the party with the purchasing power. I think that asymmetry needed to be on the table before we invested in architecture — not after.

Compliance is a design partner, not a gatekeeper.

Bringing legal in early to review the user journey gave us the chance to stress-test flows beyond the happy path. The constraints it surfaced mostly improved the product. It's easy to forget this when timelines are tight, but I've found it's almost always worth it.

Push technical assumptions earlier — and harder.

Design and product raised the possibility of an AI-first approach to invoice matching early on. The technical team pushed back — ledger technology offered deterministic one-to-one matching, while AI relied on fuzzy matching that felt less reliable for financial transactions. That argument won. Looking back, I think the more significant issue wasn't matching reliability — it was adoption architecture. Ledger-based matching required the wallet to be live on both sides of every transaction. That's a bilateral adoption requirement, which made the buyer-side resistance fatal by design. An AI-first approach would have broken that dependency — suppliers could have gotten real reconciliation value even if buyers never changed their behavior. That's a different go-to-market model entirely. It deserved more pressure-testing before the technical direction was locked.

Organizational complexity is the hardest design problem.

Two large organizations, executive sponsors, competing priorities, reorgs on both sides — the product design was the straightforward part. The real challenge was maintaining momentum across an organizational structure that was changing underneath us. You can't always design around that. But you can design with it in mind — building artifacts and alignment mechanisms that survive personnel changes rather than depending on specific relationships.