Universal Banker Application
Core banking's complexity reduced to legible, governing elements.
Overview
Fiserv's Universal Banker Application began as a feature-by-feature rebuild of a single legacy teller product. It has since become part of something larger: UBX, the effort to consolidate every core and teller application onto a single teller UI. This case study is about the domain model that makes that consolidation coherent, and what it took to prove the model holds.
The work starts with a mapping. Any core or teller product, including its navigation, its workflows, and its administrative and operational structures alike, can be traced into six behavioral domains:
- System Settings
- Roles & Access
- Transactions & Pricing
- Cash & Currency
- Forms & Communications
- Compliance & Risk
The interactive chart below shows the first such mapping, from the oldest legacy product's interface into the six domains. That mapping is the method, not the deliverable: a taxonomic starting point that any product, or any other surface within the same product, can pass through the same way.
None of it holds without the layer beneath it: a reconciled semantic layer of terms, definitions, and the intent behind them, worked out across products as they converge. When several products each bring their own meaning of “hold” or “alert” into a single interface, reconciliation isn't cleanup after the mapping. It's what the mapping stands on. And because products keep evolving, it's ongoing work, not a completed deliverable.
The domains do more than organize. Each one governs a system behavior, so that a teller mid-transaction, or an administrator configuring the system behind them, doesn't have to hold everything the system is doing in their head for it to behave correctly. Five typed relationships between the domains describe exactly how that governing works:
Together they reach down to a single transaction, where all six domains act simultaneously to keep the outcome consistent. That consistency is deterministic by design. The edges define what must happen and in what order of authority, so outcomes never rest on inference in the places where regulation demands certainty.
The same legibility serves two audiences. For people, it gives cross-functional and cross-product teams a shared language: the same six domains and five relationships mean the same thing whether the discussion is about design, implementation, or a product that hasn't been mapped yet. For agentic AI, it draws the boundary that makes adoption safe: inference belongs where it genuinely helps, including conversational guidance, onboarding, and fielding early process questions, and stays out of execution, where the edges keep outcomes deterministic.
That deterministic consistency is what a single teller UI requires when many products converge into it, and it's what banking's emerging global standards assume but don't supply. BIAN, the industry framework Fiserv partners with, standardizes the structural scaffolding of core modernization; the specific behavioral rules that make that scaffolding function are left to the implementing organization. This model is that supply: the same role, at the level of meaning, that Fiserv's Enterprise Services Framework already plays at the level of integration.
Research Approach
The work follows a structured progression from internal structural analysis through iterative external validation with banking professionals.
Phase 1: Structural Analysis
I reverse-engineered the 13 existing Integrated Teller tabs into 6 first-principles, task-based categories. Each category was defined by inclusion and exclusion criteria documented in governance materials designed to prevent future navigation accumulation. Representative features were mapped to the proposed structure to demonstrate how the taxonomy would accommodate both current functionality and future additions.
The framework prioritizes task-oriented mental models over product-centric legacy organization. Categories are designed to answer "what am I trying to accomplish?" rather than "which product feature is this?"
Integrated Teller · Legacy Navigation → Proposed IA
13 Legacy Categories → 6 Proposed Domains
Hover over legacy items or proposed domains to trace consolidation paths.
Phase 2: Unmoderated Tree Test → Round 1
To test whether the proposed structure made intuitive sense to banking professionals who had never encountered UBA or Integrated Teller, I designed and fielded a tree test through UserTesting with a screened panel of banking VPs and system administrators from multiple countries. The test included 18 tasks representative of common banking workflows, with success measured by first-click accuracy, task completion rate, and ultimate correct selection.
The initial overall pass rate was 67.1%, a strong result for a first-iteration tree test conducted with unfamiliar, international participants navigating an abstract interface. The test also surfaced specific areas where task wording and category labels could be refined without requiring structural changes to the underlying framework.
Phase 3: SME Refinement Sessions
Between rounds of external testing, I conducted sessions with internal subject matter experts from other Fiserv core banking and teller products. These conversations served as a structured refinement bridge: SMEs reviewed the IA framework, the navigation model, and the tree test task wording, surfacing terminology mismatches and labeling friction that external participants had flagged with their navigation behavior, without always articulating precisely.
Their feedback informed targeted adjustments to category labels, navigational groupings, and task phrasing ahead of the second round of testing. SMEs also confirmed that the framework was not only applicable to UBA, but could extend across their own product areas, an early signal of cross-product viability.
Phase 4: Unmoderated Tree Test → Round 2
The second tree test was designed to measure the impact of SME-informed refinements with a larger participant pool. The study used 9 tasks (compared to 18 in round 1) and 10 screened participants (compared to 5), allowing for a sharper focus on the most structurally significant navigation decisions and greater confidence in the results.
The improvement was substantial. Overall task success rose to 85.6%, an 18.5 percentage point gain over round 1. Four participants achieved a perfect 9/9 score, and six of ten scored 90% or higher. Multiple tasks reached 90-100% success rates, and post-test participant feedback consistently described the structure as clear, intuitive, and aligned with how they expect banking system settings to be organized.
Phase 5: Moderated Tree Test → Round 3 (Complete)
The third and final round of tree testing was conducted with 10 senior-level Fiserv client participants, including system administrators, VPs of Operations, and other roles directly relevant to UBA's intended user base. Unlike the two prior unmoderated rounds, this study was moderated, allowing for deeper dialogue on labeling choices and category logic.
The results exceeded expectations: greater than 97% cumulative task success. More valuable than the score was the quality of participant feedback. Senior client participants provided discriminating critique that helped sharpen labels to conform to established mental models and semantic associations. The refinements improved category boundary clarity to the point where the structure is now obvious to users without needing to read domain rules.
The framework is validated. The path forward is organizational adoption.
Key Findings
Domain Knowledge as Foundation
Building a credible information architecture for a core banking product requires more than card sorting and category logic. It requires understanding what banking professionals actually do, the regulatory environment they operate within, and the institutional variation that shapes how different organizations prioritize workflows.
Before proposing any structural consolidation, I invested in understanding compliance and prudential regulations governing banking transactions, the competitive landscape across traditional banks, credit unions, neo-banks, and fintechs, how institution type, size, and risk profile shape operational priorities, top level metrics, and the geographic variation in regulatory requirements that Fiserv products need to accommodate across their global client base.
This domain knowledge wasn't background context. It was the analytical foundation that made the 13-to-6 consolidation defensible rather than arbitrary. Without it, the framework would have been a designer's guess. With it, it became a structure banking professionals could navigate without ever having seen the product.
This same logic extends directly to AI readiness. A validated domain taxonomy, one that reflects how banking professionals actually think about their work, confirmed across three rounds of testing with no fundamental structural revision, is the prerequisite for trustworthy agentic systems in regulated environments. Agents don't negotiate ambiguity. They execute on context. If the context is a taxonomy that hasn't been validated against real mental models, the system is confidently operating on someone's internal assumption. Deloitte's February 2026 analysis of Domain-Driven Design in legacy banking modernization makes the same argument from the technical side, that bounded context clarity is the foundation modernization requires. This work approaches that same boundary from the user research and design side, and arrives at the same conclusion.
From Taxonomy to Property Graph
Domain-Driven Design Model w/ Governing Relationships
Check Deposit Example
Hover a relationship type or a domain to trace how the event resolves.
Domains (Behavioral)
- System Settings→ how the system behaves over time
- Roles & Access→ roles, permissions, and access control
- Transactions & Pricing→ rules and limits for movement of money
- Cash & Currency→ control of physical cash & foreign currency
- Forms & Communication→ what the system prints or shows
- Compliance & Risk→ regulatory enforcement and audit posture
Governing Relationships
- Has Primacy Over→ Governs first; wins under contention
- Authorizes→ Gates whether the actor may act
- Constrains→ Bounds how or whether it executes
- Triggers→ Creates an obligation in that domain
- Renders→ Produces an output or record there
This diagram emerged by extending the mapping of the legacy navigation items into the six behavioral domains shown above, illustrating more precisely the governing relationships between each in the context of a single, specific transaction, moving the description beyond abstraction and grounding it in a concrete example. Those six domains, System Settings, Roles & Access, Transactions & Pricing, Cash & Currency, Forms & Communications, and Compliance & Risk, weren't invented. They were surfaced.
The governing relationships followed the same logic. Every transaction in a banking system already has a resolution path: compliance constrains, roles authorize, settings bound, cash asserts primacy, forms render the output. Naming those edges explicitly turned a taxonomy into a property graph: human-readable for cross-functional alignment, machine-readable for implementation, and AI-legible for agentic systems that need to know not just what domains exist, but how they govern each other under contention.
This diagram is a single moment: one transaction, one event, one slice of what the full model governs. But it's the right slice, because it shows that the logic holds all the way down to the regulatory citation level.
Client Validation Exceeds 97% (Round 3)
The final moderated round with 10 senior-level Fiserv client participants achieved greater than 97% cumulative task success. Participants included system administrators, VPs of Operations, and other roles directly relevant to UBA's intended user base. Their discriminating critique helped sharpen labels to conform to established mental models and semantic associations, improving category boundary clarity to the point where the structure is obvious to users without needing to read domain rules.
The framework is validated across three rounds of testing with no fundamental structural revision required.
Navigation Structure Validated (Round 1)
The first round of external validation tested whether the proposed structure made intuitive sense to banking professionals with no prior exposure to UBA or Integrated Teller. Eighteen tasks were fielded through a screened UserTesting panel of banking VPs and system administrators from multiple countries.
The overall pass rate of 67.1% was a strong result for a first-iteration tree test conducted on an abstract interface with unfamiliar international participants. One participant achieved 94.4% accuracy, 17 of 18 tasks correct, demonstrating that the framework's ceiling was reachable. The test also identified specific task wording and labeling friction that pointed toward clear, targeted refinements without requiring structural overhaul.
SME Sessions Sharpen the Framework
Between rounds of external testing, sessions with internal subject matter experts from other Fiserv core banking and teller products provided a structured opportunity to interrogate the framework from the inside. SMEs reviewed the IA categories, the navigation model, and the tree test task wording, identifying terminology mismatches and labeling ambiguities that external participants had signaled but couldn't always name precisely.
Their feedback informed targeted adjustments to category labels, navigational groupings, and task phrasing, changes designed to reduce cognitive friction without altering the underlying structural logic the first round had already validated.
Validation Strengthens Across Rounds
The impact of SME-informed refinements is most clearly visible in the jump from round one to round two. With 10 participants and 9 tasks, the second tree test was designed for sharper focus and greater statistical confidence. The results were unambiguous.
Overall task success rose to 85.6%, an +18.5 percentage point improvement over round one. Where one participant had cleared 90% in round one, six did in round two. Four participants achieved a perfect 9/9 score. Multiple tasks reached 90–100% success rates across the panel. Post-test feedback consistently described the structure as clear, intuitive, and aligned with how participants expect banking system settings to be organized.
The pattern is not just improvement, it's the framework becoming reliably learnable across a broader range of participants.
Cross-Product Applicability Confirmed
SME sessions surfaced a finding that extended beyond UBA's immediate scope. Every SME who reviewed the framework confirmed it would work for their own core banking and teller products, not just the product it was originally designed for.
This cross-product signal positions the IA framework as potential shared infrastructure across Fiserv's banking product suite, a structural foundation that could reduce fragmentation, improve consistency, and lower training and support overhead for clients using multiple Fiserv products. It is an early but meaningful indication that the framework's logic is sound at a category level, not just within a single product context.
Governance Documentation Prevents Regression
The inclusion and exclusion criteria documented for each IA category create a decision-making framework for future feature additions. As UBA continues to expand, this governance layer provides clear guidance on where new functionality belongs and why, preventing the gradual accumulation of misplaced features that produced the navigation problem this work was designed to solve. The value of this documentation compounds over time: it is most useful not at launch, but at every subsequent product decision that follows.
Notably, across every phase of this work, from initial structural analysis through two rounds of external tree testing and multiple SME sessions, the governing logic of the framework has remained intact. Minor terminology adjustments have improved clarity at the surface, but the categorical structure itself has required no fundamental revision. Each iteration has confirmed its correctness rather than challenged it.
"We're blocked from meaningful usability tests because the current navigation is incoherent. Participants will get lost in structure, not features. If we adopt this framework now, we can more readily validate workflows."
Impact & Reflection
The validation trajectory on this project is clear and strong. Two rounds of external tree testing with screened banking professionals, SME sessions that sharpened the framework between rounds, and a third moderated round with known Fiserv clients underway, the research has done what research is supposed to do: reduce uncertainty, build evidence, and point toward a decision.
What the research has delivered to date:
A validated IA framework that rose from 67.1% to 85.6% to greater than 97% overall task success across three rounds, culminating in a moderated study with 10 senior-level Fiserv client participants. Their discriminating feedback sharpened labels to conform to established mental models, improving category clarity to the point where boundaries are obvious without reading domain rules. Cross-product applicability confirmed by SMEs from multiple Fiserv product areas. Governance documentation that gives the team a durable decision-making tool for future feature additions.
What remains unresolved is not the research. It is the organizational question of when and how the findings get acted on. That gap between evidence and adoption is a reality of doing strategic research inside a product development process that is still in motion. The team is heads-down on feature delivery, and structural questions like navigation are easy to defer when shipping feels more urgent. Naming that dynamic honestly is more useful than pretending it isn't there, or understating what's actually at stake.
There is a broader reason this work matters beyond navigation. A validated domain model, one that banking professionals recognize without training, is a prerequisite for any credible agentic AI integration. If internal teams and clients cannot agree on how banking operations are categorized, scoping AI agents against that structure is guesswork. This IA framework is not just a navigation fix. It is the semantic foundation that any future automation, intelligent routing, or agent-assisted workflow would need to operate reliably.
What this project continues to reinforce is that the work worth doing is rarely the work you were asked to do. I was engaged to run usability studies. What I saw was a problem that would have made those studies unreliable until it was solved. Solving it first (abstractly, rigorously, and in advance of feature completion) is the kind of contribution that doesn't always show up on a sprint board but shapes everything that follows, from Jira tickets to leadership messaging.
The moderated client round will close the external validation loop. What comes next is a communication and alignment challenge, and one I intend to meet directly.