UAD 3.6 rejection errors, translated.

Two different reasons a file bounces

Every UAD 3.6 ZIP submitted to UCDP is checked in layers, and the layer that rejects it changes what kind of error you get back:

• Schema-level ("System") checks — is the ZIP well-formed, and does every value in the XML match its declared data type against the published MISMO 3.6 subschema? Failures here surface as SYS-prefixed codes, like SYS9001. The validator doesn't know or care what an appraisal is at this layer — it's checking shapes and types.
• Business-rule ("UAD Compliance") checks — given a structurally valid file, does it satisfy the appraisal-specific rules in Appendix H-1: required fields, conditional logic, enumerations, comment-length limits? Failures here surface as UAD-prefixed message IDs, each with a severity of Fatal or Warning. This is the layer the rest of this page is mostly about, and it's the layer Plumb Bob checks before you submit.
• GSE-proprietary checks — Fannie and Freddie's own internal collateral and risk logic, run after the first two layers pass. This ruleset isn't published, so there's no plain-English dictionary anyone outside the GSEs can offer for it — including us. More on this below.

What a SYS9001 appraisal error actually means

SYS9001 is a schema-validation failure — the ZIP's XML doesn't conform to the published GSE_UAD_3.6.0 subschema. The single most common trigger is a broken file reference: an image or PDF pointer inside the XML that doesn't satisfy the schema's data type for that field.

MISMO defines that field's data type as MISMOObjectURL — the schema's own documentation describes it as a value that must be a well-formed URL, "conform[ing] to both the generic syntax of RFC 2396 ... and the specific syntax of the scheme." In practice: the exhibit filename or path your software wrote into the XML has to be a clean, valid reference — no stray characters, no missing extension, no path that doesn't actually match a file sitting in the ZIP's \Images folder.

The business-rule layer has the same concern spelled out in plain language, which is useful for cross-checking exactly which exhibit reference to look at:

• UAD1705 — "Provide the file name and location of the image within the .zip file (e.g., \Images\MH1_DwellingFront.png)."
• UAD1707 — "Provide the format of the image file."
• UAD1276 — "Provide the file name and location of the image within the .zip file (e.g., \Images\SF1_Comp2.png)."

If UCDP hands you a schema error naming an ObjectURL or an image field, the fix is almost always in the exhibit filenames your forms software wrote — not in the appraisal content itself.

Fatal vs. Warning — what the severity actually decides

Every rule in Appendix H-1 carries a severity. Fatal means UCDP rejects the submission outright — not a note you can explain away in a comment field, a hard stop. Warning means the finding is flagged for review but doesn't block delivery on its own. The full list of Fatal-severity rules, by report section, is on the hard-stops page. The three rule families below are the Fatal ones that account for a disproportionate share of first-time bounces.

The photo-exhibit Fatal class

Missing or mismatched exhibits are one of the most common Fatal categories, and the rule text says exactly what's required:

• UAD1274 — "The required subject property photos must be included." The underlying rule logic checks for three specific image categories on the subject: the dwelling front, a property-access photo, and a general property photo. Missing any one of the three trips this rule.
• UAD1275 — "Provide a photo of each sales comparable used in the valuation." Every comp needs its own photo — no exceptions, no "MLS didn't have one."
• UAD1283 — "Provide the sales comparable map." Required whenever the Sales Comparison Approach is used in the appraisal — which is effectively always.

Required-container ("select None") rules

A large family of Fatal rules doesn't ask for a value so much as it demands the container itself exist — even when the honest answer is "there isn't one." Leaving the field blank because nothing applies is exactly what trips these:

• UAD1296 — "Provide the type of apparent environmental condition. Select 'None' if there are no apparent environmental conditions."
• UAD1313 — "The type of hazard zone must be included. Select 'None' if the property is not in a hazard zone."
• UAD1667 — "The type of vehicle storage must be included. Select 'None' if there is no vehicle storage."
• UAD1683 — "The type of disaster mitigation feature must be included. Select 'None' if there are no disaster mitigation features."

Old form-filling habits carry this bug forward: on the legacy 2.6 form, skipping an inapplicable field was normal. On 3.6, several of those same fields became required enumerations with an explicit None option — skip it, and it's Fatal, not blank.

Commentary length limits

Several narrative fields carry a hard character cap, and it's not the same number everywhere — pasting a paragraph that was fine in one comment box can be Fatal in another:

• UAD1765 — 140-character limit (hazard zone / non-residential use commentary).
• UAD1766 — 210-character limit (a cluster of project-related commentary fields).
• UAD1767 — 540-character limit (special tax assessment commentary).
• UAD1768 — 2,500-character limit (site influences, water frontage, and several project-factor commentary fields).

The rule text for all four is the same shape: "The commentary provided for the specified field exceeds the allowable limit of N characters." There's no partial credit or truncation — over the limit is Fatal.

What about FNM-prefixed codes, like FNM1087?

Codes prefixed FNM instead of UAD belong to the third layer above — Fannie Mae's own proprietary collateral and Collateral Underwriter (CU) findings, run after your file already cleared schema and Appendix H-1 checks. That ruleset isn't published, so we can't hand you an official plain-English definition for a specific code like FNM1087 — nobody outside Fannie can, honestly, and be careful of anyone who claims otherwise.

What is reliably true in practice: FNM-prefixed messages tend to cascade from an upstream problem rather than originate on their own — a broken exhibit reference or a CU-not-performed condition, for instance, because the collateral engine never received valid data to evaluate in the first place. Field reports of exactly this pattern exist — a schema-level exhibit error (like the SYS9001 case above) cascading into a downstream Fannie-specific "CU not performed" message. The practical move is the same either way: fix the System and UAD Compliance findings first. A downstream proprietary code will often clear on its own once the file it's evaluating is actually valid.