The industry conversation about UAD 3.6 has been dominated by two topics: the November 2, 2026, mandate date, and whether appraisal software vendors are ready to produce the new URAR. Both matter and neither is where most lenders will actually feel the transition challenging.
The real operational exposure is upstream in how appraisal orders are defined, structured, routed, and version-controlled before an appraiser ever touches a file. If you get that bit wrong, no amount of software readiness downstream will save you from a pipeline full of mis-routed assignments, upload failures, and version mismatches that can’t be unwound. Get it right, and UAD 3.6 becomes something your operations team absorbs methodically instead of scrambling through.
This article is about getting it right. It lays out the order management framework that production-grade UAD 3.6 readiness requires; drawn from what we’ve learned building and running this in live pipelines. It maps the execution steps lenders and AMCs should be working through now.
For a side-by-side readiness checklist tied to this framework, we suggest referring to our Lender Readiness Checklist.
Why Your Order Management Layer Can’t Wait
Under UAD 2.6, the appraisal order is a relatively simple object. A product code (1004, 1073, 1025) drives everything downstream: the form the appraiser fills out, the file format they deliver, the rules that QC applies, and how the package gets submitted to UCDP. The product code is the source of truth, and operations teams have built years of workflow logic around it.
UAD 3.6 makes that model obsolete at the source. The GSEs have replaced form-driven ordering with a data-first model. Instead of a product code, the order is now defined by a structured set of assignment attributes: property type, loan type, valuation method, report type, construction, unit counts. Those attributes determine the report’s shape, the delivery format, and the applicable validation rules. There is no form number anymore.
The operational consequence follows directly – every piece of downstream logic that reads a product code to make a decision needs to be rebuilt or mapped to read attributes instead. That includes routing, upload validation, QC rule selection, UCDP submission logic, and delivery configuration.
There is a second consequence that amplifies the stakes. Unlike UAD 2.6, where a report could be revised and resubmitted relatively freely, a completed UAD 3.6 report cannot be converted to UAD 2.6, and vice versa. The two versions share roughly 6% of data fields. A mis-routed order sent to a 3.6-ready appraiser when the receiving system isn’t ready or sent to a 2.6-only appraiser when the lender is already on 3.6 cannot be recovered without starting over. At low volume, that’s an operational nuisance, but at scale, it’s a material failure that compounds through your pipeline.
This is why order management must be solved first before production volume picks up. Here’s a framework of what that solution looks like.
The 5-Step UAD 3.6 Order Management Framework
The framework consists of minimal structural requirements for lenders and AMCs to process UAD 3.6 orders reliably through a dual-version production environment, which is exactly where the industry is right now.
1. Replace Product Codes with an Attribute Model at Intake
The most foundational change in UAD 3.6 order management is treating the order as a dataset rather than a product selection. Every order must capture and carry a defined set of UAD-aligned attributes as structured, system-readable fields:
- Property type: SFR, condo, 2–4 unit, manufactured housing, co-op
- Property valuation method: traditional, desktop, hybrid, exterior-only
- UAD report type: URAR, Completion Report, Appraisal Update Report
- Construction type: site-built, manufactured, modular
- Living unit count and ADU count
- Loan Type
This does not require abandoning existing internal product codes. The right architecture keeps product codes as an internal mapping layer – your fee tables, SLAs, and business rules continue to operate against them – while shifting the order definition to the attribute set. Attributes become the source of truth and products become derived from attributes, not the other way around.
To practically implement this, start by documenting every path through which orders enter your system today – LOS integrations, direct portals, bulk imports, order duplication, internal resubmissions. For each one, confirm whether it can capture the full UAD attribute set as structured fields. Any path that can’t is a gap with a deadline. Then, at a policy level, agree on how your organization will represent the attribute combinations you’ll use in production and map those to your existing internal product codes, fee tables, and SLAs.
2. Make UAD Version a System-Enforced Field, Not a Manual Decision
During the transition window, now through November 2, 2026, lenders will be running 2.6 and 3.6 orders simultaneously. The only way to manage that dual environment without constant manual intervention is to make the version a structured, system-enforced field on every order:
- UAD 2.6 only
- UAD 3.6 only
- Supports both
This is a required, structured attribute that every system in the chain reads automatically to determine routing eligibility, upload format enforcement, QC rule selection, and UCDP submission behavior. The delivery format stakes are concrete: UAD 2.6 deliveries continue as XML with embedded PDF. UAD 3.6 deliveries are ZIP files containing the MISMO XML 3.6 data, a rendered PDF, and a dedicated Images folder with a maximum UCDP submission size of 60MB. Upload logic must enforce the correct format by version and reject mismatches at intake only, not at submission, since discovering a format error at UCDP is the expensive version of this problem.
One operational detail worth building into your tracking infrastructure: the GSEs have confirmed that UAD 3.6 ZIP submissions carry Document File IDs beginning with “2”, while UAD 2.6 IDs begin with “1.” Operations teams managing mixed pipelines should use this distinction in their exception monitoring and SSR reconciliation processes.
3. Build a Version-Aware Vendor Routing Layer
Before you configure routing logic, there’s a harder dependency to confirm – has your LOS completed ULDD Phase 5 implementation? If it hasn’t, UAD 3.6 orders can’t flow through to compliant delivery regardless of how well everything else is set up. Confirm it with your LOS provider first, and if it isn’t complete, it becomes the first item in your implementation sequence.
Once that’s settled, your appraiser panel now has a UAD version dimension it didn’t have before. During the transition, every vendor falls into one of three buckets:
- Appraisers capable of UAD 2.6 only
- Appraisers fully ready for UAD 3.6 (verified software, training, and demonstrated delivery capability)
- Appraisers who can support both versions
This readiness state must live as structured data on each vendor record; not in a spreadsheet, a comment field, or a tag you informally check before assignment. It needs to be a binary, system-readable attribute that assignment logic reads and enforces automatically across every routing method: manual assignment, broadcast, quote workflow, and auto-assignment.
What you can do is define your criteria for 3.6 readiness. At minimum: confirmed software from a GSE-verified vendor, completed training, and delivery of at least one sample ZIP that passes validation is required. Store the result as a binary field on each vendor record and ensure all assignment methods read it automatically.
For AMCs especially, map your 3.6 coverage by geography before scaling volume in any market. Gaps in 3.6 coverage are invisible in existing panel reporting unless readiness is a structured field; build that visibility before volume scales, not after.
One thing to note here is that if a 3.6 order routed to a 2.6-only appraiser produces a report in the wrong format, the order must be restarted from scratch considering the reports cannot be converted between versions after completion. Your operations team loses the turn time, potentially the fee, and certainly the goodwill.
4. Lock Version-Specific QC and Client Delivery Configurations at the Order Level
The version indicator set at intake is what determines which QC behavior fires when the report arrives. UAD 3.6 carries a significantly different and substantially larger validation rule set than 2.6 covering data completeness, format validity, field interdependencies, and submission requirements. A QC engine applying 2.6 rules to a 3.6 report produces incorrect findings in both directions: it will flag things that aren’t issues and miss things that are.
QC must be version-specific. There should be separate rule sets for each standard, tied to client profile so the correct checklist runs automatically on receipt, without manual selection per file. Delivery configuration follows the same logic. Different lender clients will have different intake preferences for 3.6 files: full ZIP, XML only, PDF plus SSR, or a combination. These preferences belong at the client level as a stored configuration, applied automatically when a report is marked complete.
Here’s how you should go about it: build and configure your separate 2.6 and 3.6 QC rule sets, and tie default checklists to client profiles by version. Any changes made mid-pipeline create exactly the kind of inconsistency that generates exceptions at scale so you must lock client-level delivery preferences before production volume begins.
5. Before You Scale: Run a Contained End-to-End Pilot
Before expanding UAD 3.6 beyond a targeted set of programs, process a small, controlled volume of 3.6 orders through every stage: LOS intake, routing, appraiser upload, UCDP submission, SSR handling, and delivery.
Use the pilot to surface gaps in attribute mappings, intake forms, and delivery configurations while the stakes are low. The organizations that participated in limited production in 2025 are months ahead on this and if you couldn’t at the time, this pilot is your equivalent and it needs to happen now.
Closing
The mandate is fixed. What isn’t fixed is whether your organization absorbs UAD 3.6 as a controlled operational transition or as a scramble compressed into the final quarter of 2026.
The lenders who will absorb it cleanly are the ones who recognized early that the real work was in order management – the attribute model, the version field, the routing layer, the QC configuration – and built that infrastructure before 3.6 volume scaled. While that work doesn’t show up in a software demo, it shows up when a dual-version pipeline runs without exceptions, because every system in the chain is reading the same structured data from the same source of truth.
That’s what production-ready actually means. And the window to build it without pressure is right now.
ValueLink has processed UAD 3.6 appraisal orders in live production, running end-to-end from LOS intake through compliant UCDP delivery. Curious about how we did it? Read more about it
