2026

TrustPath

An adaptive provisioning trust framework for , making friction proportional to risk.

My Role

Product Strategy, Technical Product Thinking & Launch Execution

Project Timeline

June 2026

Project Stack

Apple Pay currently establishes trust through verification channels instead of trust signals, creating a system that is simultaneously too difficult for legitimate users and too weak against sophisticated fraud.

Apple Pay trust balance between legitimate users and fraud risk

00A Note on This Project

This project was built as a structured product strategy exercise targeting the Apple Pay PM role. The problem framing, provisioning system architecture, stakeholder analysis, goals framework, and ML decisioning structure are grounded in Apple's documented ecosystem, public payment standards, and real data sources including Federal Reserve payment surveys and CFPB complaint data.

Several sections, concept ideation, Pugh matrix scoring, preference testing, and the technical build plan, are structured as this is how I would approach this stage rather than executed deliverables. These sections are labeled. Where the work is directional, it reflects genuine product process thinking applied to a real problem, not a hypothetical exercise.

The goal is to show how I think, how I structure ambiguity, and how I would operate in this role from day one.

Phase One

Discovery

What is the problem? Why does it matter? Who is affected?

01What is the Problem?

provisioning is fundamentally a trust-establishment problem that is often solved through verification mechanisms.

Common verification channels

-SMS OTP
-Email verification
-Issuer app authentication
-Call-center assisted verification

The gap

These methods verify access to a channel. They do not always prove that the user, device, and cardholder relationship should be trusted.

The Provisioning Tension

Legitimate users face

Delayed SMS codes
Forgotten issuer credentials
App switching mid-setup
Confusing error states
Call-center waits

Fraudsters exploit

SIM swapping
Account takeover
Stolen credentials
Synthetic identity
Social engineering

The result: a provisioning system that can become too difficult for legitimate users and still too weak against sophisticated fraud.

03Why This Matters

Four Business Outcomes

01 /

adoption

Activation gateway

Every failed provisioning attempt is a user who intended to use but did not successfully activate it.

02 / Transaction volume

Downstream revenue

Provisioned cards create future payment volume. Failed provisioning reduces downstream engagement across the ecosystem.

03 / Issuer trust

Partner confidence

Issuers need confidence that provisioning reduces risk rather than increasing fraud exposure or operating burden.

04 / Brand trust

First moment of use

promises privacy, security, and simplicity. Provisioning friction undermines that promise at the first use moment.

04Current State

The Provisioning Flow

The biggest tension sits in the middle. Medium-confidence attempts fall into channel-based step-up flows where friction and fraud collide.

05Core Product Insight

The wrong question

Did the user complete a verification challenge?

The right question

Do we have enough trusted evidence to allow this device to represent this credential?

This reframes provisioning from a verification problem into a trust decisioning problem.

06Stakeholders

Multi-Sided Ecosystem

Users

The person adding a card

Want instant setup, clarity, and confidence. They should not be punished because the system cannot distinguish them from fraudsters.

Apple

Platform owner

Owns the Wallet experience, device security, privacy model, and ecosystem trust. Apple is uniquely positioned to solve this.

Issuers

Banks and card issuers

Own cardholder relationships, risk appetite, fraud liability, and approval decisions.

Networks / TSPs

Tokenization rails

Operate token lifecycle management and see patterns across the ecosystem that a single issuer cannot.

Fraud and Ops

Risk teams

Need better signals, fewer false positives, and lower manual review burden.

Legal and Privacy

Compliance

Ensure identity verification remains consented, minimal, explainable, and compliant across regions.

07User Research MethodsSTRUCTURED APPROACH · NOT YET EXECUTED

How We Researched the Problem

Method 1

User Interviews

Recruited users who had successfully added cards, failed to add cards, completed SMS verification, used issuer app verification, called issuer support, or experienced suspected fraud. Goal: understand where friction occurs and which failure states users attribute to Apple vs. their bank.

Method 2

Apple Support Community Mining

Searched for patterns around: cannot add card, card not added, Apple Pay verification, Wallet verification failed, call bank to verify Apple Pay, and Apple Pay card declined during setup.

Method 3

App Store Review Mining

Analyzed reviews for Wallet and issuer apps mentioning: Apple Pay, verification, add card, fraud, OTP, call bank, and Wallet failure.

Method 4

CFPB Complaint Analysis

Used the public complaint database to classify themes: unauthorized use, digital wallet, verification failure, account takeover, disputes, and customer service.

Method 5

Expert Interviews

Spoke with former payments PMs, fraud analysts, banking operations professionals, compliance experts, and support agents to understand issuer-side decisioning and the operational cost of current verification paths.

08Root Cause AnalysisMY FRAMEWORK

The 5 Whys

Why

Finding

Why do legitimate users face friction and fraudsters still pass?

Provisioning relies on channel-based verification.

Why does it rely on channels?

Issuers need a quick way to establish cardholder confidence.

Why don't issuers have better options?

They lack high-confidence device, identity, and behavioral signals.

Why are those signals missing?

Trust is fragmented across Apple, issuer, network, and device systems.

Why is trust fragmented?

The ecosystem lacks a unified privacy-preserving trust layer for provisioning.

Root cause: Fragmented trust. Apple has device signals, issuers have cardholder signals, networks have token signals, users have identity credentials, but the provisioning decision collapses into a low-quality verification challenge.

False friction

Good user forced through unnecessary verification.

False approval

Fraudster passes weak verification.

False decline

Good user blocked entirely.

Operational escalation

User must call support.

Unclear ownership

User cannot tell if Apple or issuer caused the failure.

Phase Two

Definition

Requirements, solution direction, trust dimensions, decision ladder.

09Requirements

What the Product Must Do

Reduce unnecessary step-up verification.
Preserve issuer control over decisioning.
Improve fraud signal quality.
Support privacy-preserving identity verification.
Gracefully handle users without Wallet identity credentials.

Operate within low-latency provisioning constraints.
Create measurable improvements in conversion and fraud outcomes.
Support issuer-by-issuer rollout.
Include experimentation and feedback loops.

The solution cannot simply be “add more verification.” The better answer is adaptive trust.

10Solution Direction

TrustPath

An adaptive provisioning trust framework that combines multiple trust dimensions to recommend the right provisioning path for each attempt.

Inputs / trust dimensions

Device Trust

Identity Trust

Issuer Trust

Behavioral Trust

Network Trust

Output

Provisioning Trust Decision

The right path for this card, device, user, issuer, and risk context.

11Trust Dimensions

Five Signal Categories

Trust Dimension Orbit

Device

Device Trust

Device age, tenure, biometric enrollment, Wallet history, prior usage, and trusted device relationships.

Identity

Issuer

Behavioral

Network

12The TrustPath Decision LadderPROPOSED FRAMEWORK

Trust Score to Provisioning Path

Trust Score

Path

User Experience

> 90

Instant Provisioning

Add Card → Face ID → Card added. No step-up.

70-90

Passive Verification

Silent signal check. Minimal friction. Card added with brief confirmation.

50-70

Wallet ID Verification

Verify with your ID in Wallet. Face ID → Wallet attestation → Card added.

30-50

Enhanced Issuer Verification

Issuer-led step-up with richer trust signal package. SMS / issuer app / call center.

< 30

Decline

Clear explanation. Recovery options presented. Issuer contact path surfaced.

Score is computed from composite signals across all 5 trust dimensions. Issuers retain final approval authority. TrustPath provides the signal and recommendation, not the binding decision.

Phase Three

Ideation

Weaknesses

A - Wallet ID Step-Up

selected

Use Wallet identity credentials as step-up when issuer confidence is medium.

Strong identity assurance, fast UX, privacy-preserving.

Adoption constraints, regulatory complexity.

B - Issuer App Fast Lane

Route users to issuer app when installed and trusted.

Issuer-controlled, strong existing relationship.

Not all users have app, context switching remains.

C - Device Reputation Layer

selected

Use device tenure, biometric state, Wallet history as primary risk signal.

Apple's unique advantage, low user friction, scalable.

Cold-start problem, insufficient alone.

D - Behavioral Trust Engine

Use behavioral and velocity patterns to adapt verification dynamically.

Dynamic fraud detection, useful for emerging attacks.

Explainability concerns, privacy sensitivity.

E - Issuer Risk Console

Give issuers better analytics and controls for Apple Pay provisioning.

Improves partner trust, operationally valuable.

Less direct user impact, slower UX improvement.

F - Safe Recovery Path

selected

Build a better recovery experience when users fail verification.

Reduces abandonment, easier MVP.

Does not reduce fraud.

G - TrustPath Adaptive Decisioning

Combine all signal types into a unified provisioning trust framework.

Solves root problem, scalable platform.

Complex, requires cross-functional execution.

15Down Selection - Round 1SIMULATED · MY APPROACH

Concept Evaluation

Evaluation Criteria

C1User friction reduction

C2Fraud reduction

C3Privacy alignment

C4Engineering feasibility

C5Issuer adoption feasibility

C6Strategic differentiation

C7Time to market

C8Scalability

C9Explainability

C10Apple ecosystem fit

Scoring scale

+2 strong positive / +1 positive / 0 neutral / -1 negative / -2 strong negative

Concept / Criteria	C1	C2	C3	C4	C5	C6	C7	C8	C9	C10	Total
Wallet ID Step-Up advanced	+2	+2	+1	0	0	+2	0	+1	+1	+2	11
Issuer App Fast Lane	+1	+1	+1	+1	+2	0	+1	0	+2	+1	10
Device Reputation Layer advanced	+2	+1	+2	+1	+1	+1	+1	+2	+1	+2	14
Behavioral Trust Engine	+1	+2	0	-1	0	+1	-1	+2	-1	+1	4
Issuer Risk Console	0	+1	+1	+1	+2	0	+1	+1	+2	0	9
Safe Recovery Path advanced	+1	0	+2	+2	+1	0	+2	+1	+2	+1	12
TrustPath Adaptive	+2	+2	+1	-1	0	+2	-1	+2	0	+2	9

Top 3 advanced to preference testing:

1. Device Reputation Layer - 14
2. Safe Recovery Path - 12
3. Wallet ID Step-Up - 11

TrustPath Adaptive Decisioning scores well on differentiation and fraud but loses on feasibility and time to market. It remains the long-term platform vision. The three concepts above are its buildable components.

16From Architecture to Experience

Naming Bridge

The top 3 concepts use internal, architecture-facing names in the scoring exercise. For preference testing, each was translated into a user-facing name that reflects what the experience communicates to the person adding a card, not how the system achieves it. The concepts are identical; only the framing shifts.

Internal Name (Pugh Matrix)

User-Facing Name (Preference Testing)

What Changes

Device Reputation Layer

Trusted Device Fast Lane

Passive trust signal -> experienced as speed and confidence.

Safe Recovery Path

Recovery Assist

Structured fallback -> experienced as guidance after failure.

Wallet ID Step-Up

Wallet ID Verification

Identity attestation -> experienced as a familiar Wallet action.

17Preference TestingSTRUCTURED APPROACH · NOT YET EXECUTED

Prototype Flows Tested With Users

Three flows were tested with users to measure perceived speed, security, privacy, and likelihood to complete. Each concept was presented as a prototype, not a description.

Concept 1

Trusted Device Fast Lane

Device Reputation Layer

"This card can be added instantly because this is a trusted device."

Flow

Add Card -> Face ID -> Card added

The system uses device tenure, biometric enrollment, and Wallet history as passive trust signals. The user experiences no visible verification step.

Concept 2

Wallet ID Verification

Wallet ID Step-Up

"Verify with your ID in Wallet to add this card."

Flow

Add Card -> Face ID -> Wallet ID attestation -> Card added

Identity-native step-up using the user's existing Wallet credential. Replaces SMS OTP for medium-risk attempts.

Concept 3

Recovery Assist

Safe Recovery Path

"We couldn't verify this card automatically. Here are the fastest ways to finish."

Flow

Add Card -> verification fails -> structured options presented: issuer app / Wallet ID / call bank / retry later

Reduces abandonment when primary verification is unavailable by surfacing next-best-action clearly.

Perception attributes measured / 1-5 scale

SpeedSecurityPrivacyClarityControlTrustEaseConfidenceLikelihood to complete

Key findings

Users strongly prefer Face ID-based flows when the trust rationale is explained. Passive trust feels arbitrary without it.
Users worry about sharing government ID unless the privacy boundary is made explicit upfront.
Calling the bank has the highest stated abandonment risk of any option. Users blame Apple, not the issuer.
Users cannot distinguish whether Apple or the issuer is making the verification decision. Ownership clarity materially affects trust perception.
Recovery Assist scores highest on clarity but lowest on perceived security. Users want options but want to understand why they're needed.

18Down Selection - Round 2SIMULATED · MY APPROACH

Final Pugh Matrix

Post-preference testing criteria updated to incorporate user perception data alongside business and technical metrics.

C1Completion likelihood

C2Perceived security

C3Perceived privacy

C4Fraud reduction

C5Engineering feasibility

C6Issuer feasibility

C7Apple differentiation

C8MVP viability

Concept / Criteria	C1	C2	C3	C4	C5	C6	C7	C8	Total
Wallet ID Verification (Wallet ID Step-Up)	+2	+2	+1	+2	0	0	+2	+1	10
Trusted Device Fast Lane (Device Reputation Layer)	+2	+1	+2	+1	+1	+1	+1	+2	11
Recovery Assist (Safe Recovery Path)	+1	0	+2	0	+2	+1	0	+2	8

Selected direction: Trusted Device Fast Lane + Wallet ID Verification combined.

This pairing covers the full trust spectrum with a coherent two-tier model:

High trust → Trusted Device Fast Lane: no visible friction

Medium trust → Wallet ID Verification: identity-native step-up

Low trust → enhanced issuer verification

Very low trust → decline

Recovery Assist does not advance as a standalone concept but is incorporated as the fallback layer within the same product, presented when Wallet ID is unavailable or verification fails. It solves a real problem but is not a differentiated strategy on its own.

The full narrative now reads as one continuous decision thread: 7 concepts → scored on 10 criteria → top 3 advanced → renamed for user testing → preference data collected → rescored on 8 criteria → 2-concept direction selected → Recovery Assist absorbed as fallback layer.

Phase Four

Delivery

MVP scope, user flows, PRD goals, metrics, ML framework, launch strategy.

19MVP ProposalPROPOSED SCOPE

TrustPath Pilot / Five Components

MVP Scope 01

Trust Score Service

Calculates a composite trust score at provisioning time using device, identity, issuer, behavioral, and network signals. Outputs a score, recommended path, and issuer-readable reason codes within real-time latency constraints, while degrading gracefully when signal categories are unavailable.

MVP Scope 02

Trusted Device Fast Lane

Reduce unnecessary verification for high-confidence users with long-tenured, secure devices.

MVP Scope 03

Wallet ID Step-Up

Offer identity-native verification for eligible medium-risk users instead of defaulting to SMS or email.

MVP Scope 04

Fallback / Recovery Assist

Improve fallback options when identity verification is unavailable or fails.

MVP Scope 05

Analytics Dashboard

Track conversion, fraud, step-up completion, support contacts, and issuer outcomes.

20Technical Build PlanPROPOSED APPROACH

From Signals to Pilot Readiness

Phase

Name

Scope

Discovery and Data Access

Identify available signal sources, define feature availability, map issuer API constraints, define fraud outcome labels.

Prototype Decision Engine

Build rules-based trust score, simulate outcomes on historical provisioning data, validate precision-recall tradeoffs.

Wallet ID UX Prototype

Design step-up screens, test consent language, validate privacy explanation comprehension with users.

Pilot Integration

Select 2-3 issuer partners, implement path routing, deploy real-time monitoring and rollback plan.

Measurement

Run A/B experiments, monitor fraud rate, support contact rate, and provisioning funnel; make rollout decision.

21Edge CasesDIRECTIONAL · NOT VALIDATED

Fallbacks, Degradation Paths, and Overrides

Edge Case

Handling

User has no Wallet ID

Route to fallback verification; Wallet ID step-up not presented.

User has expired identity credential

Treated as no Wallet ID; fallback path activated.

Issuer does not support Wallet ID step-up

System degrades to current issuer-preferred path.

Device is new but user is long-tenured Apple ID

Apple ID and Wallet history compensate for low device score.

User recently changed Apple ID password

Triggers risk signal; may route to medium-trust path.

SMS fallback fails

Recovery Assist surfaces issuer app and call center options.

Issuer app not installed

Issuer app fast lane skipped; alternative paths shown.

High-trust user flagged by issuer

Issuer override respected; TrustPath recommendation does not bind.

Identity name mismatch

Routes to enhanced verification; not auto-declined.

Network token service unavailable

Provisioning held; user notified with retry option.

22MVP User Flows

Four Provisioning Paths

Flow A

High trust

Risk path 01

01 / Trigger

Add Card

02 / Routing logic

TrustPath evaluates signals / High trust detected

03 / Verification action

Face ID

04 / Resolution

Card added

User outcome

"That was instant."

Flow B

Medium trust

Risk path 02

01 / Trigger

Add Card

02 / Routing logic

Medium confidence detected / Verify with ID in Wallet

03 / Verification action

Stronger signal to issuer

04 / Resolution

Card added

User outcome

"Secure, but still fast."

Flow C

Low trust

Risk path 03

01 / Trigger

Add Card

02 / Routing logic

Low confidence detected

03 / Verification action

Enhanced issuer verification

04 / Resolution

Clear next step shown

User outcome

"I understand why."

Flow D

No Wallet ID

Risk path 04

01 / Trigger

Add Card

02 / Routing logic

Wallet ID unavailable

03 / Verification action

Fallback options shown

04 / Resolution

Issuer app / SMS / Support

User outcome

"I am not stuck."

23PRD Summary

Goals Across All Stakeholders

User goals

Add card faster
Avoid unnecessary verification
Understand what to do when verification is required
Recover from failed verification

Business goals

Increase provisioning conversion
Reduce fraud-after-provisioning
Reduce issuer operational burden
Increase activation and usage

Partner goals

Improve issuer confidence
Preserve issuer decision control
Provide better risk signals
Reduce manual review volume

North Star Metric

Provisioning Success Rate

24Success Metrics

Measurement Framework

Primary

Step-up completion rate, time to provision, fraud-after-provisioning rate, false-positive rate, issuer approval rate

Secondary

Support contact rate, call-center verification volume, retry rate, fallback completion rate, Wallet ID step-up adoption, user satisfaction

Guardrails

Fraud rate cannot increase, privacy complaints cannot increase, issuer decline rate should not worsen for legitimate users, error rate must remain within launch threshold

25ML / Risk Decisioning FrameworkDIRECTIONAL · PENDING INTERNAL DATA

The ML question

Is this fraud?

The product question

What is the right amount of friction for this provisioning attempt?

Optimization target

Expected fraud cost + expected user friction cost + expected operational cost + expected trust / brand cost

Feature Category

Features

Device

Device tenure, device model, biometric enrollment state, Wallet history, Secure Enclave state, prior provisioning attempts.

Account

Apple ID age, account recovery events, number of trusted devices, password change recency, account activity patterns.

Issuer

Cardholder tenure with issuer, card status, prior fraud flags, issuer confidence score.

Behavioral

Provisioning velocity, typing vs. paste indicators, session behavior, location consistency.

Network

Token history, card velocity across network, issuer/network fraud intelligence feeds.

Model outputs

Fraud probability score
Composite trust score
Recommended provisioning path
Confidence interval
Reason codes for issuer interpretation: explainable, not a black box

Precision, recall, and friction tradeoff

High recall catches more fraud but routes more legitimate users to step-up. High precision reduces false positives but misses more fraud. The threshold is a product decision, not a technical one. It lives on the fraud-friction curve and should be set per card type, user segment, and issuer risk appetite.

Threshold strategy

Different thresholds applied across: premium cards vs. debit vs. prepaid · new users vs. established users · high-fraud geographies · issuers with different declared risk appetites.

Feedback loops

Model retrains on: fraud outcomes and chargebacks · user abandonment signals · issuer override decisions · support contact patterns · manual review outcomes.

26Launch Strategy

Start Narrow. Prove. Then Expand.

Phase

Simulation

Pilot

Readout

Expansion

Platform

Scale

Phase 1

Offline simulation

Replay historical provisioning attempts and estimate whether TrustPath would have reduced friction without increasing fraud.

Phase 2

Hypothesis

Structured next-best-action fallback reduces abandonment vs. current generic error state.

Primary metrics

Recovery completion rate, abandonment rate.

Guardrails

Support contact rate cannot increase.

28Cross Functional Execution

Team Alignment Required

Engineering

Trust scoring, path routing, telemetry, issuer/TSP integration.

Human Interface

Verification flows, fallback states, privacy copy, accessibility, error handling.

Legal and Privacy

Consent, data minimization, identity-sharing boundaries, retention, regional compliance.

Business Development

Select pilot issuers, align network partners, communicate partner value.

Analytics

Design experiments, dashboards, causal measurement, fraud monitoring.

Operations

Support teams, fraud escalation, incident response, launch readiness.

Marketing / Comms

Issuer-facing and user-facing language where needed.

Data needed

Provisioning funnel, path distribution, step-up completion by method, fraud-by-path, Wallet ID eligibility.

Phase Five

Learning

What might be wrong. What to validate. What to do next.

29What Might Be Wrong

Known Assumptions to Validate

This proposal may overestimate

Wallet ID adoption rate
Issuer willingness to change risk models
Quality of available trust signals
Legal feasibility of identity verification
User comfort with identity verification

This proposal may underestimate

Integration complexity
Regional regulatory requirements
Fraud adaptation to new signals
Operational change management burden

Without validation data, the project remains a hypothesis. With it, the team can identify exactly where TrustPath creates leverage.

30What I Would Do Next

If This Were a Real Apple Project

Validate current provisioning funnel metrics.
Identify top issuer pain points through partner conversations.
Run user research on verification friction.
Test concept comprehension with target users.

Replay historical decisions with a trust scoring model.
Select pilot issuer for controlled experiment.
Define privacy-preserving signal contract with Legal.
Launch controlled experiment with guardrail metrics.

Data required to begin

Provisioning attempts by issuer/region/device/card type, path distribution, step-up completion by method, time to provision by method, abandonment rate by step, fraud-after-provisioning by path, false-positive estimates, support contact rate, call-center volume, Wallet ID eligibility and adoption.

31The Vision

TrustPath is not a proposal to add more verification. It is a proposal to make verification smarter, rarer, and more proportional to risk.

Legitimate users

Add cards effortlessly, with friction proportional to their actual risk profile.

Issuers

Receive stronger confidence signals, with more control and less operational burden.

Fraudsters

Face harder barriers that cannot be bypassed by exploiting weak verification channels.

Apple

Strengthens Wallet as the most trusted digital payments and identity platform.