UX case study

 

Small Business Debit Card Issuance

 

Redesigning how TD Bank colleagues issue debit cards to small businesses, migrating off legacy software and embedding fraud prevention directly into every issuance flow.


Role

Lead UX Designer

Client

TD Bank

Platform

Odyssey Web App

Team

PO, BSA, Dev, VD, CD

Timeline

1 year

 
 
 

Project Overview

 

For the past 5 years, TD Bank has been working to improve how colleagues issue debit cards to personal and small business customers. The project sits at the intersection of two major initiatives: a multi-year platform migration from a legacy enterprise app to a modern web app (Odyssey), and a bank-wide effort to prevent money laundering after a high-profile fraud event.

Small businesses introduce hierarchies, authorized users, regulatory limits (5 debit cards per business), and a heightened need for sanction screening on every cardholder. The challenge: design flows that handle this complexity without slowing colleagues down or eroding trust with customers.


 

Strategic How-Might-We

How might TD tighten debit card controls through sanction screening for every business debit card so that we have more awareness on debit card activities and prevent money laundering?

 

Key Design Decisions

Sanction Screening Built-In

Informed by: Fraud Concerns & Required Data Capture

Mandatory data fields (Name, DOB, SSN, address) for every cardholder were designed directly into the issuance flow, ensuring sanction screening always runs, never as an afterthought.

Adaptive Business Rules

Informed by: Authorized User Hierarchies

The flow dynamically enforces business-specific rules the 5-card-per-business limit and authorized-user permissions without colleagues needing to memorize policy.

One App, All Issuance

Informed by: Context Switching Pain Points

Consolidated personal and small business debit card issuance into a single Odyssey workflow, eliminating the need for colleagues to switch between Encore and other tools.

 

 

Step 1 of 4 — Account Selection

Designing for Progressive Disclosure

Small business issuance requires colleagues to handle primary and secondary accounts, view existing linked cards, and respect the 5-card business limit — all in the first step. The design reveals complexity progressively, so colleagues never feel overwhelmed.

 
 

Entry Point

A clean starting point


The colleague enters the maintenance hub for John's Cleaning Service. Only "Issue new card" is shown initially, additional actions (Re-issue, Close, Change limit) appear contextually as the colleague progresses, reducing cognitive load.


 

Linked Cards Visibility

Showing existing card relationships

Once an account is selected, the colleague immediately sees all existing linked cards, cardholders, and statuses. This visibility helps respect the 5-card business limit and identify cards that may need to be closed before issuing a new one, surfacing maintenance options like Re-issue, Close card, and Change limit only when relevant.

 

Multi-Account Issuance

Handling business complexity

Many small businesses have multiple accounts a card needs to link to. Colleagues can optionally add secondary accounts, each with their own linked card visibility and pagination. The Continue action only appears once the colleague has the context they need to move forward confidently.

 

 

Step 2 of 4 — Address verification

Confirming the Right Address, Up Front

Business addresses change. Before any card is printed or mailed, the colleague verifies the primary account address with the customer — preventing wasted cards, returned mail, and the fraud risk that comes with cards sent to outdated addresses.

 
 

A single, deliberate question

The address is shown exactly as it is on file, with a clear note that this isn't the card mailing address, it's the account address. The colleague answers one question: Is this still correct?

A "No" path branches into edit-and-update without leaving the flow, while "Yes" advances the colleague forward — keeping pace with confident, fast-moving customers.


 
 

Step 3 of 4 — Cardholder information

The Heart of Sanction Screening

This is where every regulatory requirement converges. Each cardholder must have Name, DOB, SSN, address, and citizenship captured before a card can be issued — so the screen pulls all cardholders into one view, lets the colleague verify each person's details, and respects the dynamic per-business limit.

 
 

Step 3 anatomy — expanding any cardholder reveals the exact data being captured for sanction screening, so the colleague can confirm with the customer in real time.

 

Initial State

All known cardholders, ready to confirm

The customer's existing authorized parties surface automatically, with a clear cap and a visible "Add a cardholder" affordance for new additions.

Dynamic Limit

The 5-card rule, enforced quietly

The "up to 5 cardholders" cap recalculates against the business's existing linked cards. Colleagues never have to do the math — the rule is enforced inline, not at submission.

Screening Kickoff

An honest moment of waiting

When sanction screening launches, an inline "Launching application…" state replaces the silence. Colleagues know the system is working, customers know nothing is stuck

 

 

Step 4 of 4 — Card delivery

Per-Cardholder Delivery, in One View

Business issuance can mean four cards going to four different people. Rather than asking colleagues to repeat the same decision four times, the final step consolidates every cardholder's delivery method into one table — with the destination address confirmed in context.

 
 

Multi-Account Issuance

Handling business complexity

Many small businesses have multiple accounts a card needs to link to. Colleagues can optionally add secondary accounts — each with their own linked card visibility and pagination. The Continue action only appears once the colleague has the context they need to move forward confidently.

 

Selections made

Confidence to print

Once every cardholder has a delivery method chosen, the primary action — Print card — anchors the bottom of the view. The colleague closes the issuance task knowing every cardholder is accounted for, screened, and routed correctly.

 

 

Confirmation

A summary that closes one loop and opens the next

The final screen is both a receipt and a springboard. Each cardholder has its own status row — Printed or Mail in progress — so the colleague can confidently tell the customer exactly what happens next, per card. And because business customers often need more than one card, the recurring "Open another debit card" action lets the colleague loop back without restarting from the customer search.

 
 

Anatomy

One row per cardholder — expand for the full receipt

Each row collapses to the essentials: who the card is for and whether it's printed or mailing. Expanding reveals the auditable detail the colleague might be asked for — issuance timestamp, every linked account, card type, masked PAN, and the business name on file.

The pattern keeps the screen scannable for a multi-cardholder business while still surfacing audit-grade detail on demand.

 
 

States the summary handles

Real issuance is rarely uniform. The summary scales gracefully across status mixes and account counts.

 
 

Happy path

All printed in-branch

When every cardholder picks in-person delivery, every row resolves to Printed and the customer walks out with cards in hand.

Mixed status

Some printed, some mailed

Per-row statuses make it instantly clear which cards are ready today and which are en route — so the colleague can set accurate expectations with the customer.

Many accounts

Progressive disclosure for power users

Cards linked to ten-plus accounts truncate to five with a Show more / Show less toggle — keeping the summary compact without hiding compliance-relevant detail.


 

Recurring Action

"Open another debit card" — the loop that respects context

Business customers frequently leave the branch with more than one card request. The summary surfaces a single, obvious next action that loops the colleague back into the flow with the customer's context still loaded — no re-search, no re-authentication, no lost momentum.

 
 

Across all five steps — account selection, address verification, cardholder information, delivery, and confirmation — every regulatory requirement is met without ever pulling the colleague out of the flow. Sanction screening, the 5-card business limit, per-cardholder delivery decisions, and the recurring multi-card loop all live inside the same continuous experience.

 

Appendix

 

The Challenge

Migrating off a legacy enterprise application demanded careful design thinking. Experienced colleagues were deeply trained on their legacy app’s quirks, while new hires needed flows that felt intuitive from day one. Our job was to design for both audiences without slowing either down.

On top of that, we faced strict budget and timeline constraints, forcing constant prioritization between building new functionality and enhancing existing flows. A recent money laundering event at TD meant fraud prevention couldn't be deferred. Every issuance flow had to embed sanction screening from the start.

 
 

Core problem

How can small business customers get access to their money as quickly as possible, while colleagues confidently meet every regulatory and fraud prevention requirement along the way?

 
 

Process Transformation

Before: Manual Review

  • Colleagues juggled multiple legacy systems to issue a single business debit card.

  • No native support for business regulatory rules like the 5-debit-card limit.

  • Sanction screening was disconnected from issuance, fraud risk slipped through gaps.

  • Steep learning curve for new colleagues; platform slated for discontinuation.

After: Odyssey Issuance

  • A single, modern application for issuing personal and business debit cards.

  • Business regulatory logic (5-card limit, authorized users) built into the flow.

  • Mandatory sanction screening on every cardholder, embedded into issuance.

  • Intuitive UI for both veteran and new colleagues, reducing training time.


Key Insights

Authorized User Hierarchies

Business accounts have an authorized user who can issue debit cards to other authorized or non-authorized users. The flow needed to handle multiple cardholder relationships clearly.

Fraud is a Top Concern

After a recent money laundering event, the bank initiated a sweeping fraud prevention campaign. Debit card issuance is one of the highest-impact areas to embed controls.

Required Data Capture

Every cardholder requires Name, DOB, SSN, and address to be captured for sanction screening — these fields had to be designed into the flow, not bolted on.


My Role & Approach

As the Lead UX Designer, I owned the design end-to-end from initial requirements with product owners and BSAs through visual design sign-off and developer handoff, while regularly coordinating across pods to keep flows consistent.

 

UX & Visual Design

Designed and iterated on the issuance workflow and interaction model, finalized visual designs, and built prototypes for complex business-specific interactions when static designs weren't enough.

Stakeholder Alignment

Led requirements alignment sessions with Product Owners, BSAs, and developers. Ran weekly feedback sessions and occasionally facilitated cross-pod collaboration to keep flows consistent.

Content & Visual Partnership

Held working sessions with Content and Visual Designers to ensure terminology and layout guided colleagues intuitively through complex regulatory and screening tasks.


 

Pilot Outcomes

Results & Impact

The pilot validated all three goals — proving the Mitek technology, the experience design, and branch adoption could work together at retail scale.

Increased

Small business debit card issuance volume

Reduced

Time to issue a card end-to-end

100%

Cardholders screened via embedded sanction checks

Migrated

Colleagues moved off legacy Encore


 

Learnings & Reflections

Trust is built into the flow, not announced. For small business customers, trust comes from a colleague who moves confidently and asks for the right information at the right time. Embedding sanction screening seamlessly into the flow was as much a trust signal as it was a regulatory requirement.

Driving adoption requires empathy for legacy users. Colleagues were deeply trained on Encore. Designing the new flow wasn't just about being better — it was about being intuitive enough that veteran colleagues would willingly leave a system they had mastered.

Prototypes bridged the developer handoff gap. With business rules layered on top of fraud screening logic, static visual designs often left ambiguity. Sharing prototypes early — especially for complex business workflows — was what got developers aligned and confident.