The Brief
A bank with no
digital path for
dispute submission.
When I joined TD, every debit claim followed the same path. A customer called the helpline, was transferred to a fraud operations intake team, and answered a detailed questionnaire over the phone. Or they walked into a branch and did the same thing in person. The process was manual end-to-end, and at over 70,000 debit claims per month, the operational cost of that model was significant.
Competitors had already built digital dispute channels. TD had not. I was brought in specifically to build it.
What I did not fully understand on day one was how structurally difficult that would be. The problem was not a missing front-end form. Claims did not live in the digital world at all. They lived in a Pega-based claims and disputes management system, owned, operated, and financially controlled by the Fraud Operations team. Fraud Operations and the Digital team were separate lines of business with entirely separate mandates: one managed claim intake and resolution, the other managed customer journeys across the bank's mobile and web platforms. Neither had ever needed to intersect with the other. These were two separate organizations, with separate budgets, separate definitions of the problem, and no shared product surface.
"Fraud Operations managed claims. Digital managed the customer experience. Neither had ever needed the other, until now."
The Approach
Discovery across
a fractured
organizational landscape.
I started with structured discovery across more than 40 people: engineers, designers, fraud operations analysts, compliance leads, payment network specialists, and product stakeholders from both the digital and claims organizations. The goal was to answer one question before we wrote a single requirement: what is actually possible at the intersection of these two systems?
The Pega system had 51 workbaskets with individual routing rules. Claim automation decisions were generated by Pega AI. The system handled multiple product types, including debit, Zelle, BillPay, wire, and transfer, and produced 41 distinct letter types with 10 variations among them. None of this had ever been documented from the digital channel's perspective, because from the digital channel's perspective, it had never needed to be.
The cross-functional alignment work was where most of the real effort went. Getting Fraud Operations and the Digital team to agree on the feature boundaries between their platforms required sustained negotiation, not just a few meetings. Each organization had legitimate constraints. Fraud Operations had regulatory requirements and claims automation rules that could not be compromised. The digital team had UI standards, accessibility requirements, and a mobile-first architecture. The question of what belonged in each system, and where shared responsibility started and ended, took months to resolve.
We delivered in three sequential MVPs. Fraud debit first, chosen for volume, regulatory priority, and the clearest path through the Pega integration. Non-fraud debit second, using the same API layer but expanded and re-indexed to carry the different information requirements of non-fraud claim types. For the third phase, credit and co-branded cards, I completed full discovery and mapped the architecture against TD's card processing system before my engagement concluded. The discovery artifacts were handed off to the continuing team.
The digital channel submitted claims via API to the Pega system. New APIs had to be designed, agreed upon, and built from scratch. Claim automation rules had to be pulled through Pega AI and exposed in a format the digital front-end could act on. Every data field, every validation rule, and every error state required negotiation between two engineering teams with no prior working relationship and no shared data model to start from.
The Hard Calls
Three decisions
that shaped
the build.
We analyzed four options: modify Pega to accept free-text address fields and remove zip code as mandatory; redirect customers to phone or branch; use the relationship manager address on file rather than the core banking EFT address; or integrate a third-party address verification service for non-US addresses. Each option was assessed against development impact, data reliability, and compliance exposure.
The impacted segment was less than 3% of dispute volume. Third-party non-US address data was unreliable. Free-text field changes required API and schema modifications with downstream compliance implications. The RM address option introduced its own data integrity risk.
I ran the math. Forty-one letter types, 10 with variations, annualized at current run rate, factoring in full letter production cost per unit. Total estimated annual storage cost came to approximately $235,000. I mapped that against actual customer and operational value: customers rarely needed to retrieve historical dispute letters through the digital channel, and Fraud Operations had existing workflows for document access. The ROI did not hold.
The limit was not a Pega constraint. It was set at the processing network level, applicable to all dispute submissions regardless of channel or system. There was no path to expanding it on our timeline. We accepted it as fixed, adjusted the UX to manage whitespace handling within the constraint, and moved on.
The Outcome
From phone queue
to digital channel.
At scale.
The fraud debit MVP launched and drew 28% of TD's debit dispute volume off the phone channel and into the digital experience. At over 70,000 debit claims per month, that shift in channel mix represented a material change in unit economics, contributing to the $106M+ financial impact attributed to the platform.
Within weeks of the fraud debit MVP launch, TD's marketing team reported an 86% customer adoption rate for the new digital channel. The number reflected how sharply digital-first customers had been underserved by the phone-only model. When a capable digital path existed, customers took it without friction.
The platform earned back-to-back Delivery Excellence Awards at TD, ranked first out of more than 100 enterprise-wide submissions in consecutive years.
"What I'd do differently."
The hardest part of this engagement was not the technical architecture. It was the time it took to establish shared language between two organizations that had never needed to collaborate before. The digital team had no framework for thinking about claims workflows. The Fraud Operations team had no framework for thinking about API contracts or mobile UX constraints. A significant portion of early discovery was spent building that shared vocabulary from scratch, time that could have been compressed if the right stakeholders had been aligned before requirements work began.
If I ran this engagement again, I would push harder to get Fraud Operations leadership, specifically the people with authority over the Pega platform and its budget, to the table at the start of discovery, not after the digital team had already formed its assumptions. And I would have made the case earlier for a single executive sponsor with authority across both organizational lines. Cross-organizational 0-to-1 builds need a named decision-maker above the seam. Consensus across it is not a substitute.