Excellent.

I will now answer these questions based on your updated instructions,

ensuring I explicitly name the frameworks used from the provided documents and
apply the CIRCLES framework to product design questions.

Question 1: Designing a New Sign-In Method

Affirm currently relies exclusively on phone number-based sign-in. This has created
challenges, particularly when users change their numbers. We are considering
introducing new authentication methods like email-based sign-in or SSO based
sign-in. Pick one of these methods and walk me through how you would develop it
as a new feature. How would you define goals, address risks, prioritize, and envision
the user experience?

This is a critical product design question that directly addresses a core business
challenge mentioned in my interview notes: the returning user funnel. I'll use the
CIRCLES Framework to structure my response.

Clarifying Questions:
●​ What is the primary business objective? Is it reducing customer support costs
from account lockouts, increasing conversion, or mitigating fraud?
●​ Do we have data on our users' preferences for SSO providers like Google
versus a standard email login?
●​ Are there any engineering constraints or preferences for third-party identity
vendors?

(C) Clarify the Goal

The core goal is to improve returning user retention by providing a stable, alternative
authentication path, thereby reducing friction and churn for users who change their
phone number.

(I) Identify Customers

The primary customers are returning Affirm users, especially those who have
changed their phone number. Secondary customers are new users who prefer
email/SSO for onboarding and all users who desire more choice in how they secure
their account.

(R) Report Needs

Users need a reliable way to access their account that isn't solely tied to a transient
piece of information like a phone number. They are frustrated by being locked out,
leading to a poor experience and high re-acquisition costs for us.

(C) Cut, Through Prioritization

Between email and SSO, I would prioritize email-based sign-in.
 ●​ Reasoning: Email is a more universal identifier than any single SSO provider.
It directly solves the core "changed number" problem by establishing a stable
second factor. It also serves as a necessary foundation upon which SSO can
be built later; you need a verified email in the system to link an SSO provider
to it reliably.

(L) List Solutions

We need to design the feature with security and user experience at the forefront.
●​ 1. Goals and Success Metrics:​

○​ North Star Metric: I'll use the VITAL Framework here. The North Star
should be Successful Returning User Authentication Rate. This is
value-focused, intelligible, trackable, and actionable.
○​
○​ Counter Metric: Account Takeover (ATO) Fraud Rate. We must not
sacrifice security.
○​ Supporting Metrics: Adoption rate of email sign-in; reduction in
account recovery support tickets.
●​ 2. Security & Fraud Risk Mitigation:​

○​ Risk: Account takeover via a compromised email account.

○​ Mitigation: Enforce multi-factor authentication (MFA) for high-risk
actions (e.g., changing a phone number). Use risk-based
authentication to trigger step-up challenges from new devices/IPs, a
project the team is already considering.
○​
●​ 3. User Experience (First-time and Returning):​

○​ First-Time User: After phone number verification and initial approval,

add an optional but encouraged step: "Secure your account with an
email for easy recovery."
○​ Returning User (Login): The sign-in page will have "Sign in with
Phone" and "Sign in with Email" options.
○​ Returning User (Recovery): A "Changed your phone number?" link
will initiate an email-based recovery flow, which requires re-verification
of identity (e.g., DOB, last 4 of SSN) before a new number can be
linked.

(E) Evaluate Options

The primary trade-off is between speed of development and security. An email-based
system requires building our own logic for password storage, resets, and security,
while SSO offloads some of that but adds integration complexity. Prioritizing email
first gives us more control over the user experience and security posture, which is
paramount for the Trust and Safety team.

(S) Summarize Your Recommendation

I recommend prioritizing the development of a secure, email-based sign-in feature.
This directly addresses the critical returning user problem. The North Star is to
improve the Successful Returning User Authentication Rate while closely
monitoring for fraud. This foundational feature will enhance user trust and pave the
way for future authentication methods like SSO.

Question 2: Leveraging Connected Accounts for Trust

From a 'Trust and Safety' perspective, design a new feature that leverages
connected accounts (Shopify, Amazon, etc.). How could this feature simultaneously
build user trust, streamline the user experience, and help us mitigate fraud? Present
your concept as if you were pitching it to the team for the first time.

This is an innovative product design question that aligns with the mentioned project
idea of using connected accounts. I'll use the CIRCLES framework to structure my
pitch.

"Team, I want to propose a new feature called 'Trusted Partner Verification.' The
concept is to leverage the trust a user has already built with our partners, like
Shopify, to create a safer and faster checkout experience with Affirm."

(C) Clarify the Goal

The primary goal is to decrease friction for verifiably low-risk users, thereby
increasing conversion, while simultaneously gaining new data signals to better detect
high-risk users.

(I) Identify Customers

The primary customers are Affirm users checking out on a partner merchant site
(e.g., Shopify) who have an established, trusted history with that partner.

(R) Report Needs

Our users need a faster, more seamless checkout experience. They are frustrated by
'additional checks' that create friction. From a business perspective, we need more
reliable, real-time signals to differentiate good users from fraudsters.

(C) Cut, Through Prioritization

For an MVP, I would prioritize launching this with a single, large-scale partner like
Shopify where the integration is deep and the user volume is high.
(L) List Solutions
The solution is an opt-in feature at checkout.
●​ User Flow:
1.​ At checkout, the user selects Affirm.
2.​ A new, optional checkbox appears: "Verify faster with your Shopify
account."
3.​ With consent, we use OAuth to receive trusted signals from Shopify.
Key signals would be: account tenure, verified payment method on
file, and whether the shipping and billing addresses match.
4.​ Dynamic Funnel:
■​ High Trust Signal (e.g., 2-year-old account, addresses match):
We route the user to a faster, token-based authentication path,
potentially skipping additional checks.
■​
■​ Low Trust Signal (e.g., new account, address mismatch): We
route the user to our standard, robust verification funnel.

(E) Evaluate Options

We are trading off engineering complexity for better risk assessment and user
experience.
●​ Strengths: Rewards good users, adds powerful fraud-detection signals, and
improves conversion.
●​ Challenges: Requires tight partner integration and careful handling of user
data consent. The risk model needs to be updated to ingest these new
signals.

(S) Summarize Your Recommendation

I recommend we build 'Trusted Partner Verification,' starting with Shopify. This
feature leverages partner data to create a win-win-win: a faster UX for trusted users,
powerful new signals for our risk models, and higher conversion for our merchants. It
directly supports our move towards a more flexible, risk-based authentication
system.

Question 3: Proactively Showing Loan Terms

We have a proposal to show users the terms of their potential loan (approval
amount, APR) before they complete the full authentication process. This is a
significant change to our current funnel. Design this new user flow from scratch.
What are the primary customer pain points this would solve? What are the biggest
risks, and how would you build a system to manage them?
This is a significant product design challenge that re-orders our entire funnel. I will
use the CIRCLES framework to design this new flow.

(C) Clarify the Goal

The goal is to increase user transparency and reduce late-stage funnel
abandonment by qualifying users on the loan terms earlier in the process.

(I) Identify Customers

The customers are all Affirm users, but particularly those who are sensitive to the
specific APR and loan amount they will be offered.

(R) Report Needs

The primary user need this solves is reducing uncertainty. Users currently invest
time and provide sensitive information (Name, DOB, Address) before they know if
the loan terms are even acceptable. This can lead to frustration and a feeling of "bait
and switch" if the final terms don't meet their expectations, causing them to abandon
at the 'Terms of Loan' step.

(C) Cut, Through Prioritization

The critical decision is when to show the terms. I would prioritize showing them
immediately after phone number verification, which allows for a soft credit check,
but before the user has to manually enter their full PII.

(L) List Solutions

Here is the design for the new flow and the system to manage its risks.
●​ New User Flow:​

○​ Enter: User selects Affirm and enters their phone number for SMS
verification.
○​ Pre-Approval & Terms: Based on the phone number and a soft credit
check, we immediately display a "pre-approval" screen: "You're
pre-approved for up to $1,200 with an estimated APR between
10-30%." This screen is clear that these are estimates.
○​ Engage: If the user finds these terms acceptable, they click "Continue"
and are taken to the full application form to enter their Name, DOB, and
Address for the final underwriting.
○​ Exit: The final, firm loan terms are presented for acceptance.
●​ Risk Management System: I'll use the Risk Management framework here.
○​ Risk 1 (Prevention): The "Bait and Switch" perception. If the final
terms are worse than the pre-approved ones, we destroy trust.
■​ Mitigation: The underwriting model must produce a "confidence
score." For low-confidence pre-approvals, we will not show
specific terms, but a message like: "Complete your application to
 see your personalized terms." We will also monitor the "Term
Discrepancy Rate" as a key health metric.
○​ Risk 2 (Monitoring): Application Fraud. Fraudsters could ping the
system to find favorable pre-approvals.
■​ Mitigation: Implement strict velocity checks on pre-approval
requests from a single IP or device. The initial phone check
must still trigger silent fraud scores.
○​ Risk 3 (Response): We must be prepared to tighten the confidence
score thresholds or add friction if we see these risks materializing.

(E) Evaluate Options

The main trade-off is improved user experience vs. potential model complexity and
fraud vectors. By building a robust risk management system with confidence scores
and velocity checks, we can capture the upside of transparency while mitigating the
downside.

(S) Summarize Your Recommendation

I recommend we redesign the funnel to show estimated loan terms after phone
verification but before full PII entry. This addresses the key pain point of uncertainty.
We will manage the risks by tying the feature to a model confidence score and
implementing strict fraud checks. This will lead to a more transparent and efficient
user experience.

Question 4: The Returning User Mobile Number Problem

(This is a problem-solving/execution question, so I will use the Root Cause
Analysis and VITAL Framework as I did previously.)

This is the most critical challenge for the Trust and Safety team. My approach would
be a methodical diagnosis before proposing solutions.

Clarifying Questions:
●​ Do we have access to the original documentation for the flow built by
Customer Service to understand its intended logic?
●​
●​ What specific data points are we collecting at the point of failure?
●​ Can we segment the 50% failure rate by user tenure, device, or original
onboarding channel?

Step 1: Investigation (Root Cause Analysis)

1.​ Comprehend the Situation: I would start by mapping the entire user journey
with the Customer Service and Engineering teams.
 2.​ Generate Hypotheses: My hypotheses would be: a) a technical bug or high
latency, b) a confusing UX with poor error messaging, or c) a fraud rule that is
too aggressive and is creating false positives.
3.​ Prioritize Investigation & Validate: I would use a combination of quantitative
and qualitative analysis to validate these hypotheses.
○​ Data Analysis: Create a funnel to see where in the flow the 50% of
users drop.
○​ Session Replays & User Interviews: Watch recordings and talk to
users who failed the flow to understand their frustration.
○​ Support Ticket Analysis: Analyze verbatim comments in support
tickets related to "changed phone number".
○​

Step 2: Define the North Star Goal (VITAL Framework)

●​ The North Star Metric should be the Successful Account Revalidation
Rate.
●​ It's VITAL because it's Value-focused (measures user success), Intelligible,
Trackable, Actionable, and Legitimate.
●​ Counter Metric: Account Takeover (ATO) rate on revalidated accounts. We
must not open new fraud vectors.
●​

Step 3: Identify Key Customer Pain Points

My investigation will likely confirm pain points like hitting a "dead end" with no clear
next step, confusion about what information is needed, and being forced into a
high-effort channel like a phone call.

Step 4: Propose and Prioritize Solutions

1.​ Quick Win (Low Effort, High Impact): Improve the UX of the existing flow
with clearer instructions and error messaging.
2.​ Core Project (High Effort, High Impact): Build an alternative recovery path
using a verified secondary identifier, namely email-based authentication.
3.​
4.​ Future Enhancement (Medium Effort, Medium Impact): Proactively prompt
users to add a recovery email before they have a problem.

Question 5: Investigating the Authentication Funnel

(This is a diagnostic question. I will use the Root Cause Analysis framework.)
A 15% month-over-month drop-off in returning users is a critical issue. Friction in the
authentication funnel directly impacts long-term retention; a bad login experience can
permanently break the user habit.

My Diagnostic Plan (Root Cause Analysis):

1.​ Comprehend the Situation:​

1.​ Validate the Metric: First, I'd confirm the metric's definition with our
data team.
2.​ Isolate the Change: I'd pinpoint the exact date the drop-off began to
correlate it with any product releases, feature regressions, or external
events.
2.​ Generate Hypotheses: The cause could be a technical issue (bug, latency),
a product/UX change (added friction), or external factors (competitor actions).​

3.​ Prioritize Investigation (First Five Metrics):​

1.​ Authentication Funnel Conversion Rate by Step: This will tell me

where the drop-off is occurring (e.g., Phone Entry, Authentication,
Fraud Check).
2.​
3.​ Drop-off Rate by User Segment: Segmenting by platform
(iOS/Android/Web), user tenure, and acquisition channel will help
isolate the cause.
4.​ API Latency and Error Rates: This will test the hypothesis of a
technical performance issue.
5.​ Customer Support Ticket Volume & Sentiment: A spike in tickets
mentioning "login" or "locked out" is a clear signal from the user.
6.​ Adoption/Failure Rate of Different Auth Paths: If we have multiple
login methods, I'd check the drop-off rate for each to see if the problem
is specific to one.

Question 6: Transitioning to Risk-Based Authentication

(This is a strategic question about evaluating a major initiative. I will use the Binary
Tradeoffs framework to structure my evaluation.)

Moving to a risk-based authentication (RBA) model is a strategic imperative for the

Trust and Safety team. The goal is to reduce fraud while improving the experience
for good users. I would structure the decision-making process to carefully evaluate
the trade-offs.

Framework: Binary Tradeoffs (Friction vs. Fraud)

1. Clarify the Goal:

The primary goal is to reduce fraud losses while maintaining or improving the
conversion rate for returning users. The secondary goal is to create a faster,
token-based process for trusted users.

2. Evaluate Pros and Cons (The Trade-off):

Aspect Pro (Benefits of RBA) Con (Risks of RBA)

User Pro: Low-risk users get a Con: High-risk (but potentially

Experience seamless, faster experience. legitimate) users face increased
friction.

Fraud Pro: Can dynamically target Con: A flawed model could block
Prevention new and evolving threats. good users or miss sophisticated
fraud.

Engineering Pro: Modern, flexible Con: High initial complexity to build

architecture. and maintain the risk models and
dynamic UI.

Business Pro: Potential for higher Con: Risk of customer dissatisfaction

Impact conversion and lower fraud from false positives or new fraud
losses. vectors.

3. Recommendation & Rationale:

I would recommend we proceed with the initiative. The long-term benefits of a

flexible, intelligent system far outweigh the risks, provided we mitigate them properly.

4. Additional Considerations (New Fraud Vectors & Mitigations):

●​ Vector: Model Probing (fraudsters trying to reverse-engineer our risk rules).
○​ Mitigation: Use an ensemble of models and introduce randomness to
make thresholds unpredictable.
●​ Vector: Exploiting Low-Friction Paths (attacking compromised "trusted"
accounts).
○​ Mitigation: The RBA model must be contextual. A trusted user
shipping to a new address should still trigger a step-up challenge.
 ●​ Vector: Attacking the Step-Up Challenge itself.
○​ Mitigation: Use dynamic, risk-based challenges (e.g., a simple DOB
check for medium-risk, a full IDV check for high-risk).

Question 7: Diagnosing and Fixing a 40% Drop-off

(This is a classic execution question. I will use the Bottlenecks framework.)

A 40% drop-off at the 'Additional checks if necessary' step is a critical bottleneck that
needs immediate attention.

Using the Bottlenecks Framework:

1. Find the Bottleneck & Analyze Data:

●​ The bottleneck is clearly identified. My next step is to quantify performance
and identify pain points.
●​ Quantitative: What is the average time spent on this step? Which specific
question within the step causes the most abandonment?
●​ Qualitative: I would watch session replays and analyze support tickets to
understand the user's frustration.

2. Identify User Pain Points (Hypotheses):

●​ Effort Hypothesis: The task (e.g., uploading a document) is too difficult.
●​ Trust Hypothesis: The user is asked for sensitive data without a clear
explanation of why.
●​ Vagueness Hypothesis: The instructions are unclear.

3. Fix Options:
●​ Process Solution: Replace a high-friction task (document upload) with a
lower-friction one (e.g., knowledge-based questions or a Plaid integration).
●​ UX Solution: Improve the UI with clearer copy, reassuring messaging ("To
protect your identity..."), and explicit examples of what is needed.

4. Recommend a Solution:

I would recommend an A/B test.

●​ Variant: A redesigned flow that combines a Process Solution (a simpler ask)

with a UX Solution (clearer, more reassuring copy).
●​ Success Metrics: A primary metric of a reduction in the 40% abandonment
rate, with a counter metric of no increase in fraud for users passing through
the new, simplified flow.
Question 8: Handling a Pre-Launch Conflict
(This scenario requires a structured approach to risk. I will use the Risk
Management framework from the Launch section of the provided document.)

This conflict between a new feature and existing systems is a classic pre-launch
challenge. My goal is to mitigate the risk without killing a valuable feature.

Using the Risk Management Framework:

1. Prevention (Triage and Understand):

●​ My first step is to get specific. I would meet with the Fraud and Auth
engineering teams to understand the exact conflict. What rules are being
triggered? Is it ATO or synthetic fraud? What is the potential impact?

2. Monitoring (Develop a Phased Rollout Plan):

●​ Instead of delaying the launch entirely, I would propose a phased rollout
using feature flags, as described in the Launch Strategy framework.
○​ Phase 1: Internal dogfooding.
○​ Phase 2: Launch to 1% of users.
○​ Phase 3: Gradually ramp up to 100%, while the fraud team monitors
the new signals and adjusts their models in real-time.
●​ We would establish a clear "kill switch" criterion (e.g., if fraud losses exceed
X bps) to immediately roll back the feature if necessary.

3. Response (The Iteration Plan):

●​ The data from the phased rollout will allow us to respond intelligently. The
fraud team can use the live data to fine-tune their models. My product team
can iterate on the UX to add targeted friction where needed (e.g., adding a
step-up challenge for new email-based accounts that appear risky).

This structured approach allows us to launch on time, start delivering user value, and
manage risk in a controlled, data-driven way.

Question 9: Designing the Address Matching Feature

(This is a product design question, so I will use the CIRCLES framework.)

This feature is a great example of leveraging partner data to reduce friction, an idea
mentioned in the interview notes.

(C) Clarify the Goal

The goal is to increase conversion and reduce friction for low-risk users by using
data they have already provided to our partners.

(I) Identify Customers

The customers are Affirm users checking out on a partner site (like Shopify) where
their billing and shipping addresses are the same.

(R) Report Needs

Users need a faster, easier checkout process. They don't want to enter the same
information multiple times. The business needs more positive signals to accelerate
trusted users through the funnel.

(C) Cut, Through Prioritization

The MVP would be to launch this with a single partner, like Shopify, where we have
a strong technical integration. The feature would only apply when billing_address ==
shipping_address.

(L) List Solutions

●​ The User Experience: The experience should feel seamless and automatic.​

1.​ User selects Affirm at checkout.

2.​ An optional, pre-checked box says: "Use my address from Shopify for a
faster checkout."
3.​ In the background, if the addresses match, we auto-fill the address
fields on our form and use this match as a strong positive signal in our
risk model.
4.​ If the addresses don't match, the flow gracefully reverts to our standard
manual entry form.
●​ Risk Mitigation: Address matching can be tricky ("St" vs. "Street"). We must
use a robust address normalization service before comparing. A mismatch
should not be a negative signal, simply the absence of a positive one.​

(E) Evaluate Options

The trade-off is the engineering effort to build the partner integration and address
normalization logic versus the expected lift in conversion. The benefit of improved
user experience and a stronger partner story is significant.

(S) Summarize Your Recommendation

I recommend building the Address Matching feature as an MVP with Shopify. It's a
low-friction, high-value feature that leverages our partner ecosystem, improves the
user experience, and provides a valuable signal to our risk engine.
Question 10: Designing a Passkeys/FIDO2 Roadmap
(This is a strategic vision and roadmap question. I will use the 3W Vision
Framework to set the stage, followed by a Three Year Roadmap structure.)

Passkeys are the future of authentication. Championing this would position Affirm as
a leader in security and user experience.

The Vision (3W Framework):

●​ What problem are we solving? We are solving for a future where users no
longer need to rely on insecure (passwords) or high-friction (SMS)
authentication methods.
●​ Why does it matter? It matters because it offers a fundamentally more
secure and seamless user experience, which will increase trust, conversion,
and retention.
●​ Where are we heading? We are heading towards a "passwordless Affirm,"
where our most trusted users can authenticate with a biometric scan.

The Three-Phase Roadmap:

Phase 1: Foundation (0-6 months)

●​ Goal: Build the core capability.
●​ Features: Allow users to register a passkey in their account settings and use
it to re-authenticate to their main Affirm account.
●​ Metrics: Number of passkeys registered.

Phase 2: Checkout & Recovery (6-12 months)

●​ Goal: Solve our biggest pain point: returning user friction at checkout.
●​ Features: Enable passkey as an authentication method at merchant
checkout. Explore using passkey as a secure account recovery method.
●​ Metrics: Conversion Rate of Returning Users (A/B test passkey vs. standard
flow).

Phase 3: Onboarding & Strategic Advantage (12-18 months)

●​ Goal: Use passkeys as a competitive differentiator.
●​ Features: "Sign up with a Passkey" to allow new users to create an account
and a passkey in a single step.
●​ Metrics: Conversion rate of new users; percentage of MAUs using passkeys.

Question 11: Prioritizing a Backlog

(This is a prioritization question. I will use a standard Impact vs. Effort
Prioritization Framework, which is a core PM skill emphasized in the interview
guide.)

My prioritization is based on our primary goal: solving the returning user retention
problem first, then reducing friction.

Feature Business Engineering Rationale Priority

Impact Effort (H/M/L)
(H/M/L)

(a) Email High Medium Solves our #1 challenge: P1

Login the returning user who
changes their phone
number. It's a
foundational fix.

(d) Medium Low-Medium A significant friction P2

Address-mat reducer at checkout.
ching High value for a large
auto-approv segment of users.
e

(c) Faster Medium Low-Medium Excellent friction reducer P3

device-token for loyal, same-device
auth users. Slightly narrower
impact than address
matching.

(b) Google Low-Mediu Low A "nice to have" P4

OAuth m convenience feature that
should be built after the
foundational email
system is in place.

Sequencing:
1.​ P1: Email Login is the foundation. It fixes the biggest leak.
2.​ P2: Address-matching is the next biggest win to improve checkout
conversion.
 3.​ P3: Device-token auth is another friction reducer that can be worked on in
parallel or after address-matching.
4.​ P4: Google OAuth builds on the email foundation, making it a logical final
step.

Question 12: Investigating a 3% Drop at 'Terms of Loan'

(This is a diagnostic question. I will use the Root Cause Analysis framework.)

A 3% drop at the final decision step is alarming. I would act with urgency.

Investigative Sequence (Root Cause Analysis):

1.​ Comprehend the Situation: Validate the metric and pinpoint the exact date
the drop started to correlate with any releases.
2.​ Generate Hypotheses: My top hypotheses are a) a feature regression in the
UI, b) a change in the offered loan terms from the Credit model, or c) a new
bug.
3.​ Prioritize Investigation:
○​ Data Dive: Segment the drop by merchant, loan terms (APR/amount),
and platform (iOS/Android/Web).
○​ Qualitative Review: Watch session replays of users who abandon and
personally review the UI for any recent changes.

First Two Fixes to Test:

1.​ The "Clarity & Reassurance" Test:
○​ Hypothesis: A recent UI change made the terms feel confusing.
○​ Fix: A/B test a revised screen with a simpler summary at the top ("Your
loan: $550 at 15% APR") and a clearer call-to-action button.
2.​ The "Contextual Help" Test:
○​ Hypothesis: Users have a specific question (e.g., "What is APR?")
and abandon because they can't find an answer.
○​ Fix: A/B test adding small, clickable tooltips next to key terms that
provide plain-language explanations.

Question 13: Handling a Fraud Spike

(This is an incident response question that tests senior experience. There is no
specific framework in the doc, so I will outline a standard, structured incident
command process.)
This requires a rapid, structured response. My priorities are: 1) Stop the bleeding, 2)
Diagnose, 3) Communicate.

Who I Call First (The First 5 Minutes):

I would create a virtual war room with the Lead Engineer for Fraud Prevention, the
Head of Trust & Safety, the merchant's Account Manager, and the Data Science
Lead for Fraud Modeling.

What Dashboards I Open (The First 15 Minutes):

I would filter my standard fraud dashboards for this specific merchant:

1.​ Real-Time Transaction Monitoring: To see if the attack is ongoing.

2.​ Fraud Signals Dashboard: To find the "fingerprint" of the attack by looking
for commonalities in SKU, IP address, device ID, and shipping address.
3.​ Merchant Configuration Dashboard: To see if the merchant recently
changed their integration.

The Action Plan (The First Hour):

1.​ Containment: The first move is to write an emergency rule to block the
specific fraud fingerprint we've identified.
2.​ Communication: I would work with the account manager to inform the
merchant: "We've detected unusual activity and have implemented a targeted
measure to protect your account. Our team is investigating."
3.​ Escalation: If we cannot isolate the pattern and losses are mounting, I would
recommend temporarily pausing Affirm on that merchant's site as a last
resort.

Question 14: Collaborating with the Credit Team

(This is a cross-functional problem. There is no specific framework, so I will outline a
partnership-based approach.)

A high false-positive rate for returning users means we are declining good
customers. This is a shared problem between Trust & Safety and the Credit team.

My 4-Step Partnership Plan:

1.​ Frame with a Shared Goal: I would approach the Credit PM with a shared
opportunity: "I think there's a chance for us to work together to safely approve
more returning users, which would increase revenue and improve retention.
Can we partner on this?"
2.​ Create a Joint "Tiger Team": I'd propose a small, virtual team with PMs,
data scientists, and engineers from both Trust & Safety and Credit.
 3.​ Conduct Joint Debugging: The team's first job is to analyze the data
together. The Credit team brings why the model declined a user; the Trust &
Safety team brings that user's positive Affirm history. We'd look for cases
where strong Affirm history should outweigh a negative signal from a
traditional credit bureau.
4.​ Propose and Test Model Adjustments: We would hypothesize that the
model is underweighting Affirm's proprietary data. We would test a new
version of the model that gives higher weight to these features for returning
users, launching it as an A/B test with the goal of increasing approvals without
increasing defaults.

Question 15: Re-planning After a Slip

(This is a strategic execution question. There is no specific framework, so I will
outline a standard PM response to a delay.)

A three-week slip on the RBA rollout is a challenge, but my job is to manage the plan
to protect our North Star: retention.

My Re-planning Process:
1.​ Understand the "Why": I would first meet with the engineering lead to
understand the root cause of the delay to ensure the new timeline is realistic.
2.​ Triage the Impact and Protect the North Star: I accept that the full impact of
RBA will be delayed. My focus shifts to: "What is the next best thing we can
do to protect our retention goal now?"
3.​ Identify "Quick Win" Projects: I would review our backlog for smaller
initiatives that drive retention and can be executed in the three-week window.
This could be the "Clarity Fix" for the 'Terms of Loan' step or a fix for the
'Additional Checks' bottleneck.
4.​ Communicate and Re-Set Expectations: I would immediately update
leadership and stakeholders, presenting not just the problem (the slip) but
also the solution (the revised plan to pull forward a smaller project). I would
formally update our quarterly roadmap to reflect this new reality.

Question 16: The A/B Test Decision

(This is a classic trade-off problem. I will use the Binary Tradeoffs framework to
structure my decision.)

This A/B test result (+2 bps retention, +5 bps fraud loss) presents a direct trade-off
between a business goal and a critical risk metric.

Framework: Binary Tradeoffs (Retention vs. Fraud)

1. Clarify the Goal: The goal of the email login feature is to improve retention
without materially harming our risk profile.

2. Evaluate Pros and Cons:

●​ Pro: The 2 bps retention lift is a powerful signal that we are solving a real user
need. Killing the feature would mean abandoning this user value.
●​ Con: The 5 bps fraud lift is a direct, immediate cost. Shipping it would be
irresponsible and set a dangerous precedent.

3. Recommendation: ITERATE.
●​ Why not SHIP? Shipping a feature that knowingly increases fraud is not
acceptable for a Trust & Safety team.
●​ Why not KILL? The retention lift proves we are on the right track. We cannot
abandon our users.

4. Additional Considerations (The Iteration Plan):

My recommendation is to iterate to capture the upside while eliminating the

downside.

●​ Hypothesis: The current flow is too permissive.

●​ Action: I would work with the fraud team to analyze the type of fraud. We
would then design a new test variant that adds targeted friction. For example,
if the fraud is ATO, we add a stronger step-up challenge when a user adds an
email to an existing account.
●​ New Test: We would run an A/B/C test (Control vs. Original Variant vs. New
Iterated Variant) with the goal of finding a version that keeps the retention lift
while neutralizing the fraud lift.

Question 17: Taking Ownership of a Flow

(This is a change management question. There is no specific framework, so I will
outline a structured, partnership-based approach.)

Transitioning ownership of a codebase requires a delicate, people-first approach to

maintain velocity and morale.

My 3-Phase Change-Management Plan:

Phase 1: Align and Learn (Weeks 1-2)

●​ The Kick-off: I'd meet with the Customer Service (CS) product and
engineering leads, framing the transition as an evolution, not a rejection. My
message: "We want to build on the great work you've done."
 ●​ Knowledge Transfer: We'd ask them to walk us through the architecture,
codebase, and their future ideas for the flow. This shows respect for their
expertise.

Phase 2: The Transition Plan (Weeks 3-4)

●​ Define Clear Ownership: We would create a document outlining the new
roles. T&S Engineering owns the code; T&S Product (me) owns the roadmap;
the CS team becomes a key stakeholder.
●​ Phased Handover: We'd take ownership in stages: first monitoring, then bug
fixes, and finally new feature development over a period of 1-2 months. The
CS team would move from primary on-call to consultant.

Phase 3: Maintain Velocity and Demonstrate Value (Ongoing)

●​ Deliver a Quick Win: My first priority after the handover would be to ship a
small improvement that the CS team had previously wanted. This builds
immediate trust and proves we are good stewards.
●​ Establish a Shared Rhythm: I would set up a bi-weekly sync with the CS PM
to share our roadmap and get their feedback, ensuring they remain a valued
partner.

Of course. This is the most critical problem described in the interview notes,
and addressing it comprehensively is key to improving the returning user
funnel.

First, a clarifying question: Is the primary goal to find the single best solution,
or is it to design a resilient, multi-layered system where different solutions can
be applied based on the user's context and risk profile? Assuming the goal is
to design a robust system, I will proceed.

To structure my answer, I will use the CIRCLES Framework, as this is

fundamentally a product design challenge—we are designing a new "account
recovery" product. I will incorporate competitive research into the "List
Solutions" stage to inform our options.

(C) - Clarify the Goal

The business goal is to fix the 50% failure rate in the account revalidation
process for users who change their mobile number. This will significantly
reduce the high costs associated with re-acquiring these valuable returning
users and lower the burden on the Customer Service team. The user-centered
goal is to eliminate the anxiety and frustration of being locked out, providing a
secure and reliable path back to their account. We must achieve this without
weakening our fraud controls.
(I) - Identify Customers
The primary user is the legitimate returning Affirm user who has lost access to
their registered phone number due to changing carriers, moving, or losing
their device. These are valuable, already-acquired users we are at high risk of
losing.

(R) - Report Needs

Users need a predictable, self-serve, and secure "lifeline" to regain access to
their accounts. When their primary authenticator (phone number) fails, they hit
a dead end, causing immense frustration. Our current flow fails half the time,
indicating that their need for a reliable alternative is not being met.

(C) - Cut, Through Prioritization

Before listing individual solutions, the strategic priority must be to establish a
stable, primary identifier for each account that is independent of the phone
number. My competitive research shows that rivals like Klarna, Afterpay, and
PayPal have already solved this.
●​ Competitive Insight: Klarna, Afterpay, and PayPal all use the user's
email address as the foundational anchor for account identity and
recovery. They send password reset links, one-time login codes, and
account notifications to the user's verified email.

Therefore, the highest-priority "cut" is the decision to make a verified email

address a mandatory part of the Affirm user profile, which then serves as the
foundation for most of the following recovery solutions.

(L) - List Solutions

Here are all the ways we could fix the account revalidation issue, categorized
into a tiered system. This approach is informed by both the projects
mentioned in my notes and competitive best practices.

Pillar 1: Foundational Recovery Paths (Low Friction)

These are the primary, self-serve methods that should solve the problem for
the majority of users.
1.​ Email-Based Sign-In & Recovery: This is the top priority, already
identified as a potential project.
○​ How it Works: A user who can't use their phone number clicks a
"Try another way" link. They enter their email address. We send a
secure, one-time login link or a password reset link to their
verified email on file.
○​ Competitive Insight: This is the standard recovery method for
Klarna and Afterpay.
 2.​ Single Sign-On (SSO): Leverage established digital identities. This is
also a project mentioned in the notes.
○​ How it Works: Users who have previously linked their Google,
Apple, or other accounts can use that identity to sign in,
completely bypassing the phone number.
○​
○​ Competitive Insight: PayPal has a robust "Log in with PayPal"
ecosystem that functions similarly, demonstrating the power of a
federated identity.
3.​ Device-Based Authentication: Use the user's trusted device as an
authentication factor.​

○​ How it Works: If a user has previously logged in from a specific

device (phone or laptop), we can use a secure token stored on
that device to grant access or to authorize the change of their
phone number. This is often invisible to the user and very
low-friction.
○​

Pillar 2: Step-Up Verification Paths (Medium Friction)

If a user cannot use a foundational path (e.g., they also lost access to their
email), we apply targeted friction to verify their identity.
4.​ Knowledge-Based Verification: Leverage the unique data we collected
during underwriting.
○​ How it Works: After entering their email, we can ask the user to
confirm 2-3 pieces of personal information that a fraudster is
unlikely to have, such as their Date of Birth, Last Name, or the
last four digits of their Social Security Number.
○​
5.​ Connected Account Verification: Use linked financial or merchant
accounts as a proof of identity.
○​ How it Works: We could present a flow that says, "To verify it's
you, securely log in to the bank account you've used to repay
Affirm" or "Confirm a recent purchase you made at a connected
Shopify store." This uses a unique Affirm data asset.

Pillar 3: Manual & High-Friction Paths (Last Resort)

This is the safety net for the most complex cases, ensuring no legitimate user
is ever permanently lost.
 6.​ ID Document Verification: Escalate to a formal identity check.​

○​ How it Works: The user is prompted to use their phone camera to

scan their driver's license or passport via an integrated third-party
service (e.g., Veriff, Jumio).
○​ Competitive Insight: PayPal uses a similar document upload
system in their Resolution Center for high-stakes account
recovery.
7.​ Live Agent Verification: A final, human-in-the-loop solution.​

○​ How it Works: The user schedules a brief video call with a trained
Affirm customer support agent who visually verifies their identity
against their ID and asks a series of security questions.

(E) - Evaluate Options

The core trade-off is always Security vs. User Experience vs. Operational Cost.
●​ Email/SSO/Device Auth are the best options, offering high security and a
great user experience at a low operational cost.
●​ Knowledge-Based Verification is also excellent, as it uses existing data
assets.
●​ ID Document Scan and Live Agent Verification are highly secure but add
significant user friction and operational cost. They should be reserved
for the highest-risk or most complex edge cases.

(S) - Summarize Your Recommendation

My recommendation is not to pick one solution, but to build a risk-based,
multi-layered recovery system.
1.​ Immediate Priority: Implement Email-Based Recovery as the
foundational layer. This aligns with competitive best practices, solves
the core problem for the majority of users, and is already a known
project idea.
2.​
3.​ Fast Follow: Launch SSO and Device-Based Authentication. These
features will provide extremely low-friction recovery paths for our most
engaged users.
4.​ Build Out: Layer in Knowledge-Based and Connected Account
Verification as intelligent step-up challenges.
5.​ Safety Net: Finally, integrate ID Document Verification as the ultimate
escape hatch, ensuring we can recover every legitimate user without
sacrificing our fraud controls.
 Account Revalidation Solutions
Framework - Affirm Trust & Safety
Framework Applied: CIRCLES + Competitive
Analysis + Strategy

C - CLARIFY THE PROBLEM & BOUNDARIES

Current State Analysis

●​ Problem: 50% failure rate when users change phone numbers

●​ Business Impact: High acquisition costs make losing returning users
extremely expensive
●​ User Pain: Locked out of existing accounts, forced to create new accounts
●​ Fraud Risk: Balance between user convenience and account security

Key Constraints

●​ Must maintain fraud detection effectiveness

●​ Cannot compromise Trust & Safety standards
●​ Must work across mobile and web platforms
●​ Should integrate with existing authentication infrastructure

I - IDENTIFY COMPETITIVE LANDSCAPE

Competitive Research Analysis

Klarna

Authentication Methods:

●​ Email + SMS verification

●​ Social login (Google, Apple, Facebook)
●​ Biometric authentication (Touch/Face ID)
●​ "Magic links" via email
●​ Account recovery through purchase history verification

Key Insights:

●​ Emphasizes frictionless social login

 ●​ Uses purchase history as identity verification
●​ Strong mobile-first biometric integration

Afterpay

Authentication Methods:

●​ Email-based login with SMS backup

●​ Social login (Google, Apple)
●​ Security questions based on purchase history
●​ Customer service escalation with ID verification
●​ Device registration and recognition

Key Insights:

●​ Multi-layered backup options

●​ Heavy reliance on device recognition
●​ Customer service as final fallback

PayPal Pay in 4

Authentication Methods:

●​ Leverages existing PayPal account ecosystem

●​ Email + password with 2FA options
●​ Device authorization and management
●​ Backup authentication codes
●​ Account recovery through linked bank accounts

Key Insights:

●​ Benefits from mature PayPal identity ecosystem

●​ Strong device management capabilities
●​ Multiple financial institution verification paths

Apple Pay Later

Authentication Methods:

●​ Apple ID integration (biometric + password)

●​ Device-based authentication
●​ iCloud Keychain integration
●​ Customer service with identity verification

Key Insights:

●​ Seamless ecosystem integration

●​ Device-centric security model
●​ Minimal user friction through ecosystem trust
 Sezzle

Authentication Methods:

●​ Email + SMS dual verification

●​ Social login options
●​ Account recovery through linked payment methods
●​ Purchase pattern verification
●​ Manual customer service review

Key Insights:

●​ Balanced approach between automation and human review

●​ Uses spending patterns as identity signals
●​ Multiple verification layers

R - REPORT COMPREHENSIVE SOLUTION

OPTIONS
Primary Authentication Alternatives

1. Email-Based Authentication

Implementation:

●​ Email + password login option

●​ Magic link authentication (passwordless)
●​ Email-based 2FA with backup codes

Fraud Controls:

●​ Email reputation scoring

●​ Device fingerprinting correlation
●​ Behavioral pattern matching

Pros: Universal access, familiar UX, existing infrastructure Cons: Email compromise
risk, deliverability issues

2. Social Sign-On (SSO)

Options:

●​ Google OAuth 2.0

●​ Apple Sign-In
●​ Facebook Login
●​ Microsoft Account
Implementation Strategy:

●​ Progressive rollout starting with Google/Apple

●​ Account linking during initial signup
●​ Fallback verification for new social accounts

Fraud Controls:

●​ Social account age and verification status

●​ Cross-platform identity validation
●​ Risk scoring based on social signals

Pros: High user adoption, reduced password fatigue, strong identity verification
Cons: Platform dependency, privacy concerns, integration complexity

3. Biometric Authentication

Technologies:

●​ Touch ID / Face ID integration

●​ Android Fingerprint / Face Unlock
●​ Windows Hello support
●​ Voice recognition (future)

Implementation:

●​ Device enrollment during first successful auth

●​ Biometric + device pairing for security
●​ Fallback to other methods if biometric fails

Fraud Controls:

●​ Device binding and registration

●​ Biometric template security
●​ Anti-spoofing measures

Pros: Excellent UX, high security, growing adoption Cons: Device dependency,
accessibility concerns

Account Recovery & Backup Methods

4. Knowledge-Based Authentication (KBA)

Based on Affirm Transaction History:

●​ "What was your last purchase amount?"

●​ "Which merchant did you use Affirm with most recently?"
●​ "What's your current loan balance?"
 ●​ "When did you make your last payment?"

Implementation:

●​ Dynamic questions based on recent activity

●​ Multiple choice to prevent brute force
●​ Time-limited attempts

Fraud Controls:

●​ Questions only account holder would know

●​ Cross-reference with recent transaction patterns
●​ Escalate suspicious patterns

5. Financial Institution Verification

Methods:

●​ Bank account micro-deposits

●​ Credit/debit card verification
●​ Plaid integration for account linking
●​ Payment history validation

Implementation:

●​ Link financial accounts during onboarding

●​ Use for account recovery when phone unavailable
●​ Real-time balance verification

Fraud Controls:

●​ Account ownership verification

●​ Historical payment correlation
●​ Velocity limits on financial verification

6. Document-Based Identity Verification

Options:

●​ Driver's license verification

●​ Passport scanning
●​ Utility bill verification
●​ Social Security Number validation

Implementation:

●​ OCR + human review process

●​ Integration with identity verification providers (Jumio, Onfido)
●​ Used for high-value account recovery

Fraud Controls:
 ●​ Document authenticity verification
●​ Biometric photo matching
●​ Address correlation with known data

Advanced Authentication Methods

7. Device-Based Authentication

Technologies:

●​ Device fingerprinting
●​ Hardware security keys (FIDO2/WebAuthn)
●​ Mobile device attestation
●​ Browser certificate management

Implementation:

●​ Register trusted devices during successful auth

●​ Device-specific tokens for returning users
●​ Hardware key enrollment for high-security users

Fraud Controls:

●​ Device reputation scoring

●​ Geolocation consistency
●​ Hardware attestation validation

8. Behavioral Biometrics

Signals:

●​ Typing patterns and rhythm

●​ Mouse movement patterns
●​ Touch pressure and swipe patterns
●​ Navigation behavior

Implementation:

●​ Passive collection during normal usage

●​ ML models for user behavior recognition
●​ Continuous authentication during sessions

Fraud Controls:

●​ Behavioral anomaly detection

●​ Session risk scoring
●​ Real-time fraud prevention
 9. Risk-Based Adaptive Authentication

Logic Framework:

●​ Low risk: Single factor (email link, biometric)

●​ Medium risk: Two factors (email + SMS backup)
●​ High risk: Multiple factors + manual review

Risk Factors:

●​ User history and tenure

●​ Transaction patterns
●​ Device and location consistency
●​ Time since last successful auth

C - CUT THROUGH PRIORITIZATION

Solution Prioritization Matrix
Solution Use Fr E Ti P
r au ng me r
Imp d Ef lin i
act Ri fo e o
sk rt r
i
t
y

Email Hig Me M 6-8 P

Authentication h diu ed we 0
m iu eks
m

Google/Apple SSO Hig Lo M 8-1 P

h w ed 0 0
iu we
m eks

Transaction Me Lo Lo 3-4 P
History KBA diu w w we 1
m eks

Device Me Lo M 6-8 P
Registration diu w ed we 1
m iu eks
m
 Biometric Auth Me Lo Hi 12- P
diu w gh 16 2
m we
eks

Financial Me Me Hi 10- P
Institution diu diu gh 12 2
Verification m m we
eks

Document Lo Lo M 8-1 P
Verification w w ed 0 3
iu we
m eks

Behavioral Lo Lo Hi 16- P
Biometrics w w gh 20 3
we
eks

L - LIST IMPLEMENTATION STRATEGY

Phase 1: Foundation (Months 1-3)

Quick Wins:

1.​ Email Authentication - Address immediate 50% failure rate

2.​ Transaction History KBA - Leverage existing data
3.​ Enhanced Customer Service Tools - Manual fallback improvements

Success Metrics:

●​ Reduce revalidation failure from 50% to 25%

●​ Maintain fraud rate within 5% of baseline

Phase 2: Expansion (Months 4-6)

Scale Solutions:

1.​ Google/Apple SSO - Major UX improvement

2.​ Device Registration - Trusted device management
3.​ Financial Institution Verification - High-confidence fallback

Success Metrics:

●​ Achieve 90%+ successful revalidation rate

●​ User satisfaction score >4.5/5 for auth experience
 Phase 3: Advanced (Months 7-12)

Sophisticated Methods:

1.​ Biometric Authentication - Premium user experience

2.​ Risk-Based Adaptive Auth - Intelligent friction management
3.​ Behavioral Biometrics - Continuous verification

Success Metrics:

●​ Best-in-class authentication success rate (95%+)

●​ Fraud rate improvement through better signals

E - EVALUATE COMPETITIVE POSITIONING

Competitive Advantage Strategy

Unique Differentiators vs Competitors:

1. Purchase History Intelligence

●​ Leverage detailed transaction history (unlike general payment platforms)

●​ Merchant-specific verification questions
●​ Loan performance history as trust signal

2. Merchant Partnership Integration

●​ Pre-auth verification through merchant checkout

●​ Shipping/billing address matching
●​ Real-time merchant fraud signals

3. Financial Behavior Patterns

●​ Payment timing and consistency patterns

●​ Credit utilization insights
●​ Cross-merchant spending behavior

Competitive Gaps to Address:

●​ Klarna's Social Integration: Implement comprehensive social login

●​ PayPal's Ecosystem: Build device management capabilities
●​ Apple's Seamless UX: Invest in biometric authentication

S - SUMMARIZE RECOMMENDATIONS
 Recommended Multi-Layered Approach

Immediate Implementation (0-3 months):

1.​ Email Magic Links - Passwordless email authentication

2.​ Purchase History KBA - "What was your last Affirm purchase?"
3.​ Enhanced CS Escalation - Streamlined manual verification

Medium-term (3-6 months):

4.​ Google/Apple SSO - Major platforms first

5.​ Device Registration - Trusted device management
6.​ Bank Account Verification - Plaid integration for high-confidence

Long-term (6-12 months):

7.​ Biometric Authentication - Touch/Face ID integration

8.​ Risk-Based Adaptive - Intelligent friction based on user risk
9.​ Behavioral Biometrics - Continuous passive authentication

Success Framework

North Star Metric:

●​ Account Revalidation Success Rate - from 50% to 95%

Supporting Metrics:

●​ Time to successful revalidation

●​ User satisfaction with auth experience
●​ Customer service escalation rate
●​ Auth-related user acquisition cost

Counter Metrics:

●​ Fraud rate maintenance

●​ False positive rate
●​ Technical performance impact

Implementation Principles

1.​ Layered Security: Multiple options prevent single points of failure

2.​ Progressive Enhancement: Start simple, add sophistication over time
3.​ User Choice: Let users select their preferred auth method
4.​ Fraud Balance: Never compromise security for convenience
5.​ Competitive Differentiation: Leverage Affirm's unique data advantages

Business Impact Projection

Year 1 Results:

●​ 45% reduction in lost returning users

●​ $2M+ revenue retention from improved revalidation
●​ 40% reduction in customer service auth tickets
●​ Competitive positioning improvement in user experience

This comprehensive approach addresses the core problem while building long-term
competitive advantages through Affirm's unique position in the BNPL ecosystem.

I'll analyze comprehensive solutions for Affirm's account revalidation issue using a
structured framework approach and competitive insights.

I've provided a comprehensive framework-based analysis of solutions for Affirm's

account revalidation issue. Here are the key insights:

Top Competitive Learnings:

1.​ Klarna leads in social integration - seamless Google/Apple login with purchase
history verification
2.​ PayPal Pay in 4 benefits from ecosystem maturity - device management and
financial institution links
3.​ Afterpay uses multi-layered fallbacks - device recognition + customer service
escalation
4.​ Apple Pay Later shows ecosystem power - minimal friction through platform
integration

Recommended Solution Hierarchy:

Immediate (P0) - Address 50% failure rate:

●​ Email magic links (passwordless)

●​ Transaction history verification ("What was your last purchase?")
●​ Enhanced customer service tools

Short-term (P1) - Scale to 90% success:

●​ Google/Apple SSO integration

●​ Trusted device registration
●​ Bank account verification via Plaid

Long-term (P2) - Best-in-class experience:

●​ Biometric authentication
●​ Risk-based adaptive authentication
●​ Behavioral biometrics
 Affirm's Unique Advantages:
Unlike competitors, Affirm can leverage:

●​ Detailed purchase history for verification questions

●​ Merchant partnership data for cross-validation
●​ Loan performance patterns as trust signals
●​ Multi-merchant behavior for identity confidence

Key Framework Applications:

●​ CIRCLES for systematic problem breakdown
●​ Competitive Analysis for market positioning
●​ Prioritization Matrix for resource allocation
●​ Strategy Framework for long-term planning

The solution balances user experience improvements with Trust & Safety
requirements while building competitive differentiation through Affirm's unique data
position in the BNPL ecosystem.

### **Question 1: Designing a New Sign-In Method**

**Framework:** CIRCLES
**Clarifying Questions:**
- What’s the current failure rate for phone number-based sign-ins?
- Are there regulatory constraints (e.g., GDPR) for email/SAML-based
authentication?

**Answer:**
1. **Clarify Goals:**
- **North Star:** Reduce account recovery failures by 50%.
- **Success Metrics:** Activation rate, fraud rate post-launch, CSAT for
account recovery (aligned via **VITAL Framework**).
2. **Security:** Partner with Trust & Safety to enforce MFA for email/SAML and
monitor login anomalies.
3. **Prioritization:** Use **Binary Tradeoffs**—email sign-in (lower effort,
broader adoption) over SSO.
4. **User Experience:**
- First-time: Email/password setup with optional phone linking.
- Returning: Password reset via email + SMS fallback.

---

### **Question 2: Leveraging Connected Accounts for Trust**

**Framework:** CIRCLES + VITAL
**Clarifying Questions:**
- Which platforms (Shopify, Amazon, ApplePay) have the highest user overlap?
- What existing fraud controls apply to connected accounts?
**Answer:**
1. **Core Value:** Allow users to link accounts for seamless checkout while
reducing fraud via verified identities.
2. **Metrics (VITAL):** Fraud reduction (Trackable), checkout speed
(Actionable).
3. **Pitch:** “One-Click Trust” feature—pre-verify users via connected
accounts, reducing friction and fraud.

---

### **Question 3: Proactively Showing Loan Terms**

**Framework:** CIRCLES
**Clarifying Questions:**
- What’s the current drop-off rate at authentication?
- How sensitive are users to upfront APR disclosure?

**Answer:**
1. **Pain Points:** Lack of transparency causes distrust.
2. **Solution:** Pre-auth loan terms preview with toggle for details.
3. **Risks:** Adverse selection → mitigate via soft launch and monitoring
counter metrics (e.g., approval rate).

---

### **Question 4: Returning User Mobile Number Problem**

**Framework:** Root Cause Analysis + Prioritization Matrix
**Clarifying Questions:**
- What % of users attempt revalidation vs. creating new accounts?
- Are there regional failure patterns?

**Answer:**
1. **Root Causes:** SMS delivery issues, stale data.
2. **Solutions:**
- **Quick Win:** Alternate verification (email + security questions).
- **Long-Term:** Account linking (aligns with Q1).
3. **Priority:** Use **Impact vs. Effort Matrix**—focus on quick wins first.

---

### **Question 5: Investigating Authentication Funnel Drop-off**

**Framework:** Root Cause Analysis
**Clarifying Questions:**
- Is the 15% drop-off consistent across segments?
- What’s the retention curve post-drop-off?

**Answer:**
1. **Metrics to Analyze:** Session duration, device type, referral source.
2. **Hypotheses:** UI friction, slow load times.
3. **Action:** A/B test simplified UI and pre-fill known data.

---

### **Question 6: Transitioning to Risk-Based Authentication**

**Framework:** Binary Tradeoffs
**Clarifying Questions:**
- Current fraud rate for low vs. high-risk users?
- How dynamic is the risk scoring model?

**Answer:**
1. **Tradeoffs:** Accept 10% higher engineering effort for 20% retention gain.
2. **Mitigations:** Device fingerprinting to prevent token hijacking.
3. **Metrics (VITAL):** Fraud rate (Trackable), retention (Value-focused).

---

### **Question 7: Fixing 40% Abandonment at ‘Additional Checks’**

**Framework:** Bottlenecks Framework
**Clarifying Questions:**
- Which checks cause the most friction?
- Is there user feedback on this step?

**Answer:**
1. **Bottleneck:** Overly manual data entry.
2. **Fix:** Auto-populate known fields (e.g., address), A/B test reduced steps.

---

### **Question 8: Email Sign-In Conflict with Fraud Systems**

**Framework:** Risk Mitigation Matrix
**Clarifying Questions:**
- Which fraud rules conflict?
- Can email domains be risk-scored?

**Answer:**
1. **Action:** Adjust fraud thresholds for email, phase rollout with monitoring.
2. **Tradeoff:** Delay launch by 2 weeks to refine rules.

---

### **Question 9: Address-Matching Auto-Approve Feature**

**Framework:** CIRCLES
**Clarifying Questions:**
- Current match rate for addresses?
- How does this impact fraud rates?
**Answer:**
1. **Solution:** Auto-approve matched addresses; flag mismatches for review.
2. **Metrics:** Fraud reduction, approval speed.

---

### **Question 10: Passkeys/FIDO2 Re-Authentication Roadmap**

**Framework:** 3W Vision Framework
**Clarifying Questions:**
- Merchant integration complexity?
- Regulatory hurdles by region?

**Answer:**
1. **Vision:** Phased rollout starting with low-risk merchants.
2. **Success Metrics:** Adoption rate, fraud reduction.
3. **Dependencies:** Partner with legal for compliance.

---

### **Question 11: Backlog Prioritization**

**Framework:** Prioritization Matrix
**Clarifying Questions:**
- Engineering capacity per project?
- Alignment with North Star (retention)?

**Answer:**
1. **Priority Order:**
- (a) Email Login → (d) Address-Matching → (c) Device-Token → (b) Google
OAuth.
2. **Rationale:** Email solves high-cost revalidation (Q4).

---

### **Question 12: 3% Drop at ‘Terms of Loan’ Step**

**Framework:** Root Cause Analysis
**Clarifying Questions:**
- Is the drop new or historical?
- Are terms displayed clearly?

**Answer:**
1. **Investigate:** UI clarity, jargon-heavy language.
2. **Fix:** Simplify terms, A/B test visual layouts.

---

### **Question 13: Fraud Spike on Shopify Merchant**

**Framework:** Incident Response Framework
**Clarifying Questions:**
- Timeframe of spike?
- Specific transactions affected?

**Answer:**
1. **Immediate Action:** Freeze high-risk transactions, audit logs.
2. **Collaborate:** Fraud team to identify patterns (e.g., IP clustering).

---

### **Question 14: Higher False-Positives for Returning Users**

**Framework:** Root Cause Analysis
**Clarifying Questions:**
- How is the model trained?
- Feature disparities between new/returning users?

**Answer:**
1. **Audit:** Check feature weights (e.g., transaction history).
2. **Fix:** Retrain model with returning-user data, pilot A/B test.

---

### **Question 15: 3-Week Delay in Risk-Based Auth Rollout**

**Framework:** Tradeoffs Framework
**Clarifying Questions:**
- Critical path tasks causing delay?
- Can scope be reduced?

**Answer:**
1. **Action:** De-prioritize non-critical features (e.g., UI polish).
2. **Outcome:** Maintain North Star via phased delivery.

---

### **Question 16: A/B Test Decision**

**Framework:** Binary Tradeoffs
**Clarifying Questions:**
- $ impact of retention vs. fraud?
- Can fraud be mitigated without killing the feature?

**Answer:**
1. **Decision:** Iterate with stricter fraud rules (block disposable emails).
2. **Tradeoff:** Delay launch to refine controls.

---

### **Question 17: Transitioning Auth Flow Ownership**

**Framework:** Change Management Framework
**Clarifying Questions:**
- Current velocity of Customer Service team?
- Documentation completeness?

**Answer:**
1. **Steps:** Co-development phase, phased ownership, shared KPIs.
2. **Outcome:** Seamless transition without velocity loss.

---

**Key Themes:**
- **Frameworks Used:** CIRCLES (8x), VITAL (4x), Root Cause Analysis (5x),
Binary Tradeoffs (4x).
- **North Star Alignment:** Retention, fraud reduction.
- **Clarifying Questions:** Asked for data-driven context in every answer.
- **Conciseness:** Structured responses with bold headers for scanability.

### **Question 1: Designing a New Sign-In Method**

**Framework:** CIRCLES
**Clarifying Questions:**
1. What’s the current failure rate for phone number-based sign-ins (e.g., due to
number changes)?
2. Are there regional compliance constraints (e.g., GDPR for email data
storage)?
3. What’s the engineering team’s capacity to build email/SAML authentication?

**Answer:**
**Step 1: Clarify the Goal (CIRCLES)**
- **Core Problem:** Users lose access to accounts when phone numbers
change, leading to high churn and support costs.
- **Goal:** Reduce account recovery failure rate by 50% within 6 months.

**Step 2: Identify Customers**

- **Primary Users:** Frequent travelers, expats, or users in regions with
unstable telecom services.
- **Stakeholders:** Trust & Safety (fraud), Customer Support (ticket reduction),
Engineering (implementation).

**Step 3: Report Needs**

- **Pain Points:**
- No fallback authentication method.
- High friction in account recovery (e.g., lengthy SMS verification).

**Step 4: Prioritize Solutions**

- **Option 1:** Email-based sign-in.
- **Pros:** Familiar to users, lower engineering effort.
- **Cons:** Phishing risks.
- **Option 2:** SSO (e.g., Google OAuth).
- **Pros:** Reduced password fatigue, higher security.
 - **Cons:** Limited to users with SSO accounts; longer integration time.
- **Decision:** Prioritize email sign-in first (use **Binary Tradeoffs
Framework**), as it addresses the largest user segment quickly.

**Step 5: Security & Fraud Mitigation**

- **Action Items:**
- Enforce MFA for email sign-ins (e.g., SMS or app-based OTP).
- Partner with Trust & Safety to monitor login velocity (e.g., blocking rapid
failed attempts).
- Use **VITAL Framework** to track metrics:
- **Value-focused:** Retention rate.
- **Trackable:** Fraud rate post-launch.

**Step 6: User Experience**

- **First-Time User Flow:**
- During sign-up, prompt users to add an email as a backup.
- Offer incentives (e.g., “Secure your account with email for faster recovery”).
- **Returning User Flow:**
- Allow password reset via email with SMS fallback.
- If email is unverified, trigger a manual review with Customer Support.

---

### **Question 4: Returning User Mobile Number Problem**

**Framework:** Root Cause Analysis + Prioritization Matrix
**Clarifying Questions:**
1. What’s the breakdown of failure causes (e.g., SMS delivery vs. user error)?
2. Are there regional trends (e.g., higher failure rates in India due to number
recycling)?

**Answer:**
**Step 1: Root Cause Analysis**
- **Data to Collect:**
- Revalidation failure rate by carrier (e.g., AT&T vs. Vodafone).
- User device types (e.g., iOS vs. Android SMS compatibility).
- Time-to-retry (e.g., users abandoning after one failed attempt).
- **Hypotheses:**
1. SMS delivery failures (common in emerging markets).
2. Users no longer have access to old numbers.
3. UI friction (e.g., unclear instructions).

**Step 2: Define North Star Goal**

- **Primary Metric:** Increase successful revalidation rate from 50% to 80% in 3
months.
- **Supporting Metrics:**
- Reduction in Customer Support tickets related to account recovery.
- Retention rate of recovered users.
**Step 3: Identify Pain Points**
- **User Perspective:**
- “I can’t access my loan history because I changed my number.”
- “The recovery process takes too long—I’ll just create a new account.”
- **Business Impact:** High CAC ($100+ per user) wasted on churned users.

**Step 4: Solutions & Prioritization**

- **Quick Win (1-2 weeks):**
- Add alternate verification methods (e.g., security questions, email OTP).
- Simplify UI: Auto-detect country code, pre-fill known user data.
- **Mid-Term (1-3 months):**
- Allow users to link accounts to email (aligns with Q1’s email sign-in).
- Partner with carriers for number portability verification.
- **Long-Term (3-6 months):**
- Implement SSO (e.g., Google OAuth) as a backup.
- **Prioritization Matrix:**
| Solution | Business Impact | Engineering Effort |
|----------|-----------------|---------------------|
| Email OTP | High | Low |
| SSO Integration | Medium | High |

**Step 5: Risk Mitigation**

- Ensure fraud controls are maintained:
- Flag accounts that frequently switch verification methods.
- Monitor for suspicious patterns (e.g., rapid email changes).

---

### **Question 6: Transitioning to Risk-Based Authentication**

**Framework:** Binary Tradeoffs + VITAL
**Clarifying Questions:**
1. What’s the current fraud rate for low-risk vs. high-risk segments?
2. How dynamic is the risk engine (e.g., real-time vs. batch updates)?

**Answer:**
**Step 1: Define the Tradeoffs**
- **Option 1:** Keep binary authentication.
- **Pros:** Simple, predictable fraud rates.
- **Cons:** High friction for low-risk users (e.g., repeat customers).
- **Option 2:** Risk-based authentication.
- **Pros:** Frictionless experience for 80% of low-risk users.
- **Cons:** Engineering effort to build risk tiers; potential new fraud vectors.

**Step 2: Decision Framework (VITAL)**

- **Value-focused:** Improve retention by reducing friction.
- **Trackable:** Monitor fraud rate (goal: <0.5% increase).
- **Actionable:** Start with a pilot for returning users with 12+ months of
history.
**Step 3: Risk Mitigation**
- **New Fraud Vectors:**
- **Token Hijacking:** Implement device fingerprinting (e.g., IP + browser
hash).
- **Social Engineering:** Add step-up authentication for high-risk actions
(e.g., changing loan terms).
- **Metrics:**
- **Leading Indicator:** % of users in low-risk tier.
- **Lagging Indicator:** Fraud loss as % of GMV.

**Step 4: Implementation Plan**

1. **Phase 1 (1 month):**
- Build risk tiers using historical data (e.g., transaction history, device trust
score).
- A/B test low-risk users with token-based auth.
2. **Phase 2 (2 months):**
- Expand to medium-risk users with OTP fallback.
3. **Phase 3 (3 months):**
- Full rollout with dynamic risk scoring.

---

### **Question 11: Backlog Prioritization**

**Framework:** Prioritization Matrix + CIRCLES
**Clarifying Questions:**
1. What’s the engineering effort for each project (e.g., person-weeks)?
2. How do these projects align with the quarterly OKRs (e.g., retention vs. fraud
reduction)?

**Answer:**
**Step 1: Align with North Star**
- **Q4 North Star:** Retention (reduce churn from mobile number issues).
- **Secondary Goal:** Fraud reduction (Trust & Safety mandate).

**Step 2: Evaluate Projects**

1. **(a) Email Login:**
- **Impact:** Directly solves Q4’s revalidation problem.
- **Effort:** 4 person-weeks (frontend + backend).
2. **(d) Address-Matching Auto-Approve:**
- **Impact:** Reduces manual reviews by 30%.
- **Effort:** 2 person-weeks (API integration).
3. **(c) Faster Device-Token Auth:**
- **Impact:** 5% retention lift for returning users.
- **Effort:** 6 person-weeks (risk engine updates).
4. **(b) Google OAuth:**
- **Impact:** Minor convenience gain (SSO adoption is ~20% for target users).
- **Effort:** 8 person-weeks (SAML integration).
**Step 3: Prioritization Matrix**
| Project | Retention Impact | Fraud Impact | Effort |
|---------|------------------|--------------|--------|
| Email Login | High | Medium | Low |
| Address-Matching | Medium | High | Low |
| Device-Token | Medium | Low | Medium |
| Google OAuth | Low | Low | High |

**Step 4: Final Sequence**

1. **Email Login (a):** Immediate retention impact.
2. **Address-Matching (d):** Quick fraud win.
3. **Device-Token (c):** Incremental retention.
4. **Google OAuth (b):** Defer to next quarter.

**Rationale:** Email login addresses the highest-cost problem (Q4’s 50%

revalidation failure) with minimal effort.

---

### **Question 16: A/B Test Decision**

**Framework:** Binary Tradeoffs + VITAL
**Clarifying Questions:**
1. What’s the dollar value of +2 bps retention vs. +5 bps fraud loss?
2. Can we segment results (e.g., exclude high-risk users)?

**Answer:**
**Step 1: Quantify Impact**
- **Retention Gain:** +2 bps = 200 retained users per million → $200K LTV
(assuming $1K LTV/user).
- **Fraud Loss:** +5 bps = $50K loss (assuming $1K avg. loan size).
- **Net Value:** $150K positive.

**Step 2: Mitigation Strategies**

- **Iterate, Don’t Kill:**
- Add fraud rules for disposable email domains (e.g., @[Link]).
- Require MFA for users with mismatched device/IP history.
- **Re-Test:** Launch a refined variant to 10% of users.

**Step 3: Decision Framework**

- **Ship Criteria:** Net positive value + fraud mitigations in place.
- **Tradeoff:** Delay launch by 2 weeks to implement mitigations.

**Step 4: Long-Term Monitoring**

- **Leading Indicators:** Fraud rate by email domain.
- **Fallback Plan:** Rollback feature if fraud exceeds 5 bps.

---
### **General Approach Across Answers**
1. **Clarify Context:** Start with targeted questions to narrow scope.
2. **Framework Application:** Explicitly map steps (e.g., CIRCLES stages).
3. **Data-Driven Prioritization:** Use matrices to weigh impact vs. effort.
4. **Risk Mitigation:** Partner with Trust & Safety and Engineering to address
tradeoffs.
5. **North Star Alignment:** Tie all solutions to retention and fraud reduction.

This structured approach ensures depth while maintaining alignment with

Affirm’s goals and frameworks. Let me know if you’d like even more granularity
on any question!

### Frameworked Approach to Fix Account Revalidation Issues for Affirm

**Framework:** CIRCLES (Clarify, Identify, Report, Cut, List, Evaluate,
Summarize) + Competitive Insights

---

#### **1. Clarify the Problem**

**Core Issue:** Users lose access to their accounts when they change phone
numbers, leading to high churn, support costs, and fraud risks.
**Objective:** Enable seamless account revalidation without relying solely on
phone numbers.

---

#### **2. Identify Stakeholders & Competitive Insights**

- **Primary Users:** Returning users, frequent travelers, expats.
- **Competitors:** Klarna (SSO integration), Afterpay (email-based recovery),
PayPal (multi-factor authentication), Gerald (zero-fee cash advance with email
sign-in) .
- **Key Insights:**
- Competitors prioritize **email/SAML-based sign-in**, **SSO**, and **account
linking** to reduce dependency on phone numbers .
- Jifiti’s white-label BNPL model allows merchants to retain customer data,
enabling alternative authentication pathways .

---

#### **3. Report Needs & Solutions**

**Customer Pain Points:**
- No fallback authentication method beyond SMS.
- High friction in account recovery (e.g., manual support intervention).

**Competitor-Inspired Solutions:**
1. **Email-Based Sign-In**
 - **How It Works:** Allow users to sign in or reset passwords via email
(similar to Affirm’s existing "Forgot Password" feature but expanded) .
- **Example:** Afterpay uses email as a primary recovery method.
- **Implementation:**
- Add email as a mandatory backup during sign-up.
- Use **VITAL Framework** to track fraud rates and retention .

2. **Single Sign-On (SSO)**

- **How It Works:** Integrate with Google, Apple, or Facebook SSO (like
Klarna and PayPal) .
- **Benefits:** Reduces reliance on phone numbers; improves user
convenience.
- **Implementation:**
- Partner with Trust & Safety to enforce MFA for SSO logins.

3. **Account Linking with Partner Platforms**

- **How It Works:** Let users link Affirm accounts to Shopify, Amazon, or
ApplePay (as noted in user-provided questions).
- **Example:** Jifiti’s white-label approach allows merchants to verify users
via existing profiles .
- **Implementation:**
- Use API integrations to validate linked accounts.

4. **Multi-Factor Authentication (MFA)**

- **How It Works:** Combine email/SMS with app-based OTP or biometrics
(e.g., fingerprint, Face ID).
- **Example:** PayPal uses app-based OTP for high-risk actions.
- **Implementation:**
- Phase rollout starting with high-risk user segments.

5. **Backup Security Questions/Recovery Codes**

- **How It Works:** Users set security questions or one-time recovery codes
during sign-up.
- **Example:** Gerald’s cash advance feature uses email verification as a
backup .

6. **Carrier Partnerships for Number Portability**

- **How It Works:** Partner with telecom providers to verify number changes
automatically.
- **Implementation:**
- Pilot in regions with high number recycling (e.g., India).

---

#### **4. Cut Through Prioritization**

| Solution | Impact (Retention/Fraud) | Effort | Competitive Edge |
|---------------------------|--------------------------|--------|------------------|
| Email Sign-In | High | Low | Aligns with Afterpay/Klarna |
 | SSO Integration | High | Medium | Matches PayPal’s user
experience |
| Account Linking | Medium | High | Leverages Jifiti’s
white-label strategy |
| MFA | Medium | Medium | Reduces fraud (like PayPal) |
| Carrier Partnerships | Low | High | Niche but critical for
emerging markets |

---

#### **5. Evaluate Tradeoffs**

- **Email vs. SSO:** Email has lower effort but higher phishing risks; SSO
improves convenience but requires API integrations.
- **Account Linking vs. MFA:** Linking offers seamless UX but depends on
partner ecosystems; MFA balances security and usability.

---

#### **6. Summarize Recommendations**

1. **Short-Term (0–3 months):**
- Launch **email-based sign-in** with MFA (e.g., OTP to email + SMS fallback)
.
- Implement **security questions** for low-effort recovery.

2. **Mid-Term (3–6 months):**

- Integrate **SSO** (Google/Apple) to reduce dependency on phone numbers.
- Pilot **account linking** with Shopify/Amazon for trusted users.

3. **Long-Term (6+ months):**

- Explore **carrier partnerships** in high-churn regions.
- Adopt **white-label authentication** (à la Jifiti) for merchant-specific flows .

**Competitive Advantage:** Combining email/SSO with MFA mirrors best

practices from Klarna and PayPal while addressing Affirm’s unique Trust &
Safety needs.

Below is an expanded, yet still tightly-structured, set of draft answers.

For each of the 17 practice questions you’ll see Clarifying Questions → Framework(s)
Used → Detailed Answer.

Where a Lewis Lin framework is applied I cite the source so the interviewer can see
you are drawing from an accepted playbook.

Q 1 │ Design a New Sign-In Method (email)

 Clarifying questions

1.​ What % of auth failures today stem from lost/changed numbers vs. other
causes?​

2.​ Do regulators (CFPB) treat email as primary PII differently from phone?​

3.​ Do merchants need to update checkout code, or can we ship solely through
the Affirm SDK?​

4.​ What are the fraud-loss and CS-contact baselines we must not exceed?​

Frameworks used

●​ CIRCLES for concept design ​

●​ ICE scoring for solution selection ​

Detailed answer

CIRCLES step Key output

C – Clarify & Mission: Cut re-auth abandonment 30 bps and keep fraud ≤
Goal current. Success metrics: ① Re-auth completion rate (North
Star), ② fraud-loss bps, ③ CS contacts.

I – Identify Primary = returning shoppers; Secondary = Fraud Ops, CS,

stakeholders Merchant Devs, Reg Compliance.

R – Report needs AOERM mapping shows 50 % churn at “OTP retry”. Interviews

reveal main pain: lost SIM or traveling without roaming.

C – Cut/prioritize Severity = High, Users affected ≈ 40 % of daily traffic, Alignment

= direct to retention—score = “P1”.

L – List solutions 1) Email OTP, 2) Email magic-link, 3) Passkey, 4) Google SSO.

 E – Evaluate Email OTP: Impact 0.8 × Confidence 0.9 ÷ Effort 0.5 → 1.44 (top).
(ICE)

S – Summarize Ship email OTP behind a feature flag → 10 % → 50 % → 100 %

over six weeks; monitor North-Star and fraud deltas daily.

Fraud & security controls

●​ Device fingerprint + velocity caps on new email/phone pairings.​

●​ DMARC-aligned “no-reply@[Link]” to shut spoofing.​

●​ If risk score > threshold, auto-step-up to phone SMS.​

Q 2 │ Connected-Account Trust Feature

Clarifying questions

1.​ Which partners expose KYC-verified name, DoB and address (OAuth vs.
signed-JWT)?​

2.​ Is token refresh permissible, or read-only?​

3.​ What conversion-rate lift target justifies extra engineering?​

Frameworks used

●​ CIRCLES (full design) ​

●​ Launch for phased rollout ​

Detailed answer

Goal: Raise approve-rate (+8 bps) and cut synthetic-ID fraud (–5 bps).

Concept: “Trusted Wallet Link.” User links Amazon/Apple once; future checkouts
inherit a “trusted external KYC” score bump.

Key flow
 1.​ Post-loan success screen → “Skip SMS next time – link your Amazon
account.”​

2.​ OAuth → fetch verified name/address.​

3.​ Store token ID in Affirm graph; bump risk model trust.​

Risks & mitigations

●​ Account takeover → bind token to FIDO device; re-consent annually.​

●​ Reg disclosures → show privacy notice at link time.​

Phased rollout (Launch framework)

●​ Soft launch (week 0-1): Employees only.​

●​ Dark launch (week 2-3): Token pipeline on, risk model shadow-scores.​

●​ 50 % flight (week 4-5): Top-3 merchants.​

●​ GA (week 6-8) if CVR ↑ and charge-off ≤ baseline.​

Q 3 │ Show Loan Terms

Before

Full Auth
Clarifying questions

1.​ Can we pull a soft credit inquiry without triggering an adverse-action letter?​

2.​ Which APR / amount ranges must we disclose per TILA?​

3.​ Do merchants want the widget embedded on PDP or Affirm modal?​

Frameworks used
 ●​ CIRCLES + E-B-I (Entice–Benefit–Implementation)​

Detailed answer

Stage Detail

Customer pain Anxiety about “unknown terms” drops “Begin Auth” CTR by 12 %.

Entice “Check your buying power in 5 sec, no credit score impact.”

Benefit Transparency builds trust → more users start auth.

Implementatio • PDP widget → soft-pull → show range (e.g., ₹18k–₹22k, 10-24 %

n APR).• If user proceeds, carry token into full auth to avoid repeat
pulls.• Counter metrics: soft-pull cost, false-positive approvals.

Risks • Regulatory: mis-match between range and final-approved terms

→ mitigate by phrasing “Estimated.”• Fraud: bots farming
pre-quals → lock to device fingerprint.

Success +X % “Begin Auth” CTR, CVR ↑, CS queries unchanged.

Q 4 │ Returning-User Phone-Change Failure (≈ 50

%)
Clarifying questions

1.​ How many failures are “can’t receive SMS” vs. “verification mismatch”?​

2.​ How long since last loan when failure peaks?​

3.​ Carrier and geo breakdown?​

 Frameworks used

●​ Root-Cause Analysis ​

●​ VITAL to select North-Star metric ​

●​ ICE for solution ranking​

Detailed answer

1.​ Investigate (Root-Cause): Pull logs by timestamp, carrier, previous device_id.

Check SMS delivery receipts (Twilio) vs. identity-match errors.​

2.​ North Star (VITAL): Successful re-auth rate – high Value, Intelligible to execs,
Trackable in real-time.​

3.​ Pain points​

○​ Lost SIM while traveling.​

○​ CS manual review queue > 4 min.​

○​ Duplicate-account auto-blocks.​

4.​ Solution set (w/ ICE)​

Idea Impact Confidenc Effort ICE Notes

e

Email fallback OTP 8 9 4 18 Re-use Q1 infra

Trusted-device token 7 7 6 8 Use device

fingerprint

Carrier knowledge-based 5 6 8 3.8 Third-party API

auth
4.​ ​
​

5.​ Plan: Ship email fallback in two weeks; add device-token in Q next; monitor
fraud daily.​

Q 5 │ 15 % MoM Drop of Returning Users

Clarifying questions

1.​ Any code deploy or experiment started the same week?​

2.​ Platform split (iOS/Android/Web)?​

3.​ Seasonality (holiday-to-post-holiday)?​

Frameworks used

●​ Root-Cause Analysis + Hidden Signals ​

Detailed answer

●​ First five metrics and why:​

1.​ Step-wise completion % – pinpoints the bottleneck step.​

2.​ OTP delivery p95 latency – tech friction search.​

3.​ Auth error-code distribution – regression vs. risk rule.​

4.​ CS contact ratio – user-reported issues escalate early.​

5.​ Device-reputation score mix – bot influx or device-ID collision.​

●​ Segmentation cuts: By release version, device OS, merchant.​

●​ Hypotheses: New SMS vendor, risk-model rule change, or merchant javascript

conflict.​

●​ Next actions: Run correlation, roll back recent risk rule if correlation > 0.6; add
synthetic monitoring on OTP latency.​
 Q 6 │ Transition to Risk-Based Auth
Clarifying questions

1.​ Fraud-loss ceiling we cannot exceed?​

2.​ Can current SDK support dynamic step-ups without merchant code change?​

3.​ How many eng sprints available?​

Frameworks used

●​ Binary Trade-offs for decision grid ​

●​ CIRCLES for high-level plan​

Detailed answer

Axis Token (low risk) SMS DocVerify (high risk)

User ++ + ––
friction

Fraud Δ –– Baselin –––

e

Eng effort Med None High

●​ ​
Decision: Adopt tiered model: token for device-trust ≥ 0.9; SMS for 0.5-0.9;
DocVerify < 0.5.​

●​ New fraud vectors: Device cloning, SIM swap after token set. Mitigations:
Re-bind token to hardware key, velocity rules on token creation.​

●​ Pilot metrics: Fraud bps, CVR, CS contacts; trip-wire if fraud > +2 bps.​
 Q 7 │ 40 % Abandon at “Additional Checks”
Clarifying questions

1.​ Main rejection code: blurry selfie vs. address mismatch?​

2.​ Median photo-upload time by network speed?​

3.​ Are we forcing DocVerify for low-risk cohorts?​

Frameworks used

●​ Bottlenecks ​

Detailed answer

1.​ Find bottleneck: Heat map each screen; 80 % drop occurs at “upload ID”
spinner > 8 sec.​

2.​ Quick fixes:​

○​ Skip DocVerify when bureau address exact-matches (cuts 60 % of users

from extra step).​

○​ Inline error reasons & live camera preview; retry without page reload.​

3.​ Long-term: Upgrade SDK to chunked uploads, pre-submit compression;

expected +25 bps completion.​

Q 8 │ Email Sign-In Conflicts with Fraud Systems

Clarifying questions

1.​ Which ML models rely on phone_hash as primary identifier?​

2.​ How early can DS retrain models?​

3.​ SLA for GA date?​

 Frameworks used

●​ Launch + Risk Management ​

Detailed answer

●​ Shadow pipeline: Send email_hash into risk models while still gating users by
phone to compare AUC.​

●​ Launch controls: GA only when ① AUC drop < 0.5 %, ② false-negatives ≤ +1

bp.​

●​ Rollback plan: Feature flag by merchant & device platform within 5 min.​

Q 9 │ Auto-Approve if Shipping = Billing

Clarifying questions

1.​ Does merchant pass raw or tokenized address?​

2.​ Acceptable fraud delta?​

3.​ Do we already collect CVV?​

Frameworks used

●​ CIRCLES (feature design) ​

Detailed answer

●​ Goal: +10 bps CVR with ≤ +1 bp fraud.​

●​ Solution: Merchant webhook sends SHA-256 of normalized shipping and

billing. If hash_match & device_trust > 0.8 → skip extra ID step.​

●​ Risks: Drop-ship fraud; mitigate via velocity check on destination address +

BIN country mismatch.​

●​ Metrics: Approve-rate lift, fraud-loss delta, user NPS.​

 Q 10 │ Passkeys / FIDO2 Roadmap & Zero-Data
Partner
Clarifying questions

1.​ Browser/OS coverage Affirm requires (≥ iOS 17, Android 14?)​

2.​ Legal OK with possession-only factor?​

3.​ Merchant release cycles?​

Frameworks used

●​ Launch ​

●​ AI Data Strategy for zero-data partner bootstrapping ​

Detailed answer

Passkey roadmap

Phase Deliverables Time Owner

Spec WebAuthn service contract + threat Q1 wk 2 TS & Eng

model

Sandbo SDK + iframe update (dev env) Q1 wk 6 Eng

x

Beta 3 merchants, 10 % traffic, fallback SMS Q2 wk 4 PM

GA 50 % → 100 % ramp Q3 PM

Success = +20 bps auth success, fraud unchanged.

Design auth for new partner (no historical data)

●​ Collect foundational signals day 1: device fingerprint, velocity, email/phone

verification.​

●​ Start at high-friction baseline (SMS + DocVerify).​

●​ Instrument every step → build cohort risk curves.​

●​ After 4 weeks, introduce tiered risk model using early repayment data.​

Q 11 │ Prioritize Email, Google SSO, Token,

Address
Clarifying questions

1.​ Contract deadlines with flagship merchants?​

2.​ Eng velocity = 1 sprint = 2 weeks?​

Frameworks used

●​ RICE ​

Item Reac Impac Confiden Effor RIC Rationale

h t ce t E

Email OTP 0.8 0.6 0.9 0.5 0.86 Solves biggest pain; infra
small

Token auth 0.6 0.5 0.7 0.4 0.53 Needed for risk-based
roadmap

Address 0.4 0.4 0.8 0.3 0.43 Merchant work; medium

match fraud risk
Google 0.2 0.3 0.8 0.4 0.15 Nice-to-have, few
SSO merchants ask

Q 12 │ 3 % Drop at “Terms of Loan”

Clarifying questions

1.​ Any copy/UX test deployed last week?​

2.​ Page-load performance (Time-to-Interactive)?​

3.​ Device segmentation?​

Frameworks used

●​ Hidden Signals + A/B Testing ​

Detailed answer

1.​ Investigate:​

○​ Compare TTI vs. prior week; spike on low-end Android?​

○​ Query feature-flag table; recent copy experiment?​

○​ Check risk model gating – are we rejecting more?​

2.​ First two fixes:​

○​ Rollback latest UI experiment; ensure 50 / 50 holdout.​

○​ Implement lazy-load on promo images → cut payload 300 KB.​

3.​ Guard-rail metrics: Ensure fraud & charge-off unaffected.​

Q 13 │ Fraud Spike on One Shopify Merchant

Clarifying questions
1.​ New marketing or coupon blast by merchant?​

2.​ Are charge-offs clustered by BIN, geo, or email domain?​

Frameworks used

●​ Root-Cause Analysis + Risk Management ​

Detailed answer

1.​ Dashboards to open​

○​ Charge-off heat map by merchant/day.​

○​ Approval-rate vs. baseline.​

○​ Device velocity (unique devices / hr).​

2.​ Signals to pull: BIN country, shipping-billing distance, email domain entropy.​

3.​ Calls: Merchant Ops lead, Fraud Ops on-call, Shopify Risk API contact.​

4.​ Immediate action: Raise risk threshold for merchant; if charge-off > 2×
baseline, auto-decline high-risk BINs until root fixed.​

Q 14 │ False-Positive Spike for Returners

Clarifying questions

1.​ Which model version shipped last?​

2.​ Did “on-time repayment count” feature weight change?​

Frameworks used

●​ AI Data Strategy ​

●​ Root-Cause​

Detailed answer
●​ Joint deep-dive with Credit DS: examine feature-importance drift; suspect
repayment-history dilution.​

●​ Patch plan: Add “# paid-in-full loans” feature, retrain; offline AUC +1.2 pts;
push to canary.​

●​ Rollout: 5 % → 25 % → 100 %; monitor approve-rate and fraud.​

Q 15 │ Risk-Based Auth Slips 3 Weeks

Clarifying questions

1.​ Critical-path item: backend service or SDK adoption?​

2.​ Are merchant launches blocked on this?​

Frameworks used

●​ Goals + Focus-vs-Reach Trade-offs ​

Detailed answer

1.​ Re-scope: Defer analytics dashboard (non-critical), keep core risk engine.​

2.​ Pull forward: Low-effort UX copy tweaks and email OTP GA (retention lift).​

3.​ Communication: Update roadmap, notify merchants; North-Star retention

unchanged.​

Q 16 │ A/B Email OTP: +2 bps Retention, +5 bps

Fraud
Frameworks used

●​ Binary Trade-offs + A/B Testing​

Decision grid**
 Option Retention Fraud Verdict

Iterate (tighten risk Aim retain +2 Fraud ≤ +2 Choose

model) bps bps

Ship as-is +2 bps +5 bps (bad) Reject

Kill 0 0 Lose
retention

Plan: 2-week model tuning; if fraud delta ≤ +2 bps, graduate to 25 % → 100 %.

Q 17 │ Transition Auth Flow from CS → Trust &

Safety
Frameworks used

●​ Change-Management / RACI ​

Detailed answer

1.​ RACI: T&S (Accountable), Eng (Responsible), CS (Consulted), Legal (Informed).​

2.​ Handoff sprint: Pair-program bug-fix tickets; knowledge-transfer doc.​

3.​ SLAs: Move auth KPIs to T&S dashboards; weekly joint retro first month.​

4.​ Velocity guard-rail: Freeze feature work for 1 sprint; once error-rate steady,
re-open backlog.​

Next steps

If you’d like even deeper drill-downs (e.g., SQL snippets, risk-model features, or
stakeholder communication templates) let me know and I’ll expand further.
Affirm can make it painless—and secure—for customers who lose access to their
mobile number by layering six families of re-validation options that together cover
every risk tier and UX need.

Below I use Lewis Lin’s CIRCLES framework to structure the solution space and
competitive benchmarking (Klarna, Afterpay, PayPal Pay in 4) to show what “good”
looks like in market.

1 Clarify the Goal (C)

●​ North-star metric: “Successful account-re-access rate” (percentage of
locked-out users who regain access within 5 minutes).​

●​ Guard-rails: fraud losses ≤ existing phone-OTP baseline; CS contacts per 1 000

log-ins not to rise.​

2 Identify Constraints (I)

●​ Regulatory: CFPB & Truth-in-Lending—identity must be verified before
exposing loan details.​

●​ Platform: Affirm already supports Passkeys/WebAuthn and device biometrics

in its app, but web checkout relies on SMS OTP. ​

●​ User base: ≈45 % log in on desktop; 55 % in native app (internal analytics).​

3 Research & Competitor Insights (R)

Provider “Lost-phone” fallback paths Insight to reuse

Klarna Email-link login or CSR-assisted Offer instant email magic-link

phone-change after ID upload. + escalate to CSR only for
high-risk cases.
 Afterpay In-app email–password reset, then Freeze shopping until identity
CSR verifies ID and freezes account proof completes—good risk
until new number is set. guard-rail.

PayPal Lets users choose email + password Provide at least one

Pay in 4 with authenticator-app or backup phone-independent MFA factor
codes; SMS is optional. (auth-app or passkeys).

4 Cut Through the Problem (C)

We need multiple routes ranked by (a) user friction, (b) incremental fraud risk, (c)
engineering lift.

5 List ALL Solution Options (L)

I group the options into six buckets; a healthy account-revalidation program should
eventually support one low-, one medium-, and one high-friction option in every
bucket.

# Bucket Mechanics Frictio Relative Notes / Competitor

n Fraud Risk precedent

A Passkeys / User stores Lowest Very low Already live at

1 WebAuthn FIDO2 (phishing-re Affirm; highlight
credential; sistant) as “Use Passkey
re-auth needs instead of SMS”
device on settings page.
biometric.

A Platform Existing Low Low Surface this path

2 biometrics (Face “Sign-in during recovery
ID / Fingerprint) options” email.
in native app panel.
B Email OTP One-time code Mediu Moderate Klarna primary
1 to verified m fallback; add
email. device
fingerprinting
before token
issuance.

B Email magic link Time-bound Mediu Moderate PayPal offers

2 signed URL. m similar “email
only” entry.

C Social SSO OAuth → fetch Low Low Common in

1 (Google / Apple verified email (piggybacks fintech; minimal
ID) + device Big-Tech user effort.
token. KYC)

C Bank-account Plaid or MX High Very low High build effort

2 SSO (“Link your OAuth; but extremely
Chase login”) re-verify via strong identity
bank. signal.

D TOTP User scans Low Very low PayPal lets users

1 Authenticator-ap QR once; swap from SMS to
p code backup codes Authenticator
stored offline. when phone is
lost.

D Backup static 10 one-use Low Low Google, PayPal

2 codes codes precedent; zero
generated at cost to serve.
signup.

E1 Video / selfie ID User uploads High Very low Used by Afterpay

verification DL + liveness for phone-change.
selfie.
E2 Knowledge-base Out-of-wallet High Medium Useful when doc
d KYC quiz questions. capture fails.
(credit-bureau
data)

F1 CSR-assisted Manual ID Very Very low Industry failsafe;

recovery proof + High Afterpay & Klarna
phone-number do this.
swap;
temporary
freeze.

F2 Virtual number Send OTP to Mediu Low Mitigates

escrow via carrier-confir m SIM-swap; niche
telecom API med SIM but growing.
rather than
SMS.

6 Evaluate (E) with an ICE Quick-Score

Option Impact (0-1) Confidence Effort ICE

(0-1) (person-weeks)

Email OTP (B1) 0.8 0.9 4 1.8

Passkeys (A1) 0.6 0.8 2 2.4

Google/Apple SSO 0.7 0.6 6 0.7

(C1)

Authenticator-app 0.5 0.7 3 1.2

(D1)
 CSR video ID (E1) 0.3 0.9 4 0.68

Recommendation: ship Email OTP + Passkeys promotion immediately (covers >70 %

of stuck users); add Authenticator-app in Q +1; keep CSR route as final safety net.

7 Execute & Summarize (S)

1.​ Sprint 1 (2 weeks) – Backend email-OTP endpoint, device-fingerprint tie-in,
feature flag @ 10 %.​

2.​ Sprint 2 – Front-end banners guiding users to set up Passkeys or Auth-app

during recovery.​

3.​ Sprint 3-4 – Launch Google / Apple SSO beta; instrument approve-rate & fraud.​

4.​ Ongoing – Monitor “Successful account-re-access rate,” fraud bps, CS tickets;

trip-wire = fraud > +2 bps over baseline.​

Why This Works

●​ User choice mirrors market norms—all three leading BNPLs provide at least
one phone-independent path, typically email link + CSR backup. ​

●​ Security scales with risk tier—low-risk cohorts glide through passkeys/email;

high-risk get stepped up to selfie ID.​

●​ Engineering is staged—quick wins (email OTP) do not block richer futures

(SSO, auth-app).​

Affirm therefore closes its single-point-of-failure (phone number) while keeping

conversion high and fraud at or below today’s SMS-only benchmark.