The Outlier Lab

Multi-Factor Authentication (MFA)

Requiring two independent factors at login and, more importantly, at the money-moving moments: payout changes, withdrawals, new payees, contact changes and authenticator changes.

What it is

"We have MFA" tells you almost nothing. Consumer MFA covers SMS and voice OTP, email codes, authenticator-app TOTP, push approval (with or without number matching) and FIDO/WebAuthn credentials. Those options differ by an order of magnitude in what they stop. To judge an MFA deployment, ask three things: which factor, where in the flow it is enforced, and what the fallback is.

For transaction fraud the second question matters most. Login MFA guards the front door, but the money leaves through a handful of endpoints: add or change a payout destination, withdraw, send to a new P2P payee, start an outbound ACATS transfer, liquidate positions, redeem a rewards balance to cash, provision a card to a wallet. A session that passed MFA at 9:00 and then adds a new bank account and withdraws everything at 9:04 was never re-verified for the action that caused the loss. Stolen session tokens skip login entirely. Good MFA design for a fraud team therefore ties a factor to the transaction as well as the session (see Risk-Based Authentication and Step-Up).

What it stops (and what it doesn't)

ThreatOTP at login onlyOTP bound to the actionPhishing-resistant (FIDO)
Credential Stuffing / password reuseStops mostStopsStops
Real-time phishing relayWeak: the code is relayedSomewhat better if the prompt shows the payee and amountStrong: the credential is bound to the origin
SIM Swap and Port-Out FraudFails if SMS is the factorFails if SMS is the factorStrong
Session token theft (Session Hijacking and Infostealers)Not in the pathStrong if payout requires a fresh factorStrong if payout requires a fresh assertion
Talking a customer into reading out a codeWeakPartial: messages that name the action ("you are adding a new bank account") helpStrong: there is no code to read out
Push fatigueWeak without number matchingPartialn/a
Authorized Push Payment (APP) Scams, Impersonation ScamsNone: the customer authenticatesNoneNone
First-Party FraudNoneNoneNone

The last two rows are the ones to remember. MFA proves who is acting. It says nothing about whether that person intends fraud or has been deceived. Pair it with Payee Confirmation and Payment Friction and Transaction Monitoring.

Design considerations

  • Bind codes to actions. A code issued for "log in" should not be able to authorize "add payee". Generate codes per action server-side, include the action details in the prompt and the SMS text, and expire codes quickly. This is the core idea of the EU/UK "dynamic linking" rule under strong customer authentication, and it is good practice wherever you operate.
  • Treat your weakest enabled factor as your actual assurance level. If an account has both a passkey and SMS enabled, an attacker picks SMS. For high-risk actions you can refuse the weaker factor, or accept it with compensating controls such as a hold or a cooling-off period.
  • Treat an authenticator change as a high-risk event. Under NIST SP 800-63B-4, changing the registered phone number counts as binding a new authenticator. Require a factor the customer already has, notify every prior channel, and send the event to Account Change Events and Contact Change Cooling-Off Periods.
  • Check phone-number risk before sending a code. NIST now classes PSTN delivery (SMS and voice) as a restricted authenticator. It recommends checking for SIM change, number porting and device swap before sending an OTP. Phone Risk Signals supplies that carrier data.
  • Enroll early. If an attacker takes over an account that has no MFA and enrolls their own factor, MFA now protects the attacker. Enroll at onboarding or at first funding, and require existing-factor confirmation to add a new one.
  • Don't let remembered devices skip payout checks. A "trust this device for 30 days" cookie is a session convenience and shouldn't authorize money movement (see Device Binding and Trusted Devices).
  • Harden push approval. Use number matching, show context (location, action, amount), rate-limit prompts, and treat a burst of denied pushes as an attack signal.
  • Feed login risk into the decision. Login Anomalies such as a new device, impossible travel or a burst of failures should change which factor you ask for as well as whether you ask.
  • Cover every channel. Web, both mobile apps, legacy app versions, partner and aggregator APIs, IVR and support-assisted flows all need the same policy. Attackers find the channel that doesn't enforce it.

Industry lens. Brokerage: MFA at login plus fresh MFA at withdrawal, bank-link change and outbound ACATS. Neobank / P2P: at new-payee add and at the first send to a payee. Cashback / rewards: at cash-out of a balance to PayPal, a bank account or a gift card, which is where ATO on reward accounts turns into money. Marketplaces: at seller payout-account changes. Retail: at stored-value and gift-card redemption and at changes to a saved card.

Implementation path

StageWhat it looks likePrerequisites
CrawlOptional SMS/TOTP at login; mandatory OTP for payout-destination changes and withdrawals; notifications on every factor or contact changeVerified phone or email on file; OTP provider; event logging of auth outcomes
WalkMFA mandatory once an account holds value; step-up at payee add, payout change, contact change and MFA change; codes bound to actions; push with number matching; carrier checks before SMSPolicy hooks at transaction endpoints; carrier/phone-risk data; consistent enforcement across channels
RunPhishing-resistant factor by default (Passkeys and Phishing-Resistant Authentication); SMS kept as a restricted fallback with compensating controls; authentication strength and recency used as model features; recovery redesigned so it can't sidestep MFAWebAuthn support; Secure Account Recovery Design; feature pipeline into Real-Time Transaction Risk Scoring

Customer friction and trade-offs

  • Delivery failures. SMS breaks for international, VoIP and prepaid numbers and for people with poor coverage. Each failure becomes an abandoned transaction or a support contact. NIST requires an alternative to PSTN to be available for exactly this reason.
  • Mandatory vs optional. Optional MFA tends to end up protecting your most security-minded customers, who were least likely to be compromised. A common compromise is to make it mandatory at the first value-holding event (first deposit, first reward balance above a floor).
  • OTP cost and abuse. OTP endpoints cost money per message and can be abused to generate artificial SMS traffic. Rate-limit them like any other endpoint (Rate Limiting and Throttling).
  • Friction placement. Customers tolerate a challenge when they are moving money. They resent one every time they open the app. Moving friction from login to payout often improves both conversion and loss. See Friction and Customer Experience Tradeoffs.

Measuring effectiveness

MetricWhat it tells you
MFA-passed ATO rateShare of confirmed ATO cases in which the attacker passed MFA, split by factor type. A rising rate means attackers are defeating MFA itself.
ATO loss per 1,000 active accountsSplit by enrolled factor type and by whether the losing action needed a fresh factor
Challenge economicsCompletion rate, abandonment, time to complete, and support contacts per 1,000 challenges, by factor and channel
Fallback usageHow often customers drop to weaker factors, and whether the fraud rate after a fallback is higher
Change-then-cash-outHow often an MFA method change or contact change comes before a payout within a short window; a leading indicator for Payout Redirection

Holding out MFA as an experiment is rarely acceptable, so use pre/post comparisons and enrollment cohorts, and correct for the fact that customers who opt in are already lower risk. See Fraud Metrics and KPIs.

Common failure modes

  • Login-only enforcement. The payout, payee and contact-change endpoints don't require a fresh factor.
  • Recovery bypass. The "lost my phone" path resets MFA with weaker evidence than MFA itself (Account Recovery Abuse).
  • Support override. An agent can disable or reset MFA on a call. The control is then only as strong as the agent's script (Customer Support Verification Protocols).
  • Context-free codes. A message that says only "Your code is 123456" makes social engineering easy.
  • Long-lived trust cookies that let a stolen session or a cloned browser profile skip MFA.
  • Unprotected surfaces. Legacy app versions, partner APIs or IVR flows that don't enforce MFA.
  • Over-trusting a pass. Teaching models and rules that "passed MFA" means safe, so the fraud that does get through is waved past every later check.

Regulatory and policy notes

  • FFIEC (2021). Authentication and Access to Financial Institution Services and Systems (SR 21-14, August 11, 2021) replaced the 2005 and 2011 guidance. It describes single-factor authentication as weak, supports MFA or controls of equivalent strength within layered security, and flags risks from push-payment capabilities. Examiners use it in supervision.
  • NIST SP 800-63B-4 (Revision 4, final, published August 2025):
    • At AAL2, verifiers must offer at least one phishing-resistant option.
    • PSTN delivery is a restricted authenticator, which brings risk-acceptance, notice and migration-plan obligations.
    • Email may not be used for out-of-band authentication.
    • Changing the registered phone number counts as binding a new authenticator.
    • These are federal requirements, but they are the de facto benchmark used by examiners and auditors.
  • Reg E. Consumer liability for unauthorized transfers depends on when the customer gave notice. Consumer carelessness does not by itself increase that liability. Passing MFA is evidence in an investigation, not a liability shield (see Regulation E and Unauthorized Transfers).
  • Broker-dealers. Identity-theft red-flag obligations apply (see Broker-Dealer Obligations (FINRA and SEC)).

Mechanisms addressed

Sources and further reading