Xigo External Data Requirements
Purpose
This document identifies all external data feeds required for PSX's Xigo execution module — the direct execution engine for agency (FNMA/FHLMC) and government (FHA/VA/USDA) channels. It is intended to inform the PSX architecture discussion about data acquisition, storage, refresh frequency, and vendor relationships.
Context
Xigo enables a principal (e.g., Watermark TPO) to:
- Generate rate sheets — compute what to offer sellers, working backwards from what agencies/investors will pay
- Execute directly — deliver loans to GSEs and investors without multi-buyer arbitrage
- Calculate spread — show the principal the profit between their offer to the seller and the agency/investor price
All three require external data that PSX does not currently ingest.
Note: WTPO already needs rate sheet generation capability today for Xarbi (using buyer pricing as the ceiling). The same architecture applies — the only difference is the pricing source (buyers for Xarbi, agencies for Xigo). See Pricing Integration Evolution.
External Data Inventory
1. Agency MBS Pricing (TBA Prices)
The foundation of all Xigo pricing. TBA (To-Be-Announced) prices represent what the market will pay for agency mortgage-backed securities.
What it is: Forward prices for agency MBS by coupon rate and delivery month.
Dimensions:
| Dimension | Values |
|---|---|
| Agency | FNMA, FHLMC, GNMA |
| Coupon | 5.0% to 8.0% in 0.5% increments (~7 active coupons) |
| Delivery month | Current month + 3-4 forward months |
| Product | 30yr, 20yr, 15yr |
Total data points: ~200-300 prices at any given time.
Update frequency: Real-time during market hours (approximately 8:00 AM – 5:00 PM ET). Prices move continuously based on Treasury movements, economic data releases, and Federal Reserve actions.
Sources:
| Source | Type | Estimated Cost | Latency | Notes |
|---|---|---|---|---|
| ICE (Intercontinental Exchange) | REST API | $500-1,500/mo | Real-time | Industry standard for TBA pricing |
| Tradeweb | REST API | $500-2,000/mo | Real-time | Major electronic MBS trading platform |
| Bloomberg Terminal + B-PIPE | API | $2,000+/mo | Real-time | Comprehensive but expensive; overkill unless already subscribed |
| Broker-dealer feeds | FIX / proprietary | Relationship-based | Real-time | WTPO's clearing broker may provide feeds as part of the trading relationship |
| Manual entry | PSX UI | Free | Minutes | How many small shops operate — someone watches a screen and types prices. Viable for MVP. |
Critical importance: HIGHEST — this is the base price from which everything else is derived. A 0.25 point error on TBA price = $625 per $250K loan.
MVP approach: Manual entry via PSX UI (principal or ops team enters current TBA prices 1-2 times per day). Upgrade to API feed when volume justifies the cost.
2. Agency LLPA Grids (Loan-Level Price Adjustments)
Multi-dimensional matrices published by Fannie Mae and Freddie Mac that adjust the base TBA price based on loan characteristics.
What it is: A grid showing price adjustments (in points) for each combination of borrower/loan attributes. Example: 720 FICO + 80% LTV + Cash-Out Refi = -1.375 point adjustment.
Dimensions:
| Dimension | Typical Values |
|---|---|
| Credit score (FICO) | <620, 620-639, 640-659, 660-679, 680-699, 700-719, 720-739, 740-759, 760+ |
| LTV | ≤60, 60.01-70, 70.01-75, 75.01-80, 80.01-85, 85.01-90, 90.01-95, 95.01-97 |
| Loan purpose | Purchase, Rate/Term Refi, Cash-Out Refi |
| Property type | SFR, Condo, 2-unit, 3-4 unit, Manufactured |
| Occupancy | Primary, Second home, Investment |
| Other | High balance, subordinate financing, interest-only, etc. |
Total data points: ~500-1,000 cells per agency (FNMA and FHLMC publish separate grids).
Update frequency: Periodic — agencies announce changes weeks in advance. Major updates happen several times per year. Not daily.
Sources:
| Source | Format | Access | Notes |
|---|---|---|---|
| Fannie Mae (fanniemae.com) | Excel + PDF | Free, public | Selling Guide Exhibit — downloadable |
| Freddie Mac (freddiemac.com) | Excel + PDF | Free, public | Seller/Servicer Guide — downloadable |
| GNMA | N/A | N/A | Ginnie Mae does not use LLPAs in the same way — pricing is g-fee driven |
Critical importance: HIGH — LLPAs are often the single largest driver of loan-level price variation. A -2.00 LLPA on a $400K loan is an $8,000 adjustment. Without LLPAs, the rate sheet is dangerously inaccurate for non-pristine loans.
Ingestion approach — target automation:
Weekly automated check:
→ Download Excel from known FNMA/FHLMC URL
→ Hash file and compare to last ingested version
→ If changed:
→ AI extraction parses grid into stacking engine format
→ Store as new version (is_current = TRUE, old → FALSE)
→ Notify Admin: "FNMA LLPA grid updated, effective [date]"
→ If unchanged:
→ Do nothing
Agency LLPAs are managed at the platform level by Admin (or automated system), not by principals. Stored as extracted_profiles with participant_type = 'agency' and buyer_id = "FNMA" / "FHLMC". All principals automatically see updated agency pricing in Xigo calculations.
The known URL is the only fragile point — if the agency reorganizes their website, Admin updates the URL once. This is rare (these are major industry reference documents with stable locations).
Fallback: Admin manually uploads the Excel file if automation fails.
3. Guarantee Fee (G-Fee) Schedules and BUBD Grids
The ongoing fee paid to the agency for the MBS guarantee. Can be traded via buy-up/buy-down to optimize the security coupon.
What it is:
- Base g-fee: The annual fee the principal pays the agency (e.g., 50bps/year). This is negotiated per seller and is private.
- BUBD grid: A schedule showing how much coupon adjustment results from paying more or less g-fee. Published by the agencies.
Dimensions:
| Dimension | Values |
|---|---|
| Product | CONV, FHA, VA, USDA |
| Term | 10, 15, 20, 25, 30 year |
| Coupon rate | 4.0% to 8.0% in 0.125% increments |
| Buy-up/Buy-down ratio | Varies by commitment |
Update frequency:
| Component | Frequency |
|---|---|
| Base g-fee | Changes when WTPO renegotiates with the agency (annually or less) |
| BUBD grid structure | Published by agencies, updates periodically |
| BUBD ratios | Changes with market conditions and commitment terms |
Sources:
| Source | Format | Access | Notes |
|---|---|---|---|
| FNMA BUBD grid | Excel | Published, downloadable | Grid structure is public; actual g-fee base is seller-specific |
| FHLMC BUBD grid | Excel / XML | Published, downloadable | Same — public structure, private base fee |
| WTPO's commitment terms | Internal document | Private | The negotiated g-fee — WTPO provides this |
Critical importance: MEDIUM-HIGH — g-fee affects the pass-through rate, which determines which TBA coupon the loan maps to, which drives the base price. Getting this wrong can shift the loan to a different coupon bracket.
Ingestion approach: BUBD grids are the same format the Desktop App's BUBD Grid Converter plugin parses today. PSX can reuse the same grid structure. Base g-fee is a configuration value per principal per agency commitment.
4. Servicing Values / MSR Pricing
The value of the mortgage servicing right (MSR). Relevant when the principal retains servicing or when evaluating servicing-released vs. servicing-retained execution.
What it is: The present value of the future income stream from servicing a mortgage (collecting payments, managing escrow, etc.).
Dimensions: Product × Coupon × Weighted Average Remaining Term × Credit Quality Tier
Update frequency: Daily — MSR values move with interest rates (higher rates = higher MSR value, generally).
Sources:
| Source | Type | Cost | Notes |
|---|---|---|---|
| MIAC Analytics | Subscription / API | $$ | Major MSR valuation service |
| Phoenix Capital | Bid lists | Relationship | MSR broker providing market bids |
| Internal model | Calculated | Free | Based on prepayment speeds, discount rates, cost-to-service |
| SRP schedules | Contractual | Free | If selling servicing, the SRP is defined in the commitment terms |
Critical importance: MEDIUM — affects total economics and the sell-servicing vs. retain-servicing decision. For rate sheet generation, a reasonable assumption (e.g., 1.0x multiple) is sufficient for MVP. Precise MSR valuation matters more at execution time.
MVP approach: Configurable MSR assumption per product (entered by principal). Upgrade to market feed when the principal's servicing portfolio is large enough to warrant precision.
5. Treasury Yields and Market Indices
Benchmark interest rates used for hedging calculations, ARM product pricing, and spread analysis.
Key rates:
| Rate | Use in Xigo |
|---|---|
| 10-year Treasury | Primary driver of mortgage rates; hedge reference |
| 2-year Treasury | Short-duration hedge benchmark |
| 5-year Treasury | Intermediate hedge benchmark; ARM reference |
| 30-year Treasury | Long-duration reference |
| SOFR (Secured Overnight Financing Rate) | ARM index rate (replaced LIBOR) |
| Swap rates (5yr, 7yr, 10yr) | ARM pricing, hedging curve construction |
Update frequency: Real-time during market hours.
Sources:
| Source | Type | Cost | Latency | Notes |
|---|---|---|---|---|
| Treasury.gov | CSV download | Free | End of day | Official yields, 1 day delayed |
| FRED (Federal Reserve) | REST API | Free | End of day | St. Louis Fed Economic Data |
| ICE / Bloomberg | API | $$-$$$$ | Real-time | Same vendor as TBA prices |
| Yahoo Finance / public APIs | API | Free | 15-min delay | Sufficient for daily rate sheet generation |
Critical importance: HIGH for hedging (PSSaaS Risk Manager), MEDIUM for rate sheet generation (indirect — Treasury movements drive TBA prices, but the TBA price itself is what matters for the rate sheet).
MVP approach: End-of-day Treasury yields from FRED (free API). Upgrade to real-time when hedging operations require it.
6. Conforming Loan Limits
Maximum loan amounts for agency-eligible loans. Determines whether a loan is conforming, high-balance, or jumbo.
What it is: Per-county maximum loan amounts published annually by FHFA.
Dimensions: County FIPS code × Unit count (1-4) × Baseline vs. High-Cost
Update frequency: Annually — FHFA announces in November, effective January 1.
Data points: ~3,200 counties × 4 unit types = ~12,800 rows.
Source: FHFA.gov — published as a downloadable Excel/CSV file. Free, public.
Critical importance: LOW frequency, HIGH impact — wrong limits = wrong product classification = wrong coupon mapping = wrong price. But it only changes once per year.
Status: PSX already has conforming_limits_2026.py with this data. Update annually.
7. Agency Eligibility Rules
Rules that determine whether a specific loan can be sold to FNMA, FHLMC, or GNMA (via FHA/VA/USDA).
What it is: Business rules covering maximum DTI, minimum credit scores, property eligibility, AUS requirements, documentation standards, seasoning requirements, etc.
Update frequency: Periodic — Selling Guide updates happen monthly to quarterly. Major changes (like new DTI limits or credit score floors) are announced in advance.
Sources:
| Source | Content | Format |
|---|---|---|
| FNMA Selling Guide | FNMA eligibility rules | Online + PDF (thousands of pages) |
| FHLMC Seller/Servicer Guide | FHLMC eligibility rules | Online + PDF |
| HUD Handbook 4000.1 | FHA eligibility | Online + PDF |
| VA Lender's Handbook | VA eligibility | Online + PDF |
Critical importance: MEDIUM for rate sheet generation (determines which products to publish — no point offering VA pricing if the loan isn't VA-eligible), HIGH for execution (agencies will reject ineligible loans).
Ingestion approach: This is the hardest data to systematize. Rules are narrative, interpretive, and interconnected. For MVP, the principal configures basic eligibility filters (min FICO, max LTV, eligible property types per product). Full rule engine is a long-term capability.
Minimum Viable Xigo Data Set
For generating WTPO's first rate sheet from PSX:
| Data | Required? | Source | Acquisition |
|---|---|---|---|
| TBA Prices | YES | Manual entry (MVP) → API feed (scale) | Principal enters current prices in PSX UI |
| Agency LLPAs | YES | FNMA/FHLMC published Excel files | AI extraction (PSX already has this capability) |
| G-Fee / Base | YES | WTPO provides their negotiated g-fee | Configuration value in PSX |
| BUBD Grid | YES (for coupon optimization) | FNMA/FHLMC published Excel files | Same extraction approach as LLPAs |
| Conforming Limits | YES | FHFA.gov | Already in PSX |
| Principal's margin | YES | WTPO defines their desired spread | Configuration value in PSX |
NOT required for MVP: MSR pricing (use assumption), real-time Treasuries (TBA prices are sufficient), full eligibility rules (basic filters only), real-time TBA feed (manual entry works for 1-2 updates/day).
Architecture Questions and SA Answers
Questions posed to the PSX Software Architect. Answers received 2026-04-02.
Q1: Where does this data land?
Answer: Dedicated tables in PSX Postgres — market_pricing for TBA prices, reuse extracted_profiles + stacking engine grid model for agency LLPAs. Redis cache for hot-path access during rate sheet generation. NOT shared with PSSaaS via database — PSSaaS gets pricing via the ephemeral API endpoint.
Q2: How does the TBA price feed work?
Answer: Manual entry UI for MVP — a simple grid: Agency × Coupon × Delivery Month. Principal enters prices 1-2x daily. API feed (ICE or broker-dealer) as a Phase 2 upgrade. Feed goes directly to PSX, not through a shared service.
Q3: How are LLPA grids stored?
Answer: Yes, agency LLPAs can use the same stacking engine grid model as buyer LLPAs. They're structurally simpler (fewer dimensions, publicly defined). The extracted_profiles schema already supports multi-dimensional grids with named dimensions. Agency LLPAs would be stored as profiles with buyer_id = "FNMA" or "FHLMC".
PSSaaS architect note: This is the most important answer. The stacking engine doesn't care whether it's evaluating PennyMac's LLPAs or Fannie Mae's. No new infrastructure — just a new "buyer" that happens to be an agency.
Q4: Version control and effective dates?
Answer: Yes, keep old versions (is_current = FALSE, Invariant #6). Effective date on each version. Transition: new version becomes active at its effective date; old version stays for historical pricing queries and audit.
Q5: Who enters/maintains this data?
Answer:
| Data | Maintained By | Frequency |
|---|---|---|
| TBA prices | Principal or ops team | Daily (1-2x) |
| Agency LLPAs | AI extraction from published Excel files | Periodic (agency announces changes in advance) |
| G-fee | Principal provides their negotiated rate | Rarely changes |
| Conforming limits | Annual FHFA update | Already in PSX |
Q6: Staleness detection?
Answer: Yes. Each data type has a max acceptable age:
| Data | Warn At | Block At |
|---|---|---|
| TBA prices | 4 hours | 8 hours (block rate sheet generation) |
| Agency LLPAs | 30 days past effective date | — |
| G-fee / conforming limits | Annually | — |
UI shows a freshness indicator on each data source.
Q7: Xarbi + Xigo shared infrastructure?
Answer: Yes. Xarbi and Xigo share the stacking engine. The math is identical: base_price + sum(LLPA_adjustments) + SRP. The only difference is the pricing source — buyer rate sheets (Xarbi) vs. TBA + agency LLPAs (Xigo). The stacking engine is source-agnostic; it evaluates whatever extracted_profiles are loaded for the specified counterparty. Agency profiles would use buyer_id = "FNMA"/"FHLMC" and follow the same grid/layer model.
PSSaaS architect note: This confirms that Xigo is not a separate engine — it's Xarbi with different counterparties. This dramatically reduces Xigo build scope from "new execution module" to "new data sources + new output format."
Rate Sheet Generator (Near-Term Priority)
The SA confirmed that WTPO rate sheet generation is achievable now using existing infrastructure:
The generator inverts the bid request flow: for each rate/FICO/LTV/product combination, compute
max(buyer_prices) - principal_margin = offer_to_seller_price. PSX already has all the inputs — buyer extracted profiles, stacking engine, LLPA evaluation. The output is a rate sheet in the format WTPO currently gets from OptimalBlue. This eliminates an external dependency and a manual process. It uses the same stacking engine — no new pricing logic needed, just a new output format that iterates over a grid of loan characteristics instead of pricing individual loans.
Follow-Up: Where Does WTPO's Generated Rate Sheet Live?
Resolved (2026-04-02). The SA confirmed it goes through PSX's existing infrastructure:
WTPO's generated rate sheet becomes a buyer profile stored as an
extracted_profilewithbuyer_id = "watermark-tpo". No separate artifact. No PDF/Excel. The rate sheet lives in PSX.
How this works:
WTPO is already a PSX participant with the role "principal." The rate sheet they publish to sellers IS their buy-side pricing — what they'll pay to acquire loans. That's functionally identical to what Citi or Truist publish. Storing it as an extracted_profile means:
-
Sellers see WTPO alongside other buyers. Sellers upload tapes → PSX prices against ALL buyers including WTPO. The seller gets the best price, and WTPO competes transparently.
-
WTPO sees their spread in real time. Their offer-to-seller price is visible alongside what their buyers (Citi, Truist, AmeriHome) will pay. The spread =
buyer_price - wtpo_offer_priceper loan. This is the Xarbi arbitrage calculation made visible. -
No new infrastructure.
buyer_id = "watermark-tpo"inextracted_profilesmakes WTPO's rate sheet a first-class participant in the pricing engine. The rate sheet generator produces the profile instead of extracting it from a file. -
Validation gates apply. WTPO's generated rate sheet goes through the same extraction/validation path as any buyer. First generation gets
PENDING_VALIDATION. Subsequent regenerations with the same structure auto-validate.
The dual-role nuance:
WTPO is both the rate sheet publisher (acting as a "buyer" from the seller's perspective) AND the principal who executes against actual buyers. The principal portal needs two views:
| View | Data Source | Shows |
|---|---|---|
| "What am I offering sellers?" | buyer_id = "watermark-tpo" profile | WTPO's generated prices |
| "What can I sell for?" | Buyer profiles (Citi, Truist, etc.) | Buyer prices per loan |
| "What's my spread?" | Difference between the two | Profit per loan |
This is a UX concern (three columns in a table), not an infrastructure concern.
Follow-Up: Principal vs. Buyer Data Model (2026-04-02)
Problem identified by PSX SA: Storing WTPO's rate sheet as buyer_id = "watermark-tpo" alongside actual buyers (Citi, Truist, AmeriHome) creates a domain model problem. WTPO is the intermediary, not a competing buyer. Including WTPO in buyer best-ex calculations would be wrong. ADR-002 (blind-until-done) is also violated if sellers see "watermark-tpo" as a bidder.
Resolution: Option B (near-term) → Option C (long-term)
Option B (now): Add a participant_type role column to extracted_profiles (buyer vs. principal). The pricing engine filters by role:
- Buyer profiles (
participant_type = 'buyer'): compete in best-ex ranking. Sellers see anonymous results from these. - Principal profiles (
participant_type = 'principal'): excluded from best-ex. Used for spread analysis and seller-facing offer display only.
This solves ADR-002: sellers don't see "watermark-tpo" in best-ex results. The seller sees "N interested buyers at these price levels" (anonymous). WTPO's offer is shown separately as the principal's price.
Option C (production end state): The rate sheet generator produces WTPO's pricing dynamically from buyer data + margin configuration. No static principal rate sheet to ingest — it's computed on demand.
WTPO Rate Sheet Generator: Reference-Based Pricing
Key discovery: WTPO pegs their pricing to AmeriHome and a few other large aggregators, not to the best-of-all-buyers. This simplifies the generator from a multi-buyer optimization to a reference-plus-margin calculation:
for each product/rate/lock combo:
reference_price = get_price("amerihome", product, rate, lock)
wtpo_offer = reference_price - margin_config[product]
Principal rate sheet configuration:
{
"principal_id": "watermark-tpo",
"reference_buyers": ["amerihome"],
"margin_config": {
"CONV30": { "margin_bps": 25, "min_price": 99.0 },
"CONV15": { "margin_bps": 20, "min_price": 99.5 },
"FHA30": { "margin_bps": 30, "min_price": 98.5 }
}
}
Scaling: When WTPO wants to peg to multiple references (e.g., "best of AmeriHome and PennyMac minus margin"), the config expands to a list and the generator takes max(reference_prices) - margin. Start with single-reference — that's what WTPO does today.
Implications:
- WTPO doesn't need ALL buyer rate sheets loaded to generate their pricing — just their reference buyer(s)
- Fewer dependencies = faster rate sheet generation
- The rate sheet regenerates whenever the reference buyer's rate sheet updates or when WTPO adjusts their margin