UX & Product Strategy Case Study:
SMBC Customer Authentication Portal (CAP)
Modernizing & Safeguarding $10B Weekly in Commercial Loan Remittance Instructions
Project Details
Role/Contribution: UX and Product Strategist, Information Architect, UX Researcher
Cross-Functional Team (Co-Shore): Delivery Lead, Product Designer, Technical Architect, Software Engineer (2), QA Engineer (2)
Industry: Enterprise, Financial Services (Commercial Banking)
Project Timeline: 24 Weeks
High-Level Objectives
Analyze, validate, and prioritize changing business requirements to mitigate scope creep and ensure on-time delivery
Design complex role and permission-based user flows for efficient, frictionless, and secure task completion
Develop and sell a user research strategy to identify and remediate product defects and generate internal excitement before launch
The Challenge
SMBC, a leading multinational bank, receives loan remittance instructions (Standard Settlement Instructions or SSIs) from its commercial banking customers via non-digital channels (phone, fax, email), requiring manual callbacks to authenticate. As a result, the bank experiences processing delays and an increased risk of fraud.
Problem Statement
SMBC needs an end-to-end solution to collect, authenticate, and track customer remittance instructions that is secure, reliable, and auditable.
So, how might we streamline remittance provision for SMBC and its customers while reducing the risk of fraud?
Insights & Impact
Centralized user management is necessary to reduce risk.
The initial discovery phase recommended a delegated user management approach where internal account managers could manually add customer admin users to SSI requests. Subsequently, these customer admins could onboard and manage additional customer users without account managers. This approach emphasized speed by allowing customer admins to be responsive to their organizational needs and reduce SSI turnaround time.
Through conversations with senior stakeholders, subject matter experts, and our engineering team, we flagged this as a high-level security risk that could expose SMBC to legal, financial, and reputational damage. We recommended prioritizing security over speed by tasking user management to internal account managers and integrating CAP with the bank's KYC (Know Your Customer) systems for enhanced customer screening and risk assessment. This layered approach ensures that SMBC meets its regulatory requirements and enhances security when combined with ID verification and multifactor authentication.
Stakeholders agreed with our recommendation, and by pivoting, SMBC mitigates the risk of fraud and remains legally compliant by maximizing existing resources. Despite reduced flexibility in user management, customers still receive an improved, digitized SSI provision experience compared to the previous manual callback process. This "strategic tradeoff" balances the needs of users and the business, delivering long-term value to both.
Permission-based approvals support faster SSI turnaround.
The first iteration of CAP did not include a customer approval process for SSIs (four-eyes principle). Upon the inclusion of this new requirement, we considered utilizing the two original customer roles—admins would author the instructions, and contributors would approve. However, this approach did not consider that requests often contain multiple SSIs that can be added or modified at different times, with each of these actions requiring a four-eyes check.
Through user flows and service blueprinting, we concluded that there wasn't a need for two external user roles due to similar tasks. A single customer admin role, paired with a permission-based SSI approval process, would simplify user management and give customers increased flexibility to add and approve (or reject) multiple instructions within a request as needed. Once a customer admin authors an SSI, any other customer admin on the request may complete the four-eyes check, helping to ensure a faster instruction turnaround.
We consulted engineering, validated the feasibility, and made our recommendations to stakeholders, who approved the design change. For SMBC, this approach yields more accurate remittance instructions, streamlines user management, and reduces the risk of fraud. In addition, this approach lets customers complete requests quickly and efficiently and receive their loan dispersals faster.
Permission-Based Four-Eyes Check Process
Notifications drive efficiency and help mitigate fraud.
One of the main advantages of CAP over the previous manual callback process is that customers can complete SSI provision outside of business hours. This ability is critically important, considering account managers and bank customers are distributed globally across multiple timezones, and is one of the drivers of increased efficiency. In addition to being asynchronous, workflows are interdependent, requiring certain users to complete a task before the workflow can be completed (e.g., SSI review and approval).
The original design for CAP did not include notifications; however, the complexity of these workflows required internal and external users to stay on top of their tasks. Therefore, we recommended adding a notification center to the design to maintain process efficiency and provide a quality experience. Technical consultations with engineering were essential in adding this feature, as we needed to evaluate the feasibility of adding this feature within the project timeline and determine notification triggers. We also needed to work with SMBC legal to craft the copy for notifications, as CAP is a consumer-facing product.
Not only do notifications expedite SSI provision and loan disbursement, but this feature also enables account managers to oversee workflow progress and monitor for fraud: delays in providing required information are often a red flag for malicious activity. And, since account managers oversee numerous customer organizations, these notifications help manage their workload.
Note: For further information on findings and insights, please contact me.
Early Prototype Without Notifications
Final CAP Design With Notifications
Methods
Below are some key methods I used throughout the project and the reasons for choosing them.
Business Requirements Analysis
A previous discovery phase yielded preliminary recommendations and low-fidelity prototypes, which SMBC then used to create the first draft of the business requirements documents (BRD). I analyzed the initial document to identify new and updated requirements (including system and vendor integrations) to ensure the portal met the needs of the business.
In addition, I prioritized requirements based on business objectives and technical feasibility (in collaboration with engineering) to avoid scope creep and maintain the project timeline. Multiple revisions to the BRD (five in total) required continued analysis and stakeholder negotiation throughout the project.
Business Requirements Analysis and Tracking
Stakeholder Analysis & Management
As a customer-facing product, the CAP project involved multiple decision-makers across several internal groups. In this context, devising a client management strategy was essential to gaining trust and establishing effective communication.
I developed a stakeholder analysis that went beyond traditional power-interest mapping to consider levels of authority, influence, knowledge, trust, focus, participation, and investment. As a project team, we assessed each stakeholder and then created individualized management strategies. For example, a stakeholder low in authority and focus while high in participation should be invited to key meetings to avoid having the conversation going off-track.
Stakeholder Analysis Workshop
Service Blueprinting
SSI provision is a complex, cross-functional process involving multiple internal and external people, touchpoints, and backend systems. I partnered with design and engineering to visualize the relationships between these components using service blueprints. This approach provided our team, the client, and third-party vendors with a comprehensive, systemic understanding of the customer journey. Through service blueprinting, we identified customer four-eyes checks for SSIs as an area for optimization, helping to reduce provision turnaround time. In addition, the service blueprint exposed critical dependencies impacting security (e.g., multifactor authentication and ID verification).
Iterative Service Blueprints
User Flows
With multiple user roles and complex workflows spanning different touchpoints, I needed to map out the steps needed to complete various tasks through user flow diagrams, and doing so earlier in the project ensured the team could clarify the complexity and relationships of these interactions. Focusing on flows instead of visual designs in the critical early stages of the project allowed us to get more productive feedback from stakeholders and quickly identify challenges and opportunities before we had committed to higher fidelity design or code.
I built upon the recommendations of the previous discovery phase and iterated multiple times based on continuous feedback from design, engineering, and stakeholders. As a result, we were able to consolidate and streamline unnecessary user roles for increased efficiency. In addition, the ongoing dialog between our team and the client helped shape subsequent BRD revisions, mitigate scope creep, and build trust.
Final Versions of Internal and External User Flows
Status Business Logic
Customers and participating banks provide SSIs through requests generated in CAP by internal account managers. These requests can accommodate multiple SSIs, each requiring a four-eye check by another authorized user from the customer's organization.
To manage this intricate workflow, I collaborated with engineering to develop a hierarchical business logic based on statuses, streamlining the sequence of actions necessary to complete the request and enhancing progress visibility.
Early and Final Versions of Business Logic Diagrams
User Acceptance Testing (UAT)
We tested CAP internally to ensure we met the needs of end users (we did not have access to external customers). In addition, UAT allowed us to uncover, prioritize, and remediate product defects before launch. Resource constraints required an unmoderated approach where participants completed specific role-based test cases and documented their results (including screen captures).
Each of the 18 test cases included specific instructions and the expected results, allowing users to identify defects quickly. In total, 20 participants completed UAT, and the defects encountered were assigned one of four severity levels to prioritize action: regulatory, critical, high, and low.
Planning UAT Tasks by Role in FigJam
Reflections & Learnings
Sometimes, questions are more powerful than answers.
Working with large, waterfall-based organizations like SMBC can prove challenging for agile, digital product-led partners like ourselves. Throughout the project, we were prescribed solutions through business requirements. Occasionally, these requirements did not address the full complexity of the problem or align with the project objectives. In these scenarios, I realized that asking questions was more productive than telling stakeholders they were wrong. This approach allowed them to come to the same conclusion on their own, providing them with a deeper understanding of the issues while helping to build trust.
Educating the client is another way to provide them with value.
Often (but not always), clients seek out external partners to help fill a gap with specific skills or expertise they do not have in-house. In addition to providing SMBC with design, strategy, and digital product engineering, we educated the client on iterative design thinking and agile product engineering, a new approach for most of the client team. Several stakeholders expressed their appreciation for the exposure to our methodology, and this upskilling will provide the client with long-term value as they continue to develop and scale digital products. In addition, this mentoring relationship helps to solidify our relationship with the client as a trusted partner for future projects.
It's imperative to advocate for research.
Initially, the project planned for consultations with internal subject matter experts without evaluative end-user research. Recognizing the challenges in accessing external customers, we still believed that presenting a beta version of CAP to internal end-users was vital. Our suggestion of usability testing met with client skepticism. However, once we introduced the concept as "preliminary user acceptance testing," they were receptive — the familiar terminology eased their concerns. While our ideal scenario would have involved assessing usability and overall user experience earlier in the development process, the insights garnered from UAT were instrumental in refining the final product.