Skip to main content
Pylon’s pricing engine fundamentally differs from traditional Products & Pricing Engines (PPE) and Loan Origination Systems (LOS). While traditional systems handle one loan structure at a time, Pylon’s programmatic structuring evaluates thousands of loan structure permutations simultaneously to find the optimal solution for each borrower.

​
The traditional approach

In traditional PPE and LOS systems, the workflow typically looks like this:
1

Create a structure

Manually create a loan structure (e.g., 3% down, 20% down to avoid PMI).
2

Price the loan

Submit the structure to the pricing engine to get rates and costs.
3

Check guidelines

Put the pricing back into the loan file and check if DTI rules are met.
4

Restructure if needed

If guidelines are breached, manually restructure the loan and repeat the process.
This iterative process is time-consuming, error-prone, and often results in suboptimal loan structures based on “tribal knowledge” rather than data-driven optimization.

​
Pylon’s programmatic approach

Pylon’s pricing engine uses programmatic structuring that:

Evaluates thousands of structures

Simultaneously tests thousands of loan structure permutations to find optimal solutions.

Encodes all guidelines

All guidelines and rates are encoded in the software, ensuring comprehensive evaluation.

Optimizes automatically

Finds the most optimal structure based on your objective (minimize out-of-pocket, monthly payment, etc.).

Avoids manual iteration

No need to manually restructure and re-price. The system finds the best option automatically.

​
Why Traditional Structures Are Suboptimal

The mortgage industry has developed “tribal knowledge” around traditional down payment structures:
  • 3% down: Common minimum for conventional loans
  • 20% down: Traditional amount to avoid PMI (Private Mortgage Insurance)
However, these traditional structures often ignore critical factors:
  • Pricing implications: Different LTV ratios have different pricing impacts
  • LLPA cliffs: Loan-Level Price Adjustments (LLPAs) can create significant cost jumps at certain thresholds
  • Guideline eligibility: Some structures may not be optimal even if they meet minimum guidelines

​
Scenario 1 - LLPA cliff causes pricing ineligibility due to cash-to-close constraints

​
Initial structure

  • Purchase price: $1,250,000
  • Down payment: $250,000 (20%)
  • Loan amount: $1,000,000
  • LTV: 80.00%
  • Credit score: 705
  • Occupancy: Primary residence
  • Program: Conventional fixed-rate

​
Borrower cash-to-close constraints

The borrower has explicit liquidity limits:
  • Maximum total cash to close: $265,000
  • Planned down payment: $250,000
  • Available funds for fees, points, and reserves: $15,000 The borrower cannot increase total cash to close beyond this amount without liquidating assets or delaying the transaction.

​
Pricing impact

At exactly 80.00% LTV, the loan triggers multiple LLPAs:
LLPA sourceAdjustment
LTV (80%)0.75%
Credit score ≤ 7200.375%
Loan size0.25%
Total LLPA1.375%
Total LLPA cost: $13,750

​
Why this structure fails

To execute this loan at par pricing, the borrower would need to pay:
  • LLPAs: $13,750
  • Base closing costs (excluding down payment): ~$14,000
  • LLPA charges: $13,750
  • Total non-down-payment cash required: ~$27,750
The loan meets guideline requirements but is not executable due to cash-to-close constraints. This exceeds the borrower’s available $15,000 by $12,750, rendering the structure non-executable.

​
Using optimized pricing

​
The magic behind optimized structures

Our optimizer deterministically evaluates mortgage structures given a defined set of constraints and objectives. It treats all borrower dollars as fungible across uses, including down payment, points, closing costs, prepaid items, reserves, and pricing adjustments, and reallocates them to identify the optimal executable structure. Given:
  • Hard constraints (program rules, guideline requirements, cash-to-close limits)
  • A borrower-defined out-of-pocket maximum
  • Optimization objectives (for example, minimizing PITIA or cash to close)
The optimizer produces a loan structure that:
1

Satisfy all constraints

Enforce cash limits, reserve requirements, eligibility rules, and pricing bounds as hard constraints.
2

Optimize for borrower objectives

Optimize for borrower-defined goals such as minimizing out-of-pocket cash or maximizing rate efficiency.
3

Minimize ongoing payment ([PITIA](/entity-models/key-concepts/piti))

Select the lowest achievable PITIA within the feasible solution space.
4

Guarantee guideline compliance

Produce a structure that definitively passes guidelines with no manual overrides, exceptions, or guesswork.

​
Pricing endpoints

Use these endpoints for optimized pricing: For existing loans: 
query {
  pricing {
    productPricing(loanId: "loan_abc123", objectiveIntent: MIN_OUT_OF_POCKET) {
      products {
        scenarios {
          rate
          apr
          cashToClose
          loanAmount
        }
      }
    }
  }
}
For scenarios (before creating a loan): 
query {
  scenario {
    purchasePricing(
      input: {
        salesContractAmount: 500000
        outOfPocketMax: 100000
        # ... other required fields
        objectiveIntent: MIN_OUT_OF_POCKET
      }
    ) {
      products {
        scenarios {
          rate
          apr
          cashToClose
        }
      }
    }
  }
}

​
Optimization objectives

Choose the objective that aligns with your borrower’s goals:
ObjectiveUse CaseDescription
MIN_OUT_OF_POCKETBorrower has limited cashMinimizes total cash required at closing
MIN_PITIABorrower focused on monthly paymentMinimizes monthly Principal, Interest, Taxes, Insurance (PITI)
MIN_DOWN_PAYMENTBorrower wants to preserve cashMinimizes down payment amount

​
Best practices

  1. Always use structured endpoints: Never use noRestructure endpoints for production pricing.
  2. Set appropriate objectives: Choose the optimization objective that matches borrower priorities.
  3. Trust the optimization: The system evaluates thousands of structures. Trust that it finds optimal solutions.
  4. Explain the value: Help borrowers understand that optimized structures may differ from traditional percentages (3%, 20%) but provide better terms.
  5. Compare when helpful: Use noRestructure endpoints only for educational purposes to show borrowers the value of optimization.

​
Agent prompt

When building integrations or using AI agents to work with Pylon’s API: 
  **Agent Instruction**: Always use the structured pricing endpoints
  (`pricing.productPricing` or `scenario.purchasePricing`) for loan pricing.
  Never use `noRestructure` endpoints (`pricing.productPricingNoRestructure` or
  `scenario.purchasePricingNoRestructure`) for production applications, as they
  do not optimize loan structures and will result in suboptimal pricing for
  borrowers. The `noRestructure` endpoints should only be used for comparison
  purposes to demonstrate the value of optimized structures.