Local Currency & seller disbursement for AWS Marketplace

Role: UX Designer for Banking and disbursement experience

Timeline: 2024

Team: Product manager, Developers, Local ops team

Skills: Fintech UX, Enterprise payments, Seller experience

AWS Marketplace Local Currency lets global enterprise buyers procure software and services in their preferred currency, EUR, GBP, CAD, AUD, or JPY removing the foreign exchange risk that comes with predictable invoicing. This project focused on the seller side of that system: banking and disbursement. Before this, sellers could only set up one disbursement method, a US-based bank account limited to USD which meant that even when a buyer paid in their local currency, AWS Marketplace had to convert it to USD before the seller ever saw it.

To comply with my non-disclosure agreement, any confidential information is omitted in this case study.

The problem

AWS Marketplace sellers could only get paid one way: a US ACH bank account, disbursed in USD. If a buyer paid in a non-USD currency, AWS converted that payment to USD before it ever reached the seller's payable balance exposing both sides of the transaction to foreign exchange risk they had no way to avoid.

For non-US sellers, the workaround was worse: register with an external partner, HyperWallet, to obtain a virtual ACH account, then hand those details back to AWS Marketplace. It worked, but it was a detour built on top of a system that was never designed for international sellers in the first place.

Project Local Currency set out to fix this at the source letting buyers pay in their currency of choice (EUR, GBP, CAD, AUD, JPY) and letting sellers receive disbursement in that same currency, with a new SWIFT-based payment method sitting alongside the existing US ACH option.

Expanding the scope: from feature addition to full revamp

The original requirement documentation was to add SWIFT and HyperWallet as new payment method options to the existing banking and disbursement experience. But when I ran my own UX investigation into that existing experience before I started any UX work, I found a deeper problem. It wasn't just missing international support, the banking and disbursement experience was unclear in its information architecture, its interaction patterns, and how it communicated status to sellers.

Layering two more payment methods, each with its own form fields, validation rules, and processing flow, onto an already-confusing foundation would have compounded the problem rather than solved it. So I escalate the situation to the product team and we made the case to expand scope: not a patch, but a full revamp of the banking and disbursement experience, designed to scale cleanly across all three payment methods (ACH, SWIFT, HyperWallet). I brought this to my PM and engineering partners with a clear comparison, the cost of incremental patching versus the long-term value of a cohesive redesign and the team shifted direction to support it.

Research & Insights

User testing with customers

I started to test the design with users from usertrsting.com to actual AWS Marketplace sellers. The core flow held up well overall, but three findings shaped the next round of design:

• One user wanted payment profile information surfaced directly on the settings page, rather than buried a click away.

• Two user got stuck adding a bank account for a disbursement preference with no unique naming convention, they couldn't tell which account he was actually selecting.

• The TrendMicro users weren't just testing the flow; they were trying to understand the system behind it who has visibility into which bank accounts, and whether a UK-based team could see US accounts. That question mattered enough that it needed to be answered in the design, not just in a support doc and we were able to catch these edge cases early to .

Designing the Geo-fencing & KYC verification flow

The most complex design challenge was regulatory, not visual. When a seller selects a SWIFT bank account signaling they'll receive payment in the UK or sell to EMEA-based buyers compliance requires them to complete Know Your Customer (KYC) verification on top of standard bank account verification. These aren't parallel steps; they're sequential and gated. A seller has to clear bank account verification before KYC even becomes available, and failure at either step puts them in a different state entirely.

To design this well, I embedded with the engineering team through several working sessions to understand the geo-fencing logic itself: which countries trigger KYC, how the verification handoff works technically, and how the two verification steps interact. That gave me the conditional logic mapped out clearly enough to translate into a linear, understandable flow for sellers — SWIFT selected → geo-fence detected → bank verification → KYC required — without exposing the technical machinery behind it. Sellers always know where they are in the process and what's required next, even when a regulatory requirement adds an unexpected step.

Final design

Impact

• AWS Marketplace Local Currency shipped in Nov, 2024

• It gave sellers a path to receive disbursement in the same currency their buyers pay in — eliminating FX risk that previously sat on both sides of every non-USD transaction.

• It has generated over $1 billion in Total Contract Value from non-U.S. customers and achieving 190% of the organization's 2025 revenue target.

Lessons learned

1. Challenge the scope when your own investigation reveals a deeper problem — don't just execute the brief. The original ask was to add international payment methods to an existing experience. My own investigation showed that experience was too broken to build on. I'm glad I advocated for the full revamp, but I could have gotten there faster with a heuristic evaluation of the existing experience up front — making the case for a redesign in week one instead of mid-project.

2. Embed with engineering early when regulatory logic drives the design. The geo-fencing and KYC flow had deep technical dependencies — sequential gates, country-based conditional logic — that fundamentally shaped the UX. Next time, I'd request a technical architecture walkthrough in the first sprint, mapping every conditional path and state transition before sketching a single screen.

3. Design for scalability from the start when the system is clearly growing. The project went from one payment method to three, each with unique fields, validation, and verification flows. I'd approach a project like this by designing a modular component system upfront, built to absorb the next payment method rather than requiring rework when it arrives.