Modern Treasury

Overview

Modern Treasury gives fintech companies, lenders, and marketplaces a single platform to manage payments, reconciliation, and orchestration at scale The Payment Order form is where pretty much every customer spends the majority of their time. It is what enables money movement.

I joined the team as a Lead Product Designer for four months. The brief was focused: the Payment Order UX had not been updated since v1 of the product, which was causing onboarding failures, driving CS escalations, and was ill equipped to handle upcoming features on the roadmap.

Strategic Frame

The payment order form reflected how the backend processed payments. But users don’t think about it that way.

I started by mapping the full payment order flow with my PM—logging every input, dependency and optional field. In looking at the flow holistically, the mismatch became clear: the form's architecture made sense internally, but it was not mapping to how people actually think about moving money.

That's a structural problem which is not fixed by changing labels or CTAs.

Approach

With a four-month engagement and clear ask, I wasn't running a full discovery cycle. I first set up a sandbox account and walked the flow myself, then conducted a handful of customer interviews to pressure-test what I was already seeing. I also ran a targeted comp analysis focused on one question: How do other products make the input and output of a transaction visible at the same time?

The findings were enough to confirm what the mapping with my PM was already showing—we had a structural problem, not a labeling one.

Problem 1 — Counterparty creation forced users out of the flow

Counterparty creation was a pain for everyone, not just new users.

When a user got to the counterparty field and realized their recipient didn't exist yet, they had to leave the form entirely, create the counterparty in a separate workflow and then navigate back. It was a pain that affected new users, and for seasoned users who forgot to add a new counterparty before creating a payment order, it felt even more frustrating.

The fix was simple: keep users in the PO form. I designed an inline counterparty creation flow: a user can add a recipient, attach relevant bank accounts and include documentation—while still being in the context of the payment order. To do this, I had to work closely with engineering and product to figure out what could live inline and what couldn't. Getting rid of the round trip eliminated the dropoff.

Problem 2 — Payment methods were invisible

The form was hiding Modern Treasury's capabilities.

Six payment types: ACH, Same-Day ACH, Wire, Book Transfer, RTP and Check lived in a dropdown which users might not even interact with. New users didn't know what was possible and experienced users still had to go looking.

I pulled payment method selection out of the dropdown and made it a visible step. This way, new users could see what was available, while experienced users no longer have to dig. The platform's full range became visible by simply filling out the form—no sales call required.

This also allowed us to show at a glance what payment methods were not available, for example: when a user chooses to charge a counterparty instead of paying one.

Problem 3 — Users submitted payments they weren't sure about

In any financial product, uncertainty at the point of submission is a design failure.

The original form gave users no way to confirm what was going out before they hit the submit action. I added a payment summary that updated at every step—taking into account amount, destination, method and the final send/receive figures. This made the form feel more deliberate and reduced uncertainty, which is important when dealing with transactions in the 4-6 figures.

Solution

Form sequencing

The redesigned form reorganized the workflow into a clearer sequence: payment action → payment method → amount → internal account → counterparty → optional accounting/metadata.

A key sequencing insight: internal account selection is explicitly tied to payment type. Not every account supports every payment method, which meant they couldn't be treated as independent fields. Surfacing payment method early wasn't just a visibility call, it was an architectural one that made downstream field logic coherent.

What I decided not to do

I explored a wizard/stepper early on. It would've made the process more straightforward, but I realized Payment Orders aren't a linear process.

Amount, payment method, and counterparty are all interdependent. I saw that users jump between them constantly. Having some rigid step-by-step flow would only punish that. In the end, a single, well-organized form with clear hierarchy gets out of the way of the user.

Impact

Approved by stakeholders and in development by the time I wrapped.

The inline counterparty flow addressed one of the primary issues that had been causing dropoff. Visible payment method selection reduced the handholding that CS had to do with new users. Additionally, the form design was structured to handle templates, bulk orders, and inline editing (upcoming roadmap items) without a second redesign.

Reflection

The core constraint: how to make the Payment Order experience actually better for new users, while accommodating the workflow of experienced ones. At the end, the new form is both easier to navigate on the surface and more capable underneath.

That is legitimately the kind of problem I find most interesting—figuring out where a structural change is actually worth it versus a surface-level fix.