Pricing Integration Evolution
Overview
This document traces how pricing data flows through the PowerSeller ecosystem today and how it evolves as PSX (PowerSeller X) matures. The end state is PSX as the universal pricing engine for all counterparties — buyers AND agencies — with PSSaaS providing the hedging, risk management, and post-execution operations layer.
The Problem
The Desktop App's Risk Manager needs loan-level pricing to compute accurate hedge ratios. Today it gets instrument-level pricing — one price per coupon rate per delivery window from DDE feeds and rate sheet plugins. But the actual value of a loan depends on loan-level adjustments (LLPAs, SRPs, overlays) that vary by credit score, LTV, purpose, property type, and dozens of other factors. A 680 FICO loan and a 780 FICO loan with the same coupon rate have very different values to an investor. Without loan-level pricing, the hedge position is approximate.
PSX solves this — its stacking engine decomposes rate sheets into base price + LLPA layers and evaluates them per-loan. Getting that data into Risk Manager would significantly improve hedge accuracy.
Three Phases
Phase 1: Current State (Desktop App Only)
Pricing sources:
- DDE feeds from Thomson Reuters/Refinitiv (real-time TBA prices)
- 26 rate sheet plugins (investor-specific Excel/XML parsers)
- Manual price entry
- BUBD Grid Converter (agency buy-up/buy-down fee schedules)
What Risk Manager gets:
- Instrument-level prices in
rmcat_todays_prices(base price by coupon rate × delivery window) - Feature adjustments from
rmcat_price_adjustments/rmcat_price_adjustment_values(partially loan-level, but limited) - No decomposed LLPA data
Limitation: Prices are per-instrument, not per-loan. Two loans with different credit profiles going to the same instrument get the same base price in Risk analysis. The actual investor would pay different amounts based on LLPAs, but Risk doesn't see that difference.
Phase 2: PSX Buyer Pricing (Near-Term)
What changes: PSX already ingests and decomposes buyer rate sheets (AmeriHome, PennyMac, Citizens, Truist, etc.) with full LLPA stacking. The Desktop App team wants to send loan data to PSX and get back loan-level adjusted prices.
Integration approach:
Data contract — Request (Desktop App → PSX):
Fields from rmcat_loan and loan tables:
| Field | Purpose |
|---|---|
loan_id | Identity |
loan_amount | Position sizing, fee calculations |
note_rate | Base rate for pricing |
instrument_name | Maps to investor/product |
state | Geographic LLPA dimension |
ltv | LLPA dimension |
credit_score | LLPA dimension (biggest pricing driver) |
purpose_code | LLPA dimension (purchase vs refi) |
occupancy_code | LLPA dimension |
property_type | LLPA dimension |
amort_type | Product eligibility |
num_of_units | LLPA dimension |
product_code | Product matching |
lock_expiration_date | Delivery window determination |
Plus Risk-specific parameters:
| Parameter | Purpose |
|---|---|
investor_id or buyer_id | Which counterparty to price against |
rate_shifts | Array of rate scenarios (e.g., [-0.50, 0, +0.50]) for DPC calculation |
pricing_window_days | Delivery window to use |
Data contract — Response (PSX → Desktop App):
Per loan, per rate scenario:
| Field | Purpose in Risk |
|---|---|
loan_id | Match back to rmcat_loan |
rate_scenario | Which shift (e.g., -0.50, 0, +0.50) |
base_price | Pre-adjustment price |
llpa_total | Sum of all LLPA adjustments |
srp | Service release premium |
net_price | base_price + llpa_total + srp |
price_adjustment | Combined adjustment (for rmcat_loan.price_adjustment) |
rate_adjustment | Rate-based adjustment (for rmcat_loan.rate_adjustment) |
fee_adjustment | Fee-based adjustment (for rmcat_loan.fee_adjustment) |
pass_thru_rate | Computed coupon rate |
servicing_fee | Servicing fee used |
guarantee_fee | Guarantee fee used |
Multi-rate response is critical. Risk Manager runs three scenarios (current, rate-up, rate-down). DPCs are computed as:
lr_dpc = (price_at_lower_rate - price_at_current) / rate_shift
hr_dpc = (price_at_current - price_at_higher_rate) / rate_shift
These drive hedge ratio calculations — how many futures/options to offset the pipeline's rate sensitivity.
Key design constraint: Loans must be ephemeral — PSX processes them in memory and never persists them. The Desktop App's loan data must not enter the PSX database. This is the same pattern as the PSSaaS BestEx integration (ADR-019).
What PSX needs to build:
- Ephemeral pricing endpoint that accepts loans without persisting them
- Multi-rate-scenario support (price at N rate levels per loan)
- Investor/buyer specification parameter (which rate sheets to evaluate against)
What the Desktop App needs:
- PSSaaS Connector Plugin (or direct PSX plugin) that marshals loan data, calls the API, and writes results to
rmcat_loan - Profile-to-investor mapping (which Desktop App profile maps to which PSX buyer)
Phase 3: Xigo — Universal Pricing (Future)
What changes: PSX adds the Xigo execution module — direct execution for agency (FNMA/FHLMC) and government (FHA/VA/USDA) channels. This means PSX ingests:
- Agency LLPA grids (publicly published by FNMA and FHLMC — e.g., LLPA matrices by credit score × LTV × loan purpose)
- TBA prices (agency mortgage-backed securities prices — currently from DDE feeds)
- Guarantee fee schedules (currently from BUBD Grid Converter plugin)
- Commitment pricing (investor-specific pricing tied to master agreements)
At this point, PSX has pricing data for ALL counterparties — marketplace buyers (Xarbi) AND agencies/investors (Xigo). The Desktop App's DDE feeds, rate sheet plugins, and BUBD Grid Converter become redundant.
Impact on Risk Manager:
Risk Manager draws ALL pricing from PSX:
- Buyer prices (Xarbi data) — already available in Phase 2
- Agency prices (Xigo data) — replaces DDE feeds and plugins
- Loan-level adjustments for everything — unified LLPA evaluation
The hedge calculation becomes more accurate because every position — pipeline loans, agency commitments, and marketplace trades — is priced through the same engine with the same granularity.
Impact on the Desktop App:
- Rate sheet plugins (26 PBLs) → retired
- DDE feeds → retired (PSX ingests prices via API instead)
- BUBD Grid Converter → retired (PSX ingests agency fee grids)
pscat_inst_dde_links_multi→ populated by PSX instead of pluginsrmcat_todays_prices→ populated by PSX instead of the pricing module
The Desktop App becomes a UI shell that reads prices from PSX and manages trades/pools/risk. All pricing intelligence lives in PSX.
What This Means for PSSaaS
PSSaaS sits in this evolution as:
-
Phase 2: The Connector Plugin could route through PSSaaS (PSSaaS calls PSX, returns results) or go directly Desktop App → PSX. Either works.
-
Phase 3 (Xigo era): PSSaaS BestEx draws pricing from PSX instead of maintaining its own price tables. PSSaaS becomes the operations and hedging layer — it manages what to DO with the prices (which investor to deliver to, when to hedge, how to pool), while PSX manages the prices themselves.
-
Full replacement: When both PSX and PSSaaS are mature, the Desktop App retires. PSX handles all pricing and execution routing. PSSaaS handles pipeline, trading, pooling, risk, settlement. Together they cover everything the Desktop App does today — plus capabilities the Desktop App can't offer (AI ingestion, CRA at scale, loan-level LLPA stacking, cloud-native execution).
Open Questions
| Question | Owner | Status |
|---|---|---|
| Does PSX need an ephemeral pricing endpoint, or can What-if Pricing be extended? | PSX architect | Exploratory |
| Which buyer rate sheets should be available for Risk Manager pricing? | Greg + Desktop dev team | Not started |
| How does Profile → Buyer mapping work? (Desktop App profiles use instruments; PSX uses buyer IDs) | Desktop dev team + PSX | Not started |
| When does Xigo development start? | Product Owner | Depends on WTPO capital readiness |
| Should agency LLPA grids be ingested by PSX, PSSaaS, or both? | Product Owner + architects | Not started |
| Can the existing PSSaaS Connector Plugin concept serve this need, or is a direct PSX plugin simpler? | CTO | Exploratory |
Dependencies
| Dependency | Product | Status |
|---|---|---|
| PSX ephemeral pricing endpoint | PSX | Not built |
| Multi-rate-scenario pricing support | PSX | Not built |
| PSSaaS Connector Plugin (or direct PSX plugin) | Desktop App | Concept documented |
| Agency LLPA grid ingestion | PSX (Xigo) | Not started |
| Xigo execution module | PSX | Not started — awaiting WTPO readiness |
| Greg validates Risk Manager pricing needs | Risk Manager | Not started |