Wells Fargo Merchant Services

MSOW: risk and operational workflow modernization.

Product Owner supporting MSOW — Merchant Services Operational Workflow — a Pega-based application housing two distinct business workflows: Risk Profile Assessment (RPA) and Shared Mailbox (SMB).

Product Ownership Pega Merchant Services APIs Email Listeners Agile Delivery UAT

Role

Product Owner

Application

MSOW — Merchant Services Operational Workflow

Platform

Pega

Core Workflows

RPA & Shared Mailbox

01 / Overview

One Pega application supporting two very different business problems.

I supported Wells Fargo Merchant Services through MSOW — Merchant Services Operational Workflow, a Pega-based application used to create structured, trackable business workflows.

Within MSOW, I worked across two primary initiatives. Risk Profile Assessment (RPA) supported Merchant Services risk and credit review processes. Shared Mailbox (SMB) focused on modernizing email-driven operational work that had traditionally been handled through Outlook shared mailboxes.

Although both workflows lived within MSOW and used Pega, their integrations, data sources, users and business processes were different. Understanding those differences was an important part of translating business requirements into executable product work.

MSOW

Pega Application

Merchant Services Operational Workflow served as the Pega application housing RPA and SMB workflows.

RPA

Risk & Credit

Merchant risk-profile assessments supported by MSCD, APIs and merchant-risk information.

SMB

Operations

Shared-mailbox modernization using Outlook, email listeners, Pega cases, queues and routing.

UAT

End-to-End Validation

Supported test planning, execution, defect triage, retesting and business signoff.

02 / MSOW Platform

MSOW was the application. RPA and SMB were workflows within it.

This distinction is important when explaining the architecture. MSCD was not the backend for all of MSOW. It specifically supported the RPA ecosystem, while SMB relied primarily on Outlook/shared-mailbox integration and Pega email-listener functionality.

MSOW — Merchant Services Operational Workflow

Pega-based application providing workflow, case-management and user-interface capabilities for Merchant Services business processes.

Workflow 01

RPA

Risk Profile Assessment supported merchant risk and credit reviews.

Merchant risk assessment
MSCD integration
API-driven merchant information
Credit exposure and collateral
Approval workflow

Workflow 02

SMB

Shared Mailbox modernized email-driven Merchant Services operational work.

Outlook shared mailboxes
Email listeners
Pega case creation
Queues and worklists
Routing and resolution

03 / Product Portfolio

Two workflows. Two integration patterns. One product ownership approach.

Both initiatives used Pega to create structured and traceable workflows, but each addressed a different Merchant Services business problem.

Workflow 01

Risk Profile Assessment

Internal merchant underwriting and risk-monitoring workflow for Merchant Services Risk and Credit teams.

Risk & Credit

Supported periodic merchant reviews across yearly, quarterly, monthly and custom review cycles.
Worked with merchant information, risk exposure, collateral, ratings and credit-approval information.
Supported risk indicators including BQR, CQR, AQR, NDX, chargebacks and refunds.
Worked with MSCD as an upstream Merchant Services credit-decisioning and data platform.
MSOW consumed MSCD APIs to support the RPA workflow.
Partnered with Risk, Credit, Compliance, Change Managers and development teams.

Workflow 02

Shared Mailbox

Pega case-management workflow designed to modernize fragmented Outlook-based operational handling.

Operations & Workflow

Helped convert shared-mailbox activity into structured Pega cases.
Supported email-listener behavior connecting Outlook/shared-mailbox activity with MSOW.
Worked with worklists, unassigned queues and routing rules.
Helped define relationships between ET cases and linked SR cases.
Supported visibility into action-needed items, close times and operational follow-up.
Partnered with Operations, Change Managers and developers through build, UAT and launch preparation.

04 / Technical Context

Understanding the integrations behind each workflow.

As Product Owner, I did not implement every technical component. My responsibility was to understand how those components affected business behavior, requirements, dependencies, testing and delivery.

RPA Architecture

Merchant data → MSCD → MSOW

RPA relied on merchant information and capabilities supplied through the MSCD ecosystem.

Fiserv / Merchant Data Upstream merchant information

MSCD Credit decisioning, data and analysis

MSCD APIs Exposed data and functionality

MSOW / RPA Pega workflow and UI

Risk / Credit Review and decision

Key distinction: MSCD was an upstream system and API provider for RPA. MSOW/RPA was the downstream consumer providing the Pega user experience and workflow.

SMB Architecture

Outlook → Email Listener → MSOW

SMB used a different integration pattern centered around email intake and operational case management.

Outlook Shared mailbox / incoming email

Email Listener Monitors and processes email

MSOW / SMB Creates structured Pega work

ET / SR Cases Case relationships

Queue / Worklist Routing and operational handling

Key distinction: SMB was primarily an email-listener and workflow-routing solution. MSCD was not the backend for SMB.

05 / RPA Deep Dive

Risk Profile Assessment.

RPA supported Merchant Services Credit and Risk teams in evaluating merchants and determining whether the merchant's risk profile remained acceptable to the bank.

Important Systems

MSOW: Pega workflow and UI.
MSCD: upstream Merchant Services Credit Decisioning application/data platform.
ICMP: enterprise document storage used for supporting documents.
CAAMS: supported approver lookup for approval-related workflow.

What the Underwriter Reviewed

Merchant profile information
Merchant hierarchy
Processing activity
Risk exposure
Risk ratings

Chargebacks and refunds
Collateral
Credit amount / exposure
Bank relationship information
Supporting documentation

Simplified RPA Workflow

The exact path could vary depending on the review, but the workflow can be explained through these major business activities.

Case Creation

RPA initiated through periodic review activity or risk/alert-related activity.

Merchant Review

Review merchant profile, hierarchy, processing and relevant risk information.

Risk Analysis

Evaluate risk indicators, exposure, ratings and processing behavior.

Gather Information

Request additional information when needed, including from Relationship Managers.

Documents

Upload or reference supporting documentation through the document-management process.

Bank Relationship

Consider other products or services associated with the merchant relationship.

Collateral

Review collateral information as part of the overall risk assessment.

Credit Exposure

Evaluate the amount of processing-related credit risk the bank is willing to assume.

Approval

Route for appropriate approval where required.

Resolution

Complete the assessment after analysis, documentation and required approvals.

06 / SMB Deep Dive

Shared Mailbox modernization.

SMB addressed a different operational challenge: business activity arriving through shared Outlook mailboxes needed a more structured way to become trackable work.

Rather than relying entirely on employees to manually monitor, organize and track email activity, MSOW could use email listeners and Pega case-management capabilities to create structured operational work.

Key SMB Concepts

Outlook shared mailboxes
Email listeners
Automated case creation
ET cases
Linked SR cases

Worklists
Unassigned queues
Routing rules
Action-needed work
Close-time reporting

Simplified SMB Workflow

SMB converted incoming email activity into structured operational work that could be assigned, tracked and resolved inside Pega.

Email Received

Business request or communication arrives in an Outlook shared mailbox.

Email Listener

The configured listener monitors the mailbox and processes incoming email.

Pega Case

Email activity becomes structured work within the MSOW Shared Mailbox workflow.

ET Case

Email-related activity is represented and tracked through the appropriate case structure.

SR Relationship

Where applicable, related Service Request cases can be linked to the email-driven work.

Queue / Worklist

Work is placed into the appropriate queue, worklist or unassigned inventory.

Routing

Business rules help route work to the appropriate operational user or team.

Resolution

Users complete the required work while Pega provides case history and operational visibility.

07 / Compare the Workflows

RPA vs. SMB.

This comparison highlights the breadth of the MSOW work and the different business and technical problems addressed by each workflow.

Area	RPA	SMB
Full Name	Risk Profile Assessment	Shared Mailbox
Parent Application	MSOW / Pega	MSOW / Pega
Primary Business Problem	Merchant risk and credit assessment	Email-driven operational case management
Primary Integration	MSCD APIs and merchant data	Outlook/shared mailbox and email listeners
MSCD Involvement	Yes — upstream data/application and API provider	No — MSCD was not the SMB backend
Main Users	Risk / Credit / Underwriting	Merchant Services operational teams
Key Data / Work	Merchant information, exposure, ratings, collateral, documents and approvals	Incoming emails, ET/SR cases, queues, assignments, routing and follow-up
Core PO Challenge	Translate risk rules, data dependencies and integration behavior into usable workflow	Translate manual email operations into structured, trackable case-management behavior

Data & Architecture

Technical terminology I used around the products.

Understanding these concepts helped bridge conversations between business stakeholders, developers and other technical teams.

Data Source

The originating source of information—for example merchant data entering the RPA ecosystem or email entering SMB.

Data Ingestion

Bringing information into a system so it can be stored, processed or used by a workflow.

Transformation

Changing the structure, format or representation of data so the receiving system can use it.

API Consumer

The application calling an API. In the RPA relationship, MSOW consumed capabilities exposed by MSCD.

08 / My Contribution

Where I added value as a Product Owner.

My contribution combined product ownership, business analysis, stakeholder coordination, technical translation and quality validation.

Product & Backlog

Translated stakeholder needs into user stories.
Defined acceptance criteria, including Gherkin-style scenarios.
Supported refinement, prioritization and sprint readiness.
Clarified scope, dependencies and sequencing.
Maintained a forward-looking backlog for upcoming work.

Stakeholder Partnership

Worked across Risk, Credit, Compliance and Operations.
Partnered with Change Managers and development teams.
Clarified business rules and workflow behavior.
Connected business outcomes to technical discussions.
Used demos and feedback to refine the product.

Quality & UAT

Prepared UAT scenarios mapped to stories and criteria.
Covered happy paths, edge cases and permissions.
Validated routing, queues, notifications and business rules.
Coordinated defect triage, retesting and status updates.
Supported formal business signoff before launch.

09 / Delivery Approach

From discovery to production with feedback built in.

The work followed iterative Agile delivery. The goal was not just to write requirements—it was to continuously move from business problem to testable functionality and validated outcomes.

Discovery & Alignment

Understand the problem, users, current process, desired behavior and constraints.

Requirements & Refinement

Break needs into stories, acceptance criteria, dependencies and sprint-ready scope.

Sprint Build

Partner with developers and stakeholders as functionality is implemented incrementally.

UAT & Defect Triage

Validate end-to-end behavior, log defects, prioritize issues and coordinate retesting.

Demo, Signoff & Launch

Demonstrate functionality, incorporate feedback, secure business approval and support production readiness.

Warranty & Reporting

Support post-launch follow-up, operational visibility and reporting needs.

10 / UAT

Validating the business process, not just the screen.

For enterprise workflows, a screen can function correctly while the overall business process still fails. UAT focused on whether the complete journey supported real users, rules, routing and dependencies.

UAT Coverage

Confirm entry criteria after QA/system integration testing.
Map test scripts to user stories and acceptance criteria.
Validate happy-path, negative, edge-case and permission scenarios.
Test workflow routing, queues, notifications and business rules.
Coordinate daily status, defect triage and retesting.
Support final business signoff before production launch.

11 / Outcomes

Creating structure, traceability and operational visibility.

The work helped move complex business activity into defined workflows with clearer ownership and more consistent case history.

Structured Workflows

Converted risk and email-driven activities into defined Pega case processes.

Better Visibility

Supported visibility into case status, action-needed work, progress and close times.

Clearer Dependencies

Connected product requirements to APIs, data sources, email listeners and supporting systems.

Cross-Functional Delivery

Aligned business users, Change Managers, developers and testing partners around shared outcomes.