Loan scenario pricing is the process of using a pricing engine (PPE) to generate, compare, and deliver borrower-ready rate scenarios that feed directly into your disclosures. The single most important thing you can do is confirm that your PPE's outputs map cleanly to TRID and GFE disclosure fields and that your platform enforces lock and quoting guardrails automatically. Get that wrong, and every quote downstream carries compliance risk. We build this guidance from two decades of operational experience, including that of our founder, Omar Khamisa.
TL;DR:
- Price scenarios must accurately reflect current market rates and be refreshed regularly to prevent quoting stale information amid volatile conditions.
- Scenario labels should clearly state their optimization goal, such as lowest payment or lowest closing costs, to avoid confusion for loan officers and borrowers.
- Disclosures require precise mapping of PPE output to GFE and TRID tables, including interest rates, loan amounts, costs, and timing to ensure compliance.
- Automated system guardrails like lock enforcement, fee classification, and versioned disclosures are essential to prevent tolerance violations and audit failures.
- An integrated platform that links pricing, LOS, and compliance tools reduces errors, streamlines workflows, and maintains an audit trail for all scenario revisions.
Table of Contents
- What a broker-focused pricing engine actually does
- GFE and TRID rules that shape what your scenarios must show
- Inputs that change the price of every scenario
- Running scenario pricing from intake to disclosure
- Guardrails that prevent tolerance violations
- Setting up scenario pricing correctly: a short checklist
- Types of loan pricing scenarios brokers run every day
- How credit and property factors move the price
- Compliance beyond GFE and TRID
- Common mistakes brokers make with scenario pricing
- Tools and software brokers rely on for scenario pricing
- How market conditions move your scenario pricing
- A founder's view on why connected pricing matters
- How 1 Solution brings pricing, LOS, and compliance together
- FAQ
- Sources
What a broker-focused pricing engine actually does
A product and pricing engine, or PPE, is the system that turns raw borrower and loan data into priced, comparable scenarios. It is not a consumer calculator that spits out a rough monthly payment estimate. A real PPE applies lender rate sheets, overlays, and eligibility rules to produce scenarios you can actually quote and lock.
Core capabilities worth checking for in any PPE:
- Scenario generation across multiple lenders and products at once
- Automatic application of rate grids, adjustors, and lender-specific rules
- Points, credits, and fee modeling side by side within the same request
- Parallel scenario comparison, such as lowest rate versus lowest closing cost
- Direct connection to your loan origination system (LOS) so pricing data flows into the file without re-entry
When pricing lives inside your LOS and CRM rather than as a separate tool, you get fewer re-disclosures, faster borrower response times, and a cleaner audit trail from quote to closing. That connection is also what keeps your pipeline moving instead of stalling on manual data entry between systems.
GFE and TRID rules that shape what your scenarios must show
Every scenario your PPE produces eventually becomes a disclosure, and that disclosure has to meet federal timing and content rules. Under Regulation Z's GFE provisions, the Good Faith Estimate must go out no later than 3 business days after you receive an application or enough information to treat it as one, and certain estimates must stay available to the borrower for a set period unless circumstances change.
Your PPE output needs to map to the specific disclosure tables required by law, including:
- Loan terms (rate, loan amount, prepayment and balloon features)
- Projected payments over the life of the loan
- Costs at closing, broken into loan costs and other costs
One tolerance detail worth building guardrails around: certain charges on the GFE are subject to a tolerance band that limits certain charges to not exceed their original estimate by more than a small margin, meaning final costs cannot exceed the original estimate by more than that margin without triggering a revised disclosure. When a changed circumstance or a new lock pushes a fee outside that band, you need a documented reason for the revised GFE, and that documentation has to be retained for 3 years. Build these tolerance checks into your workflow now, not after a file gets flagged in an audit.
Inputs that change the price of every scenario
Small changes to a handful of fields can shift a quoted rate or payment meaningfully, so your intake process should capture these cleanly before you run any scenario.
- Interest rate and lock status: whether the rate is locked, floating, or pending, and for ARMs, the index and margin that determine future adjustments
- Loan amount, term, and payment schedule: 15-year versus 30-year, fully amortizing versus interest-only
- Discount points and lender credits: these trade upfront cost against rate, and mixing them up in a scenario label creates confusion fast
- Origination fees, third-party fees, and escrow estimates: these drive the "costs at closing" table borrowers see
- Mortgage insurance requirements: conforming loans with low down payments often carry MI that changes the effective payment
- Product tier: conforming versus jumbo pricing can differ substantially in rate and overlay requirements
Pro Tip: Label every parallel scenario by what it optimizes for, such as "lowest payment" or "lowest closing cost," so loan officers and borrowers never have to guess which number means what.
Timing matters too. A rate sheet from this morning may not reflect this afternoon's market move, so any PPE worth using needs to refresh pricing often enough that your quotes stay honest.
Running scenario pricing from intake to disclosure
A repeatable workflow keeps every file auditable and every disclosure defensible. Here is the sequence we recommend:
- Standardize intake: collect the borrower fields your PPE requires (credit profile, property type, loan purpose, occupancy) and run a data quality check before pricing anything.
- Run parallel scenarios: generate multiple options and label each one clearly, distinguishing rate-driven scenarios from points-driven or credit-driven ones.
- Vet against disclosure templates: confirm the chosen scenario's fields match your GFE/TRID templates and that lock terms align with your lock desk's rules.
- Issue the disclosure: produce the GFE or Loan Estimate from the vetted scenario, not from a separate manual recalculation.
- Document any revision: if a changed circumstance forces a new GFE, record the specific reason and retain that documentation for the required 3-year window.
Brokers who skip step three, vetting against the template, are the ones who end up re-disclosing weeks later because a fee category didn't map the way they assumed. Our internal guide on TRID disclosure timing walks through the operational side of this in more detail.
Guardrails that prevent tolerance violations
Tolerance violations rarely come from bad intentions. They come from systems that let a quote go out without checking it against the rules first. The fix is technical, not procedural.
- Lock-window enforcement: your platform should block a scenario from being quoted past its lock expiration without triggering an automatic re-price
- Fee classification: flag third-party fees as shoppable or non-shoppable so your PPE applies the correct tolerance band to each
- Versioned disclosures: every GFE should carry a timestamp and a version number, so you can show exactly what changed and when
- Audit logging: keep a record of who generated each scenario and when it was approved for disclosure
Pro Tip: Treat every revised GFE as a compliance event, not a paperwork update. Log the reason, timestamp it, and store it with the file for the full 3-year retention period.
Automated guardrails like these are what separate a platform built for brokers from a spreadsheet with a pricing grid bolted on.
Setting up scenario pricing correctly: a short checklist
Getting your pricing engine configured right the first time saves weeks of cleanup later. Before you go live, confirm:
- Required borrower and loan inputs are defined and mandatory in intake
- PPE output fields map one-to-one with your disclosure template's tables
- Lock rules and expiration triggers are configured and tested
- Test cases cover at least one scenario per loan type you originate
- Staff are trained on scenario naming conventions and disclosure versioning
A consistent naming standard matters more than it sounds like it should. "30yr fixed, lowest payment" tells a loan officer something useful; "Scenario 4" does not.
| Setup element | What to define |
|---|---|
| Scenario naming | A standard format noting loan type and optimization goal |
| Disclosure versioning | Timestamp and version number on every GFE issued |
| Field mapping | Direct correspondence between PPE output and disclosure table |
| Test coverage | At least one validated case per loan product offered |
Types of loan pricing scenarios brokers run every day
Not every borrower needs the same scenario, and running the wrong mix wastes time on both sides of the conversation. Fixed-rate scenarios are the most common starting point: the rate and payment stay level for the full term, which makes them easy to explain and easy to disclose.
Adjustable-rate scenarios introduce more moving parts. You're pricing an initial fixed period, then modeling what happens when the rate resets against an index plus a margin. Borrowers comparing a fixed-rate option against an ARM need to see both the initial payment and a reasonable projection of what adjustment caps could do to that payment later.
Interest-only scenarios change the payment structure entirely. Because principal isn't amortizing during the interest-only period, the projected payments table in your disclosure needs to clearly show when that period ends and what the payment becomes afterward.
Beyond those three, you'll often price:
- Jumbo scenarios, where loan amounts exceed conforming limits and rate adjustors tend to be steeper
- Buydown scenarios, where points fund a temporary rate reduction in the early years
- Cash-out refinance scenarios, where loan-to-value and use of proceeds affect pricing differently than a rate-and-term refinance
Running parallel scenarios across these types for the same borrower, clearly labeled, is usually what helps them understand the tradeoff instead of just picking the lowest number on the page.
How credit and property factors move the price
Two borrowers with identical loan amounts can see meaningfully different pricing once credit profile and property characteristics enter the equation. Credit score tiers drive rate adjustors on most conventional products, and the gap between a borrower in the top tier and one just below it can show up as a real difference in the quoted rate.
Debt-to-income ratio and reserves matter too, since they affect eligibility for certain products before pricing even becomes the question. A borrower who qualifies for multiple products at different DTI thresholds may see different scenarios depending on which program you're pricing against.
Property characteristics layer on their own adjustors:
- Occupancy type: primary residence, second home, and investment property each carry different risk-based pricing
- Property type: condos, especially non-warrantable ones, often carry adjustors that single-family detached homes don't
- Loan-to-value: higher LTV scenarios typically require mortgage insurance and carry steeper rate adjustors
A PPE that doesn't let you toggle these variables independently will give you a technically accurate scenario that still misleads the borrower about what's actually driving their price. Configuring intake to capture occupancy and property type up front, rather than after a scenario is already run, avoids having to redo the comparison later.
Compliance beyond GFE and TRID
TRID and the GFE rules govern disclosure content and timing, but they aren't the only regulatory layer touching your pricing. RESPA's prohibitions on kickbacks and fee-splitting affect how you structure referral relationships tied to pricing or service providers named in a scenario. If a scenario includes a required third-party service, the fee attached to it has to reflect what that service actually costs, not an inflated figure routed back to you.
CFPB guidance also shapes how pricing and steering get evaluated, particularly around loan originator compensation rules, which restrict how an originator's pay can vary based on loan terms. A pricing engine that lets compensation structures influence which scenario gets presented to a borrower creates exposure under those rules, so the scenarios you present should be driven by borrower fit, not by which option pays more.
State-level licensing and fee caps add another layer that varies by where you're licensed to originate. None of this replaces legal advice specific to your situation, but it's worth treating your PPE configuration as a compliance tool, not just a pricing calculator. Getting the disclosure content right under TRID means little if the process that generated the scenario violates RESPA or compensation rules upstream of it.
Common mistakes brokers make with scenario pricing
Most scenario pricing errors trace back to a handful of repeat offenders. Rate drift is the most common: a scenario gets generated against a rate sheet that's already stale by the time it reaches the borrower, because the PPE isn't refreshing frequently enough or isn't pulling from a live feed.
Mislabeling scenarios is another. When "Scenario A" and "Scenario B" don't clearly state what each optimizes for, loan officers end up explaining the difference manually every time, and borrowers sometimes pick based on which number looks smaller without understanding why.
A few more worth watching for:
- Fee misclassification: treating a non-shoppable fee as shoppable (or the reverse) throws off the tolerance calculation before you even get to closing
- Manual re-entry errors: pricing a scenario in one tool, then retyping the numbers into the LOS, introduces transcription mistakes that an integrated platform avoids
- Skipping the revised-GFE documentation: issuing a new disclosure without recording the changed circumstance leaves you exposed if that file gets reviewed later
- Ignoring lock expiration: quoting a scenario against an expired lock without triggering a re-price is one of the fastest ways to create a tolerance violation
Most of these come down to a system that doesn't enforce the checks automatically. Our guide on preventing rate drift in pricing engine setup covers this in more operational depth.
Tools and software brokers rely on for scenario pricing
Brokers generally work with some combination of a standalone PPE, a loan origination system, and a CRM, though the degree of integration between them varies widely. A standalone pricing engine on its own often requires manual data transfer into the LOS once a scenario is selected, which is exactly where transcription errors creep in.
An integrated platform that houses pricing, LOS, and CRM functions together removes that transfer step entirely. Our LOS guide for brokers covers how that integration pattern works in practice, including how pricing data should flow into the file without duplicate entry.
Beyond the core platform, brokers often lean on:
- Lender comparison tools to match overlays and eligibility against borrower profiles before pricing
- Borrower-facing calculators, such as the refinance calculator offered by some brokerages, for quick affordability conversations before a formal scenario is run
- E-signature and document storage tied to the LOS, so disclosures generated from a priced scenario route for signature without leaving the platform
The right combination depends on your volume and your staff's comfort with switching between systems, but every added handoff point is another place for an error to slip in.
How market conditions move your scenario pricing
Rate sheets don't just drift within a day. They respond to broader market conditions that shift the entire pricing grid your PPE pulls from. Bond market movement, Federal Reserve policy decisions, and inflation data all feed into the rates lenders post, and a scenario priced against yesterday's sheet can be meaningfully off once the market moves.
For ARM scenarios specifically, the index your margin is tied to responds to its own set of economic signals, which means an ARM scenario needs more frequent revisiting than a fixed-rate one if market conditions are volatile.
Lender capacity also plays a role that's easy to overlook. When volume surges across the industry, some lenders widen their margins temporarily to manage pipeline, which shows up in your scenario comparisons as a lender suddenly looking less competitive than it did the week before. A PPE that pulls live rate sheets rather than cached ones is the only reliable defense against quoting a scenario that's already stale by the time the borrower sees it.
A founder's view on why connected pricing matters
In twenty years working as a processor, underwriter, and originator, I watched the same failure repeat across brokerages: a pricing tool that didn't talk to the LOS, which meant rate drift, re-keyed data, and disclosures that had to be redone because a fee category didn't match. Every one of those failures was preventable with better system design, not more staff effort.
A broker-first platform fixes this by keeping pricing, disclosure, and audit trail in the same place. That's the priority we built around, and it's covered in more depth in our resources on pricing engine setup and mortgage software cost.
— Omar Khamisa
How 1 Solution brings pricing, LOS, and compliance together
We built 1 Solution Mortgage Software around the exact gap described above: a pricing engine that doesn't live apart from your LOS, your disclosures, or your audit trail. Scenarios you generate flow directly into the file, disclosure templates pull from the same data, and every revision gets logged automatically instead of left for someone to remember later.
What that looks like in practice:
- An integrated product and pricing engine connected to LOS, CRM, and compliance tools in one platform
- Disclosure templates built to map to GFE and TRID table requirements
- Versioned audit logs that timestamp every scenario and every revision
- Onboarding and training support from a team that built this from real brokerage experience, not a boardroom spec
Our Subscription Account gives your team access to this connected stack, with add-on services like phone systems, text messaging, and fax billed per use. If rate drift, re-disclosures, and disconnected tools are costing you time every week, take a look at what an integrated setup can do for your pipeline.
FAQ
What is loan scenario pricing in a broker's workflow?
Loan scenario pricing is the use of a product and pricing engine to generate and compare borrower-ready rate options before producing a disclosure. The output needs to map directly to GFE and TRID fields so the quote and the disclosure match without manual rework.
How quickly must a GFE be provided after application?
A Good Faith Estimate must be provided promptly, generally within a few business days after a lender or broker receives an application or enough information to treat it as one. Missing that window creates compliance exposure regardless of how accurate the pricing itself is.
What triggers a revised GFE?
A revised GFE is generally triggered by a changed circumstance, such as a new lock, a change in loan amount, or a fee that moves outside its allowed tolerance. The reason for the revision has to be documented and retained, since certain charges are capped by a tolerance band that limits certain charges to not exceed their original estimate by more than a small margin under the GFE rules.
Which fields in a disclosure must a pricing engine map correctly?
Under 12 CFR 1026.37, disclosures require separate tables for loan terms, projected payments, and costs at closing, each with specific required fields like interest rate and principal and interest payment. A PPE's output should correspond directly to those tables rather than requiring manual reformatting.
What does 1 Solution charge for its mortgage platform?
Pricing for the Subscription Account is available on request through 1 Solution, while add-on services like phone, text, and fax are billed per use. Contact our team directly for current plan details.