How Affirm Underwrites a Loan Before the Page Loads

You're at checkout. You've spent twenty minutes picking out an $800 couch, and now a button says "Pay with Affirm."

You click it, type your name and birthday, and within seconds a lending company you've never banked with tells you whether it will loan you $800, at what interest rate, and on what repayment schedule. Without a branch visit, pay stubs, or a waiting period.

Somewhere between your click and that approval screen, in roughly the time it takes to unlock your phone, a system evaluated your creditworthiness, priced a loan, checked for fraud, and generated repayment terms. Affirm processed 55.6 million transactions in their most recent quarter alone, each one through that same pipeline.

The obvious explanation is that Affirm just checks your credit score and says yes or no. Pull the FICO, apply a cutoff, done. But FICO is a blunt instrument for this problem. It tells you whether someone has historically repaid debt. It says nothing about whether this person can afford this purchase at this merchant right now. And for the tens of millions of Americans with thin credit files, FICO barely speaks at all.

Affirm underwrites the transaction, not the person. The per-transaction model requires a different pipeline, different data, and a different latency budget than anything built around a static credit score.

The latency constraint

The constraint that shapes everything is time. A checkout flow that stalls loses the sale. Affirm's S-1 filing describes its system as pricing risk "within seconds at checkout." Technical analysis of their serving architecture describes a "sub-second latency budget" for the ML scoring path.

Those seconds contain a lot of machinery. The merchant's Affirm.js SDK fires an API call to Affirm's servers running on Amazon EKS. Identity resolution matches the consumer. A soft credit bureau pull runs in parallel with internal data retrieval.

From there, the feature store, built on a fork of the open-source Feast project, assembles the input variables. The ML models score the application. A rules engine applies regulatory and business constraints, the pricing engine calculates loan terms, and the response goes back to the merchant.

My piece on why fraud models need 45 milliseconds covers the latency budget for payment authorization. Affirm operates under the same physics on a harder problem, because credit risk scoring and loan pricing involve more model complexity than a binary fraud classification.

What the model sees

Affirm's investor materials describe the underwriting inputs in three categories, and a fourth added more recently.

External credit bureau data comes first. Affirm performs a soft pull, which doesn't affect the consumer's credit score. This gives the models a baseline of existing credit accounts, payment history, outstanding balances, and inquiries.

Internal Affirm data is where the proprietary signal lives. Every prior Affirm loan a consumer has repaid adds to a behavioral profile that no credit bureau tracks. Affirm sees repayment at the installment level. They know whether you paid the third installment of your shoe purchase two days early, on time, or five days late.

Bureaus track account status (current, late, charged-off) rather than per-payment behavior. That granularity is invisible to traditional scoring.

Transaction context rounds out the real-time inputs. Merchant category, item price, requested loan term, the specific SKU when the merchant integration provides it. A four-payment zero-interest plan on $150 running shoes from a retailer with low return rates is a different risk profile than a 12-month financed $3,000 mattress from a merchant with high dispute rates.

Affirm has also described adding real-time bank account signals, including balances and cash flow trends from linked accounts. If a consumer connects their bank, the underwriting model can see whether they have enough in checking to cover the first payment.

The feature store assembles the full set of variables in real time. When a checkout request arrives, the system needs answers to questions like "how many Affirm loans has this consumer completed in the last 12 months" and "what is the default rate for this merchant's category" within single-digit milliseconds. Affirm's fork of Feast, visible on their public GitHub, serves this purpose. The concept is similar to what Chime built for fraud scoring at neobank scale, a precomputed store that guarantees the features served during a live decision match exactly what the model saw during training.

Per-transaction underwriting

The core architectural decision that separates Affirm from traditional lending is per-transaction evaluation. A credit card issuer underwrites you once, assigns a limit, and lets you spend against it. That's like a restaurant giving you a tab based on how you look when you walk in. Affirm prices each dish separately, based on what you ordered, what this kitchen charges, and whether you've paid your last four tabs on time.

The same consumer can get approved for a $200 purchase and declined for a $2,000 one in the same afternoon. The models factor in the merchant's historical performance, the product category's default rate, and the specific loan term. Affirm's investor press release describes this as underwriting "every transaction in addition to every single person, every single time."

Traditional lending can't justify this because the underwriting cost per decision is too high. Running a bureau pull, scoring a model, and generating adverse-action documentation for a $150 transaction only works if the marginal cost per decision approaches zero. Affirm built the automation to get there.

The scale this produces is considerable. $50.2 billion in gross merchandise volume for fiscal year 2026, across 28.7 million active consumers and 620,800 active merchants. The average order value is $258, and active consumers average 7.3 transactions per year on the platform.

That means the typical user gets underwritten seven times. Each decision runs through the full pipeline.

The two-stage model

For most of its history, Affirm ran gradient-boosted decision trees, likely XGBoost or LightGBM, for real-time credit scoring. Job postings confirm the stack includes Python, PyTorch, XGBoost, Scikit-Learn, Spark, Airflow, Kubeflow, and Ray. These models score in low single-digit milliseconds on CPU hardware, which fit inside the sub-second latency budget with room to spare.

In September 2026, Affirm deployed something more ambitious: a two-stage architecture that puts a transformer in front of the gradient-boosted trees.

The first stage is a transformer that processes credit report data as sequences. Each tradeline and inquiry on a consumer's credit file becomes a token combining numerical fields (balance, payment amount), categorical fields (account type, status), and encoded monthly payment sequences.

The attention mechanism weighs relationships among these records, and temporal encoding distinguishes older information from recent changes. The output is a dense embedding, a compressed numerical representation of credit behavior patterns, rather than a score the rules engine could act on directly.

The second stage is an accelerated failure time XGBoost model. It takes the transformer's embeddings alongside traditional features (transaction details, merchant data, Affirm repayment history) and produces the actual credit decision.

The transformer by itself was tested and "never performed well enough to justify production," according to technical analysis of the architecture. But as a feature extractor feeding XGBoost, it unlocked patterns the hand-engineered features missed. Affirm's previous models relied on features that engineers selected manually. The transformer learns which patterns in a credit history matter, using attention to discover relationships that no human specified.

The result, reported in Affirm's Q1 FY2027 shareholder letter: 3.4% more completed purchases (higher approval rates) with credit losses held flat. The model approved thin-file consumers and those without FICO scores that the prior system would have declined, without increasing the loss rate.

Training runs on distributed GPUs with mixed-precision computation and gradient accumulation, but the parameter count is kept "relatively small" to preserve serving speed. Affirm optimized both CPU and GPU paths for the full pipeline to stay within the sub-second budget.

Sitting on top of the ML scoring is a deterministic rules engine. Regulatory constraints (state-level usury caps, adverse-action requirements, Military Lending Act compliance), business rules (merchant-specific limits, maximum loan sizes), and model override logic execute after the ML models complete. The rules add predictable latency, microseconds per evaluation, unlike the variable cost of model inference.

The underwriting decisions remain "deterministic, transparent, and explainable to consumers," per the shareholder letter. Affirm built a proprietary explainability algorithm for the transformer stage that matches the rigor of traditional model explanation methods. When the system declines a consumer, it produces an adverse-action reason code traceable to specific model outputs, as required by fair lending regulations.

No late fees changes the math

Most consumer lenders have a safety valve. If a borrower misses a payment, late fees and penalty interest rates recover part of the loss. The credit card industry collected over $14 billion per year in late fees alone, per a CFPB analysis of credit card penalty revenue.

Affirm charges no late fees. That's a product decision, but it functions as an engineering constraint. Without the late-fee backstop, the underwriting model must be more accurate upfront. A traditional lender can afford to approve marginal borrowers because late fees offset some defaults. Affirm absorbs every bad loan at full cost.

The Q1 FY2027 shareholder letter reports 30-plus-day delinquency of 2.9% on monthly installment loans (excluding Peloton). Recent cohorts are tracking about 3.5% in ultimate net charge-offs as a percentage of cohort GMV. Pay-in-4 products, the short-duration four-payment plans, run loss rates below 1% of GMV.

Those numbers reflect calibrated risk appetite. Affirm's models could produce lower losses by declining more marginal borrowers. But the company's thesis, articulated by CEO Max Levchin since the S-1, is that many people excluded by traditional lending can repay if the terms are structured correctly. A consumer who would default on a 24% APR revolving credit line might successfully repay a 15% APR installment loan for a specific $400 purchase. The model's job is to distinguish those borrowers from ones who genuinely can't repay.

The provision for credit losses in Q1 FY2027 was $259.4 million on $890.5 million in revenue. That's the direct cost of the model's errors, and the no-late-fee policy means there is no secondary revenue stream to cushion it.

The merchant integration

Affirm's underwriting runs inside another company's checkout. The merchant embeds Affirm's JavaScript SDK, calls affirm.checkout() with order and customer data, and either opens a modal or redirects to Affirm's hosted flow. On approval, the merchant receives a checkout token and authorizes the transaction via API.

This integration provides critical data for the underwriting model, specifically what the consumer is buying and from whom. But it also imposes a UX constraint. If Affirm's decisioning stalls, the merchant's conversion rate drops. 620,800 merchants run this integration, and each one has limited patience for latency.

Affirm targets 99.99% availability on the checkout path, four nines, according to an AWS case study describing their infrastructure. The checkout service runs as microservices on Amazon EKS with Istio VirtualService for traffic routing, Application Load Balancer for ingress, and Amazon Aurora as the primary database.

The architecture uses single-region deployment with multi-availability-zone redundancy. Active-active multi-region was evaluated for the next availability tier (99.999%) but deferred.

Amazon alone accounts for 20% of Affirm's GMV. The top five merchant partners generate 40%. That concentration means a latency regression or availability incident affecting a single large merchant has outsized impact on the business.

The merchant data creates a feedback loop that traditional lenders don't have. Affirm knows which merchants generate loans with low default and full repayment, and which generate troubled portfolios. Over time, this signal shapes the underwriting model itself: a checkout at a merchant with historically strong repayment rates gets a different risk assessment than the same consumer at a merchant with poor performance.

The data moat

Affirm's S-1 filing disclosed that their risk models had been calibrated on over one billion data points from 7.5 million loans across six years of repayments. That was 2020. By late 2026, the company has accumulated fourteen years of transaction-level lending data. FY2026 alone produced $50.2 billion in GMV, with prior years adding tens of billions more.

The compounding advantage is structural. A first-time Affirm user gets underwritten mostly on bureau data and transaction context, while a returning user who has completed seven transactions (the current average) carries proprietary behavioral signals that no competitor can access. The bureau doesn't know that this consumer pays Affirm installments three days early on purchases under $300 and on the due date for purchases over $500. Affirm does.

A competitor entering BNPL lending today faces a cold-start problem. No proprietary repayment data means underwriting on bureau scores alone, which means higher decline rates for thin-file consumers, fewer transactions, and slower data accumulation. Affirm processes over 55 million transactions per quarter. Each one extends the training corpus.

The constraint on this advantage is regulatory. The CFPB's 2024 interpretive rule classifying BNPL providers as credit card issuers under the Truth in Lending Act added dispute and refund obligations. My coverage of BNPL becoming infrastructure traces the broader market shift this rule accelerated. For the underwriting engine specifically, the regulatory layer adds compliance checks to the pipeline without changing the core ML architecture. But it does add latency: every decline must produce a compliant adverse-action notice, and the system must document the model outputs that drove the decision.

Affirm doesn't hold the loans it originates on its own balance sheet indefinitely. Celtic Bank and Lead Bank are the originating bank partners. Affirm then purchases the loans and either holds them, securitizes them, or sells them to institutional investors. The underwriting model's accuracy directly affects the price those investors will pay.

What would you build differently

Affirm's architecture is coherent. Every component, the latency budget, the Feast-based feature store, the two-stage transformer-XGBoost pipeline, the merchant integration, the retraining infrastructure, was designed around the same constraint: decide fast enough that the consumer never notices, and get better with every loan repaid.

But the design has costs.

Per-transaction underwriting at 55 million decisions per quarter generates a compliance load that scales linearly with volume. Every decline needs a reason code traceable to a specific model output. The proprietary explainability algorithm for the transformer stage adds engineering complexity that a simpler model wouldn't require. That is a team and a codebase dedicated to making a black-box model legally transparent.

The data moat is also a data dependency. Affirm's models are most accurate for repeat users. First-time consumers get underwritten on thinner signals, which means either conservative declines (losing potential good borrowers) or optimistic approvals (eating losses the model can't calibrate). The cold-start problem solved at the company level persists at the individual-consumer level. The recent addition of linked bank account data helps, but only for consumers who opt in.

Amazon generating 20% of GMV is a merchant concentration risk that flows directly into the underwriting pipeline. If Amazon changed its BNPL integration or dropped Affirm, the loss wouldn't just affect revenue. It would remove the training data from the merchant with the highest transaction volume, potentially degrading model performance across adjacent categories.

And the no-late-fee model means $259 million in quarterly credit losses with no fee-based cushion. A competitor willing to charge late fees gets a wider margin of error in their underwriting. Whether that flexibility produces better or worse consumer outcomes is the policy debate at the center of BNPL regulation.

The system is engineered around a bet that per-transaction underwriting with proprietary data produces credit decisions accurate enough to sustain a business without the revenue safety net of fees. Fourteen years of loss data suggests the bet is working. The transformer upgrade suggests Affirm thinks the ceiling hasn't been reached.