LOs see what matters, not what's possible
Hiding 60% of irrelevant fields cuts cognitive load and turnaround time. DSCR loans don't pretend to need W-2s; investment properties don't ask about primary residence intent.
Capability · Smart 1003
A 1003 that knows what fields actually matter for this loan.
Declarative field-visibility engine that hides the 60% of 1003 fields irrelevant to the loan profile, documentation mode, property class, and occupancy. Amber-pulse on required fields, collapsible 'Show more' for optionals, auto-clear when a driver field changes.
Overview
What it is, in one paragraph
The Smart 1003 is a declarative relevance engine over URLA fields. Each field has a rule: which combinations of loan type, doc mode, property class, occupancy, and borrower count make it required, optional, or irrelevant. The portal renders only the relevant fields; required-but-empty fields amber-pulse; optional fields collapse into 'Show more.' Changing a driver field (e.g., switching from FULL_DOC to DSCR) auto-clears now-irrelevant values with an audit row capturing the cleared field set. Result: LOs see roughly the 40% of fields that matter for their loan, not all 100+.
Declarative relevance rules
Every URLA field carries its own relevance predicate. No imperative conditional UI — the rules are data and inspect-able via API.
Amber-pulse required-but-empty
Required fields that are still empty pulse amber on the form. The LO sees what's blocking submit at a glance.
Collapsible 'Show more' optionals
Optional fields hide by default; one click reveals them per section. Cognitive load drops without losing access to the long tail.
Auto-clear on driver change
Switching loan type or doc mode auto-clears now-irrelevant values. Audit captures the cleared fields so QC can reconstruct intent.
URLA 2021 Tier 5 complete
Tiers 1–5 fully shipped. Multi-borrower namespace (borrowers[0..N]). 2021 marital status and income type enums.
Integrator-friendly
The relevance map is exposed via API. Build your own field-visibility in your CRM or LOS using the same rules the portal does.
How it works
The pipeline, end to end.
Numbered steps from input to output. Each step maps to a specific subsystem you can inspect via OpenTelemetry.
- 1
Define the loan profile
Each field's rule is keyed to loanType, documentationType, occupancy, propertyClass, and borrowerCount. Profile lives on the loan; updates flow through.
- 2
Resolve relevance per section
For each URLA section, the engine resolves which fields are required, optional, or irrelevant for the current profile. Result is a structured relevance map.
- 3
Portal renders the map
Required-and-empty fields amber-pulse. Required-and-filled fields green-tick. Optional fields collapse under 'Show more.' Irrelevant fields render only in QC mode.
- 4
Driver-change auto-clear
When the LO changes loanType or documentationType, the engine identifies fields that became irrelevant and clears them — with an audit row capturing the prior values.
- 5
QC mode opens everything
Compliance and QC reviewers can toggle the relevance gate off. Every field renders for full audit visibility.
- 6
Submit only when required-fields are green
The form prevents submit while any required field is empty. The amber-pulse + section-summary makes it visually obvious where the LO needs to act.
Hands on
Fetch the relevance map for a loan profile
Live cURL sample — copy, paste, ship.
# Inspect which fields are relevant for a given loan profile
curl -X POST https://api.ratestack.com/v1/loans/relevance \
-H "X-API-Key: $RATESTACK_KEY" \
-H "Content-Type: application/json" \
-d '{
"loanType": "DSCR",
"documentationType": "DSCR",
"occupancy": "INVESTMENT",
"propertyClass": "INVESTOR",
"borrowerCount": 1
}'
# Returns the relevance map — required, optional, and irrelevant per section.
# The portal renders the same map; this endpoint exists so integrators can mirror
# the field-visibility logic in their own surfaces.Why this matters
The pain it removes.
QC keeps the full surface
Reviewers toggle QC mode and see everything. The relevance gate is a UX layer, not a data-suppression layer.
Audit captures the cleared trail
When a driver change clears fields, the audit row records what was cleared. Reconstruction is straightforward; nothing disappears silently.
Frequently asked
Direct answers, no marketing spin.
What if the LO needs a field that's marked irrelevant?
QC mode unhides everything for authorized users; or change the loan profile (which usually means the loan really is a different type than the form thought). The rule set is exposed and editable on Enterprise.
Does this support non-QM scenarios (DSCR, bank statement, asset)?
Yes. DocumentationType expanded to 40+ values including DSCR, BANK_STMT, ASSET, ITIN, NO_DOC, STREAMLINE. Each carries its own relevance rules.
What's the multi-borrower model?
borrowers[0..N], where index 0 is the primary 'Borrower' and the rest are co-borrowers — all carrying identical field shapes. Aliasing collapsed into the unified namespace.
Can we run this on top of our existing LOS?
Yes. Use the relevance API in your CRM or LOS to surface RateStack's field-visibility logic without adopting the portal — useful for partner channels under white-label.
Does relevance affect downstream pricing?
Irrelevant fields are excluded from the pricing input. Eligibility predicates are written against the profile they expect; hiding a field is also semantically clearing it.
Related capabilities
Pieces that work better together.
Ready to see it on your data?
Wire a 1003 that knows what fields actually matter for this loan. up to your real workflow.
We'll spin you a sandbox, load your actual ratesheets, and walk you through this capability against your top scenarios.