Data Exchange Engine for MISMO
Bidirectional conversion between your data model and MISMO Reference Model 3.6.x and MCD v2.0. Each mapping is round-trip tested, and every conversion produces an evidence record.
The problem
You have a proprietary internal data model that is not going away, and an obligation to exchange MISMO with GSEs, investors, partners and examiners — across several specs at once, each on its own version cadence.
Rewritten whenever a spec revises, by whoever is available at the time. The knowledge of why a field was mapped the way it was lives in the person who wrote it, not in the system.
When an investor rejects a file or an examiner asks how a value was derived, the honest answer is usually a developer reading code. That is not evidence, and it does not scale.
Rules-based translation covers the legacy UMDP datasets well. The live work is Reference Model 3.6.x and the MCD — and the proprietary model on the other side of them.
The mortgage data standards
MISMO publishes the reference model; Fannie Mae and Freddie Mac, under the Uniform Mortgage Data Program, define the datasets a loan must satisfy at each stage of its life. Each dataset is pinned to its own MISMO version, carries its own edits and changes on its own schedule — so a single "MISMO mapping" is rarely sufficient in production. The sections below follow a loan from application to servicing.
The same loan is described in MISMO v3.4 at application, v3.6 at appraisal, v3.3 at closing and v3.0 at delivery. Field names, containers and enumerations differ between them.
Most datasets are MISMO XML, but credit still largely runs on MISMO 2.3.1, and servicing modernization is adding JSON and CSV pathways. The engine treats format as a property of the destination.
A schema-valid file can still be rejected. Each destination applies its own business edits and findings, so validation has to mirror those rules — not just the schema.
01 · Application and underwriting
The application is where data quality is cheapest to fix and most expensive to ignore. Borrower, employment and income, assets and liabilities, real estate owned and declarations are captured in your point-of-sale or LOS — and everything downstream inherits whatever that capture got wrong.
That data then goes to automated underwriting. Findings and conditions should come back into your system as data your team can act on, and the credit report that supports the decision arrives from bureaus and resellers in formats of its own.
What we do
02 · Appraisal and collateral
The GSEs are replacing the legacy, form-based appraisal data with a single, dynamic Uniform Residential Appraisal Report. For every system that orders, produces, receives or reviews appraisals, that is a structural change — new fields, new relationships and a new version of MISMO.
Appraisals are submitted through the Uniform Collateral Data Portal, and the GSEs return findings and collateral-risk feedback that underwriting and quality control need to see in context.
What we do
03 · Closing
At closing, the terms the borrower signs have to match the data the investor will receive. The Closing Disclosure is delivered to the GSEs as data, and where the closing is electronic, the note itself becomes a data object that has to be registered and transferred.
Inconsistencies between the Closing Disclosure, the note and later delivery data are a common source of findings — and they are cheapest to catch here.
What we do
04 · Loan delivery
When a loan is sold to Fannie Mae or Freddie Mac, the delivery file is checked against the GSEs' delivery edits. Errors at this point mean rejected deliveries, purchase delays, pricing adjustments and repurchase exposure — after the loan has already closed.
Delivery data is assembled from your system of record, so its accuracy depends on everything captured upstream, and it has to agree with the Closing Disclosure and the note.
What we do
05 · Government programs
Government-insured and guaranteed loans follow program-specific requirements for insuring, guaranty and pooling. They are not interchangeable with GSE delivery, and treating them as if they were is a common source of rework.
What we do
06 · Servicing and investor reporting
Servicing data changes every month for decades: payments, escrow, curtailments and payoffs, delinquency, forbearance, modifications and workouts. Each investor has its own reporting requirements, and the cutoffs do not move.
GSE servicing modernization is adding new reported facts and new JSON and CSV pathways, phased over time — and the source data to support them often has to be captured for the first time.
What we do
The test that defines correctness
Proprietary → MISMO → proprietary returns the original, or it declares precisely what it lost and why. A mapping that cannot round-trip does not get approved, and the test runs in CI from the first commit rather than in a review at the end.
How a mapping gets made
AI proposes. A person approves. A deterministic engine executes. The record writes itself. The proposer never touches a conversion.
Propose
AI reads your schema, sample payloads and the spec, and emits candidate mappings with rationale.
Review
A named reviewer approves or rejects each mapping. Nothing activates without a signature.
Execute
Approved mappings run as a deterministic, versioned transform. No model in the path.
Evidence
Every conversion writes its own record — versions, hashes, rule outcomes, reviewer, timestamp.
What defines the engine
Reference Model 3.6.x and MCD v2.0 for current work, alongside the UMDP datasets on the versions the GSEs pin them to — ULDD on v3.0, UCD on v3.3, ULAD on v3.4 and UAD on v3.6 — plus MISMO 2.3.1 where credit vendors still use it.
Candidate mappings are generated with their rationale and reviewed by a person. Once approved, they run identically every time, with no model anywhere in the path.
Spec version, mapping version, input and output hashes, rule outcomes, the approving reviewer and the timestamp — written as the conversion happens, not reconstructed when someone asks.
Diff the schema, flag the affected mappings, propose the deltas, and re-review only what actually changed, so the work stays proportional to what moved.
How to engage
01
Find data and rule gaps against the destination's specification and edits. You receive test results, an exception report and a remediation plan.
02
Map source data, apply deterministic checks and produce the destination payload — with authorized submission and response tracking where contracted.
03
Keep covered mappings, rules, tests and reporting current as specifications change, with monitoring, exception evidence and change support for the contracted workflows.
Where it runs
Conversion happens inside your environment, on your infrastructure. Production data and credentials stay where they are — we never hold them, and your security team can verify that rather than take it on trust.
Questions buyers ask
Bidirectional conversion between your proprietary data model and MISMO. Each mapping is round-trip tested, and every conversion produces an evidence record — spec version, mapping version, input and output hashes, rule outcomes, reviewer and timestamp.
ULAD for the loan application, AUS submissions to DU and LPA, credit data, UAD 3.6 appraisal data, UCD closing data, eNotes, ULDD loan delivery, and servicing and investor reporting. Each destination is scoped separately.
Each Uniform Mortgage Data Program dataset is pinned to its own MISMO version — ULDD on v3.0, UCD on v3.3, ULAD on v3.4 and UAD on v3.6 — so the same loan is described differently at each stage. The current specification for each destination is confirmed during scoping.
No. AI proposes candidate mappings with their rationale, a named reviewer approves or rejects each one, and approved mappings run as a deterministic, versioned transform with no model in the path.
Inside your environment, on your infrastructure. Production data and credentials stay where they are.
The fastest way to judge this is against your own data. One spec, one real payload shape, and we will show you the mapping, the round-trip result and the evidence record it produces.
Review your data workflowMortgage depth behind it — see the mortgage practice →
