U.S. Online Banking Enrollment Architecture
Company: TD Bank
Scale: 10M+ Users | 1,050 Branch Locations | 99.9% Uptime Platform
The Symptom
The Baseline Reality: TD Bank’s legacy enrollment flow was blocking ~700,000 potential customer acquisitions, driving a baseline success rate of just 4–9%. This drop-off triggered massive call-center backlogs and costly, unassisted store visits.
The Systemic Defect: The failure was caused by fragmented orchestration across identity verification, legal payloads, and conditional enrollment states. This behavioral ambiguity created severe downstream implementation divergence, unmapped operational failure states, and compliance risk.
The Outcome
The Architectural Output: Engineered a build-ready, 4-step state machine that rationalized all conditional edge cases. This behavioral specification successfully cleared full IT, Legal, and Product review—eliminating implementation ambiguity and securing the architecture required to execute the ~700,000 user acquisition target.
01/ The Systemic Reality & Cross-Functional Alignment
THE BASELINE SYSTEM: The original enrollment flow. Fragmented legal payloads and unoptimized database queries caused ~700,000 dropped acquisitions.
The failure of the original enrollment experience was fundamentally a structural logic problem, not a visual one. Existing customers trying to register for online banking encountered fragmented technical roadblocks, missing exception paths, and redundant processing friction.
To reverse the 4–9% success rate, the enterprise initiated a high-stakes cross-functional design sprint. I operated alongside the line of business, change managers, legal partners, product owners, and user researchers.
As the User Experience Lead for the Responsive Web platform, my job was to take the conceptual outputs of this multi-stakeholder sprint and translate them into a clinical, build-ready architecture that respected rigid legacy mainframe constraints and strict regulatory requirements.
THE ENTERPRISE BLUEPRINT: The complete state machine architecture, mapping all edge cases, decision matrices, and fallback logic before engineering handoff.
02/ Behavioral Specification & Deconstructed Decisions
To shield engineering from interpretation puzzles and eliminate sprint carryover, we deconstructed the enrollment flow into four strict, sequential states.
State 1: Data Payload Optimization & Identity Resolution (Account Lookup)
The Constraint: The account lookup phase was historically the highest drop-off point in the system. We needed to verify identity and match the user to the correct legacy mainframe ledger entries without triggering fraud vulnerabilities.
The Product Assumption: The initial design sprint proposed utilizing only a user’s Social Security Number (SSN) to dramatically simplify the input UI.
The Research Reality: Baseline user testing exposed immediate friction: users felt a sharp psychological alarm when a system requested their SSN as the very first input, stating they expected a combination of Date of Birth (DOB), SSN, or Account Number.
The Multi-Variable A/B Test: To isolate the exact behavioral friction vector, I partnered with User Research to run an unmoderated A/B test comparing an SSN-only screen against a Last Name + SSN screen.
The Operational Insight: The data revealed an inconvenient system truth: adding fields did not mitigate user alarm. Users presented with the Last Name + SSN variant expressed identical hesitation. However, 100% of users were ultimately willing to input their SSN because they expected a bank to require it.
The Operational Consequence: Held the line on a strict single-query database requirement (SSN only), refusing to add cosmetic UI fields that offered no mechanical value.
Business Impact: Neutralized the behavioral drop-off vector entirely through precise content design ("Your SSN helps us..."), aligning user expectations with systemic requirements without expanding the engineering scope.
State 2: Legal Payload Consolidation (Terms & Conditions)
The Constraint: In the legacy architecture, Terms & Conditions were scattered contextually across multiple distinct steps. This forced users through redundant click-through actions and created fragmented database insertions.
Worse, it introduced severe compliance risk: if a session dropped mid-flow, the user's legal consent state was left unmapped.
The Operational Consequence: Working directly with our Legal and Compliance partners, I consolidated 3 fragmented legacy agreements into a single, unified state gate with a binary acceptance action.
Business Impact: Mitigated critical compliance risk by guaranteeing the database logged a clean, timestamped consent insertion prior to advancing the user, eliminating unmapped legal states during session drops.
State 3: Architectural Decoupling (Security Verification)
The Constraint: The enrollment process required a One-Time Password (OTP) security step. However, the IT development team had just finalized a massive, site-wide infrastructure overhaul of the global Security Verification screens for another project.
Introducing new enrollment-specific UI requirements threatened to disrupt their production code, trigger site-wide regression testing, and prompt intense engineering pushback.
The Governance: I initiated a series of technical design reviews, first with the core Human-Centered Design team, and then directly with the IT Architects and Product Owners.
The Operational Consequence: Rather than fighting a costly architectural battle, I negotiated a strategic decoupling. I worked with the systems architects to isolate the enrollment validation flow from the global platform security stack.
Business Impact: Preserved engineering velocity. This boundary definition prevented the new enrollment requirements from triggering costly site-wide regression testing on the locked global infrastructure.
ARCHITECTURAL DECOUPLING: (Left) The locked global security screens. (Right) The front-end decoupled enrollment sandbox, designed to bypass site-wide regression testing.
State 4: Database Schema Constraint Mapping (Username & Password)
The Constraint: To accelerate the credential setup phase, the product team wanted to auto-fill the username field using the user's email address on file
The Operational Consequence: Overrode the product team's assumption to auto-fill the username with the user's email address due to legacy schema limitations regarding special characters.
Business Impact: Prevented downstream engineering rework by intercepting technical debt before the sprint began, eliminating the guarantee of silent database insertion failures and unhandled 500-level production errors.
03/ Ingestion Governance (The Angular / Design System Gap)
Because the re-imagined flow relied on walking users through a strict, single-intent step sequence, the interface absolutely required a step-progress component to prevent drop-off. This requirement exposed a fundamental platform migration mismatch.
The Technical Blocker: The enterprise had deployed a major update to its global design system a year prior, which contained the exact progress tracker and optimized input fields we needed. However, our specific platform was locked out of this ecosystem because the development squad was fully consumed by a complex legacy migration from Angular 2 to Angular 3.
The Governance Layer: As the Co-lead designer on the platform, I was running weekly cross-vertical design syncs with other platform teams to lay the groundwork for eventual design system adoption. I used this project to accelerate those backroom conversations into immediate action.
The Strategic Outcome: I called an alignment session with Product, Development leads, and IT Architecture. I successfully positioned the enrollment flow as the ideal, isolated vehicle to test-drive the new global system's components within the near-complete Angular 3 environment.
The development leads verified the technical feasibility—scoping it at exactly one developer for one sprint. The product team approved the resource allocation, turning a design system roadblock into a highly successful, controlled technical pilot that unblocked the platform's broader ingestion roadmap ahead of schedule.
The Proof of Concept (POC) Pitch: I approached the Product Manager with a clear, quantified matrix of choices:
Build a net-new custom component from scratch: Adds high development overhead and technical debt.
Omit the component from the design: Accept high, predictable user drop-off.
Ingest the global system early: Treat this critical acquisition flow as a controlled Proof of Concept (POC).
04/ The Operational Outcome (The Architectural Handoff)
The enrollment flow was transformed from a multi-departmental interpretation puzzle into a build-ready technical specification. By mapping the state transitions and database schema limitations before development began, I established the exact data boundaries required to safely execute the ~700,000 user acquisition target.
The Execution Leverage:
Reduced Implementation Ambiguity: Replaced a fragmented legacy experience with a strict, rationalized four-step state machine.
Engineering Throughput Preservation: Proactively modeled the edge cases, eliminating the need for engineering to resolve identity logic or legacy API constraints mid-sprint.
Operational Resilience: Secured full cross-functional approval from IT Architecture, Legal, and Product leadership.
The Result:
The behavioral specification was locked as the enterprise blueprint. Even amid broader corporate roadmap shifts, the architecture stood as a fully documented, risk-mitigated asset—ensuring that whenever the flow entered the active backlog, engineering could execute the UI with zero architectural divergence or compliance exposure.