Some More Questions

Systems Analyst team Questions:

1. Party-related fields. Party is a Deal-level field, most of the party-type data we want to capture is at loan level (ie Loan Originator Name). We have Loan Originator Name mapped to Party/Individual/Name where PartyRoleType="Loan Originator". How will this look in XML? Probably covered by an Xlink/relationship, but I'd like to see how that's done.

2. We have a need to capture Pool and Loan level versions of the same field (Rounding Code, Fixed Servicing Fee, SFC?) - is this possible via XML or do we need 2 separate fields (ie Extension)?

3. We need Current & Original versions of some fields (Term, UPB, Note Rate, Index Value, etc). The XPaths for these elements do not allow repetition until the Loan level. Does that mean we'll need to repeat LOAN for the 2nd iteration of these? This same discussion applies for the handful of 1st Lien fields we capture (Term, Amort, UPB, etc). Note that for UPB we can potentially have 4 iterations of a single loan (Delivery Lien Current, Delivery Lien Original, 1st Lien Current, 1st Lien Original).

The LOANS/LOAN is designed for that purpose. Previous attempts to intermix time dependent data in one place for "some fields" resulted in never having the right "some" to satisfie all use cases. By having a full LOAN object that can be identified as "Current" or "Original" lets you decide what subset you need internally. At the same time you can accept data from other sources where they made a different subset choice. Remember the goal of MISMO is to allow communications between partners. There will always be business logic between partners about what data is required and what is conditionally required.

4. I'm unsure how to handle 1st Lien fields (Term, Amortization, UPB(Current&Orig), etc) - what indicator field should we use? If we use Lien Priority (1st/2nd), how do we differentiate between a 1st lien delivery (Lien Priority=1st, but these 1st lien fields should be blank) and the 1st lien data associated with a 2nd lien delivery(Lien Priority also=1st here, but these 1st lien fields should be filled in)? It's like we need 2 indicators, 1 to indicate the delivery type and, if delivery type = 2nd, another indicator to differentiate between the delivered loan data from 1st lien data.

If you are originating, buying, delivering a First Lien one thing that has become clear is a better understanding of the second lien is important. In V2 we had a rag tag collection of facts and indicator about the second buried inside the description of the first. This proved to be inadequate.

• We raised the element that contains all the information needed to DEAL
• We created a LOANS/LOAN structure so that all the loans that were part of the deal can be described to the same level of detail.
• We added the ability to identify the subject loan
  

5.More of a policy question for us to decide, but is it considered "standard" to add extended enumerations? This only applies to a couple of fields (ie loan index).

Actually this question goes to the core of semantics. Systems to system communications requires that both systems have a shared understanding of the meaning of the data. When a data point is enumerated the set of definitions IS its definition. Changing the enumerations changes the definition. Only MISMO the right to change the definition of a term in the MISMO name space . If you have a term in your name space that has a definition different from the one in the MISMO name space the use the EXTENSION mechanism to send your data point in your name space.