Receiver Onboarding · Identity & Fraud · A/B test

Fraud risk and customer trust: “Let me in”

Effective identity verification for employees of existing accounts.

At a glance

Summary:: Employees of companies already on our network were blocked from getting paid because they couldn't log in to their company's existing account, so many created duplicates instead. I mapped where the system could step in, took 3 options to Risk and Compliance, and designed the one we could ship with minimal engineering: recognize the employee at the duplicate check, release their first payment, and let the account's admins approve them as a member.
Design process:: Legacy experience audit → Listen to Gong calls on customer complaints → Redesign onboarding flow for this user group → Consult Risk and Compliance team → Iteration & final design
Team:: 1 product manager, 1 product designer, 1 Risk consultant, 1 Compliance consultant, 2 engineers.
Outcome:: Experiment running against legacy; results pending.
Key trade-off:: The question changed from “how do we verify everyone?” to “how much risk on one payment is worth the trust of tens of thousands of users a month?”

01Where it got hard

When an employee of a company that already has an account with us tries to sign up to get paid, we block the duplicate account and ask them to log in with their company’s existing account. Often they don’t have the credentials, so they can’t get paid. They complain (we heard it on Gong calls), and many create the duplicate anyway.

Duplicates of existing Virtual Card (VC) suppliers hurt the whole network:

Network inefficiency: duplicate organizations create a “noisy network,” which degrades autoconnection and search, confusing users while damaging vendor data integrity.
Revenue leakage: for existing VC suppliers, duplicate Basic Receivable (BR) accounts cause significant Total Payment Volume (TPV) leakage and introduce reconciliation and trust risks.
User urgency vs. access: users create a new account instead of claiming the existing one because their goal is to get paid quickly, and they can’t log in to the organization the system found.

The buried tension: the gate guarded an account login, but the real exposure was a single first payment. Once we named that, the question changed from “how do we verify everyone?” to “how much risk on one payment is worth the trust of tens of thousands of users a month?”

Here is the legacy experience.

Legacy flow: the new vendor either logs in to the existing account or creates a new account that can't receive virtual card payments.

BR is creating a duplicate of existing account that’s enrolled in Virtual Card program (receive all payments via VC).

It is a dup of an existing regular/non-VC org

Our system blocks this user until identity verified.

It is a dup of an existing Virtual Card org

How can we allow this user group to get paid via VC rails while minimizing fraud risks?

02The decision I made, and why

I chose the smallest option we could ship: recognize the employee at the duplicate check, release their first payment, and let the existing account’s admins approve them as a member.

Why: the PM and I took three options to Risk and Compliance. Compliance cleared it, as no personally identifiable information (PII) was at risk. Risk quantified the exposure: possible loss of one first payment if the user is fraudulent. The call on what risk to accept was ours, and the trust of tens of thousands of users a month outweighed it. Risk is a product decision. Admins approve membership because they know who works there; the system doesn’t have to guess.

The constraint that shaped it: payments only flow between connected accounts in the network, and vendor data (bank, address, email) changes too often to be a source of truth. So the change had to work at the moment of the duplicate check, inside the existing pipeline.

What changed in the design:

New content for the 2nd option on the duplicate-check step, telling the user their payment is here.
A confirmation step that clearly explains what happens next.
A new payment widget leading the user to their payment.

On the back end, engineering needed to check the business relationship once a duplicate is detected, route the latest pending payment for the VC organization to the new account, and email the existing account’s admins to ask for their approval.

The de-dup step, before and after: the second option changes from creating a new account anyway to receiving one payment and verifying identity to receive future payments.

The new confirmation step, “Got it. What’s next”: the pending payment will be sent as a virtual card payment, and only one payment will be sent until the user verifies their identity.

03What I tried and dropped

Dozens of options, down to three. The team brainstormed dozens of ways to get the user their payment without moving mountains in the existing pipeline. Three stood out; I chose option 2 over the two bigger rebuilds.
The “verify everyone” framing. Dropped once we named the real exposure: one first payment, not the whole account.
An external identity-verification vendor. Explored but not chosen for this release; it’s still an open option for the bigger fix.

Shipping the smallest change that tests the bet meant new wording and one confirmation step on an existing screen, so we could learn from real users while the bigger fix is explored.

Option 1: when the AP adds the vendor, the system detects an employee of a virtual card organization, auto-connects them and enrolls the vendor in virtual card.

Option 2: when the new vendor is blocked as a duplicate, a confirmed employee can receive the first pending payment without ID verification, and is encouraged to verify for future payments.

Option 3: a new ID verification capability proves the vendor's relationship with the existing business within minutes, granting admin access to the virtual card account.

04What changed

Behaviour, by design: employees get their first payment while they verify themselves, and the existing account’s admins get an approval email instead of a support ticket. See the new experience at the top of this page.

Numbers: the experiment is running against legacy, and results are pending.