.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Which Pricing Metric Fits Fintech Lenders SaaS Best: Per Seat, Transaction, or Outcome?
Fintech lenders are facing a pricing problem that looks simple until automation changes the operating model. A lender may cut a 60-person underwriting team to 35 people while processing more applications, producing cleaner files, and moving decisions faster. A per-seat contract then pays the software vendor less precisely when the software has created more value.
Outcome pricing seems to solve that mismatch. Yet a fee tied to approval rate, loan balance, interest revenue, or portfolio loss can turn a software supplier into a participant in credit economics that it does not fully control. Funding costs, borrower behavior, risk policy, and macro conditions all move those outcomes. The question is not which meter sounds most innovative. It is which meter gives the lender a fair, auditable, and durable way to pay for software as its business changes.
Monetizely’s position is clear: fintech lenders should use a transaction as the primary SaaS pricing metric. For core lending workflow software, the best transaction is usually a completed, auditable credit-workflow unit, such as a decision-ready application package, rather than a named user or a downstream credit outcome.
A completed workflow reflects the value lenders are actually buying
The relevant unit is not a click, an API call, or an employee login. It is a defined piece of lending work that the platform completes. For consumer underwriting, that may be a decision package containing verified income, identity checks, policy results, and adverse-action data. For commercial lending, it may be a completed credit memo or annual-review case.
A transaction meter works because it rises with the lender’s throughput. More completed lending work means more value from automation, data integration, document collection, workflow orchestration, and compliance controls. A seat count does not track that relationship. Nor does a later business outcome that depends on the borrower’s decision, capital-market conditions, and the lender’s own credit policy.
Monetizely’s 5-Step Pricing Framework places this decision in sequence: Goals and Segmentation, Packaging, Choosing the Right Pricing Metric, Finding the Right Price Points, and Operationalizing Pricing. The sequence matters because a price cannot repair a poorly defined customer segment, and a billing system cannot make an ambiguous meter acceptable. As Monetizing Agentic AI argues, the metric sits at the center of the model: it must connect the buyer’s value, the vendor’s costs, market expectations, and what both parties can administer without recurring disputes.
Six tests clarify why transactions should lead.
| Test | Per seat | Per completed lending transaction | Per business outcome |
|---|---|---|---|
| Tracks value as application volume rises | 2/5 | 5/5 | 4/5 |
| Gives finance a forecastable spend curve | 5/5 | 4/5 | 1/5 |
| Preserves vendor revenue when automation reduces headcount | 1/5 | 5/5 | 4/5 |
| Creates an objective audit trail | 4/5 | 5/5 | 2/5 |
| Avoids incentives around credit policy and risk appetite | 4/5 | 5/5 | 1/5 |
| Is straightforward to meter and explain | 5/5 | 4/5 | 2/5 |
| Total | 21/30 | 28/30 | 14/30 |
The transaction model wins because it links price to work completed while remaining outside the lender’s ultimate risk and funding decisions.
The market does not offer a single template. It does, however, show a consistent move away from human access as the central measure of value.
Blend’s model is the strongest lending-specific example. In its 2025 Form 10-K, filed March 13, 2026, Blend stated that it charges SaaS fees for completed transactions such as funded loans, new-account openings, closing transactions, and API calls. It also reported that it does not charge for abandoned or rejected loan applications, despite incurring costs on them.
Plaid takes the same event-driven logic further down the lending stack. As of September 3, 2026, its pricing documentation describes one-time fees per connected account, subscriptions per connected account, and flat charges for successful API calls. Its Plaid Check underwriting products charge when defined report endpoints are called, creating a visible billable event for lender data and risk workflows.
nCino offers a useful boundary case. In its Form 10-K filed March 31, 2026, nCino stated that it had shifted from seat-based pricing toward subscription fees linked to the assets of the financial-institution lines of business it supports. That approach fits a broad operating platform that delivers value throughout portfolio management, not only at origination. It does not overturn the case for transaction pricing in a discrete lending workflow. It shows instead that a seat meter weakens once a product’s value no longer rests on individual human users.
Upstart illustrates why downstream outcomes require care. Its 2025 Form 10-K, filed February 10, 2026, says that platform and referral fees may be set per unit or as a percentage of loans originated. The company also notes that origination volume depends on factors beyond software performance, including borrower acceptance, interest rates, funding availability, and macroeconomic conditions.
| Company | Pricing evidence and date | What the example establishes |
|---|---|---|
| Blend | Fees on completed lending and banking transactions; no charge for abandoned or rejected applications. FY 2025 Form 10-K, filed March 13, 2026. 2 | A discrete workflow boundary can align vendor payment with customer value. |
| Plaid | Charges vary by connected account, subscription, successful request, report, or payment event. Official pricing and billing materials accessed September 3, 2026. 4 | A transaction can be defined at the level of a verified data or decision event. |
| nCino | Shifted from seat-based pricing to fees aligned with supported line-of-business assets. FY 2026 Form 10-K, filed March 31, 2026. 3 | Seats lose relevance when platform value extends beyond staff access. |
| Upstart | Platform and referral fees may be per originated loan or linked to loan value; volume also depends on funding and market conditions. FY 2025 Form 10-K, filed February 10, 2026. 5 | A funded loan can be a valid event, but it carries more exposure to factors outside the software supplier’s control. |
The evidence points to a practical distinction: price the software’s completed work, not the full financial consequence of that work.
The first two steps of the framework require leaders to decide whom they serve and what each group buys. A community bank buying a loan-origination module is not purchasing the same thing as a national digital lender buying real-time fraud checks and automated underwriting. The meter should remain transaction-based in both cases, but the billable event should reflect the product’s job.
The table below translates that principle into contractable units.
One primary meter can support several products because the underlying logic stays constant: the lender pays when a defined unit of lending work is completed and recorded.
Seat pricing survives when software is mainly a workspace. A CRM used by 50 relationship managers, or a document editor used by 80 analysts, can reasonably be purchased by the user. The human remains the visible anchor for value.
Lending automation changes that anchor. Consider a digital lender that introduces automated document classification, policy routing, income verification, and application decisioning. The platform may support more applications while fewer employees touch each file. A seat price creates an odd result: successful automation lowers the vendor’s revenue and makes the customer’s procurement team expect a discount.
That structure also makes buyer behavior less rational. A lender may limit access to avoid another license purchase, even when broader access would reduce rework and improve controls. Product adoption becomes a cost-management problem rather than an operating-improvement program.
nCino’s move away from seats is instructive precisely because its chosen alternative is not a transaction meter. As of its January 31, 2026 fiscal year end, nCino had repositioned pricing around the assets in the financial institution’s supported lines of business. The deeper lesson is that an employee count is rarely a durable proxy for value once a platform becomes embedded in a lender’s operations.
Outcome pricing entangles the vendor with decisions the lender must own
Outcome pricing should mean payment tied to a later business result: a higher approval rate, lower early-default rate, more funded balances, greater interest income, or improved net interest margin. Those measures are appealing in a sales presentation because they appear to put the vendor “on the hook.”
They also create a harder question: who actually controls the result? A lender’s approval rate can change because its credit policy tightens. Early default can rise because unemployment changes. Funding can fall because capital partners retreat or borrowers reject offers after rates move. The software may perform exactly as promised while the measured outcome declines.
For core underwriting and origination software, outcome fees also risk blurring the line between a technology provider’s role and the lender’s responsibility for credit decisions. Mortgage arrangements demand particular caution. Regulation Z restricts certain loan-originator compensation tied to transaction terms, while the legal definition of a loan originator turns on the activities performed for compensation, not simply on a company’s label.
No pricing team should assume that calling an arrangement “SaaS” settles that question. Bank regulators also expect risk management across the life cycle of third-party relationships, including planning, due diligence, contracting, monitoring, and termination.
A funded loan can still be a valid transaction trigger for a closing or origination module. The line is clear: charge a fixed amount for the completed event, not a percentage of principal, interest revenue, approval rate, or later loan performance.
A three-year view exposes the different economic behavior of each meter
Finance leaders should model the meter before debating its rate. The next exhibit starts each model at the same $120,000 first-year contract value. It then shows what happens when automation reduces users, decision volume rises, and funded-loan volume moves with lender conditions.
The transaction model is the only one that rises steadily with the completed work the software is designed to create, rather than falling with staff or swinging with funding and borrower conversion.
That does not mean lenders should accept an open-ended bill. A transaction-first contract should use an annual volume commitment, graduated rates, and clear overage rules. Those are payment terms, not competing primary meters. They give the buyer a budget and give the vendor enough visibility to invest in support, security, integrations, and product improvement.
Operationalization is the fifth step because even a sound metric fails when the parties cannot count it the same way. The governing question is simple: can a lender’s finance, operations, risk, and procurement teams reconcile the monthly bill to system records without a manual argument?
A transaction contract should specify the rules below before either side negotiates discounts.
| Contract element | Required rule | Buyer benefit |
|---|---|---|
| Unique identifier | Every billable unit has a persistent application, case, or workflow ID | Prevents double billing |
| Completion status | Define the system status that creates the charge | Makes the event auditable |
| Duplicate treatment | State the time window for retries, resubmissions, and corrected files | Prevents charges for operational noise |
| Exclusions | Identify abandoned, test, fraud, withdrawn, and vendor-error events | Protects trust during implementation |
| Credit process | Set a fixed method for disputed units and invoice corrections | Keeps disputes from becoming renewal issues |
| Reporting | Deliver a monthly event file that ties to the invoice | Allows finance and operations to reconcile quickly |
The operational standard should be stricter than the sales promise. If the vendor cannot show the lender why each unit was billed, the metric is not ready for enterprise use.
Pricing lending work creates a cleaner growth path for both sides
A transaction-first model does more than improve billing. It changes the commercial relationship. The vendor earns more by helping the lender process more complete, compliant, and decision-ready files. The lender pays more only when its platform is doing more useful work. Neither side needs to argue over how many employees logged in, whether a borrower accepted an offer, or whether a credit policy change altered portfolio performance.
Monetizely’s position is therefore not that every lender should pay the same amount per event. Rate cards, package depth, implementation needs, and committed volume should differ by segment. The primary meter should not. Price the completed lending workflow, use a seat charge only for genuinely seat-bound tools, and reserve outcome-linked economics for narrow arrangements where causality and legal treatment are both clear.
Classify every product by the work it completes. Separate origination, verification, decisioning, closing, servicing, and portfolio-management modules before setting any price architecture.
Make decision-ready workflow completion the default meter for underwriting software. Count approved and declined files when the product has delivered its promised decision package.
Keep funding as a narrow event trigger. Use it only when a module’s work truly ends at closing or funding, and maintain a fixed fee per event rather than a share of loan economics.
Build annual commitments around forecasted transaction volume, not current staff. Procurement should negotiate volume bands and overage rates from the lender’s operating plan and expected automation gains.
Treat billing data as product infrastructure. Give finance and operations a monthly event-level record from day one, then track disputed-unit rates as seriously as uptime and support tickets.
Footnotes
- https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- Blend Labs, Form 10-K for the year ended December 31, 2025, filed March 13, 2026.
- nCino, Form 10-K for the year ended January 31, 2026, filed March 31, 2026.
- Plaid, Pricing and Pricing and Billing Documentation, accessed September 3, 2026.
- Upstart, Form 10-K for the year ended December 31, 2025, filed February 10, 2026; Consumer Financial Protection Bureau, Rules Governing Loan Origination Practices; Office of the Comptroller of the Currency, Interagency Guidance on Third-Party Relationships: Risk Management.