Valuation Firm Guide

Long Form XML - First Mortgage Attribute

First Mortgage Attribute

The First Mortgage attributes flags that the report is going to be used for first mortgage purposes only. If this field is not supplied, ValEx will default to “Yes” (First Mortgage Purpose only).

/Title/Encumbrance/@FirstMortgage

Long Form XML

Insert Title Here

Action Updates

An Action Update will act like a Delay, in the sense that it will not remove other status, like, appointment & inspected, however, when applied it will be the primary status of the job.

Marking the Job as Inspected will remove any previous Action Update (like a delay). However, an Action Update can be applied after an Inspection has been confirmed (like a delay).

When a Delay is applied to a Job already, the Action Update will not override the Delay. The Action Update will be applied as a sub status to the Delay on the Job, the Delay will remain the Primary Status. If an Action Update is on a Job and then a Delay is applied, the Delay will become the primary status of a Job, and the Action Update will not be removed, but will become a secondary status on the job.

New LIXI SOAP Operations

addActionUpdate(valexId, update_code, comment)

This is the standard operation that should be called for adding an Action Update to a job.
The update_code should correspond to one of the following action update categories in the mappings below:

ValEx LIXI
Lack of Sales Evidence lack_of_sales
I have/will Miss a Deadline miss_deadline
Insufficient Documentation (ValFirm to Resolve) insufficient_documents
Quality Assurance quality_assurance
Clarity Required on Policy clarity_required_on_policy

actionUpdateFeeApproval(valexId, reason_code, fee_amount, comment)

This is the operation to call for adding an action update where the reason is to seek approval for a higher fee on a valuation request.
The reason_code should correspond to one of the following action update categories in the mappings below:

ValEx LIXI
Nature of the Property nature_of_the_property
Size of the Property size_of_the_property
Location of the Property location_of_the_property
Report Type report_type

actionUpdateReassignment(valexId, comment, fee_amount)

This is the operation to call for adding an action update where the reason is to seek approval for a re-assignment of a previously completed valuation.

actionUpdateServiceTypeWithFeeApproval(valexId, comment, fee_amount)

This is the operation to call for adding an action update where the reason is to seek a service type change with a higher fee approval on a job.

Recommendation

Recommendation is a field within ValEx which will allow the valuer to indicate whether the property is appropriate to be considered as security for lending purposes.

Recommendation is generally an optional field for Valuers. Some clients may select (due to their Mortgage Insurer’s requirements) that this is a mandatory question to answer (please refer to the 'RequiresRecommendation' section below for more detail on this).

XPaths

Recommendation actually encompasses the following three fields in Lixi (these will be described in the following sections):

  • //ValueComponent/@RequiresRecommendation
  • //ValueComponent/@RecommendedSecurity
  • //ValueComponent/@RecommendationReason

RequiresRecommendation

From a ValEx perspective there are settings which stipulates whether Recommendation is a mandatory field for valuers to answer for each Client or Funder. This will be sent from ValEx to the LIXI Firms via setting the RequiresRecommendation as “Yes” in the request when required:

<ValueComponent ... RequiresRecommendation=”Yes”> 

In turn, it will then be up to the valfirms to implement on their system to determine whether the Recommendation is required to be provided, based on what they receive from RequiresRecommendation.

RecommendedSecurity

This is the actual field for indicating whether the Security is an acceptable security to be considered for Lending Purposes.

There are currently 3 outputs for this field in Lixi:

When the Valuer is indicating that the Security is an acceptable security to be considered for Lending Purposes:

<ValueComponent ... RecommendedSecurity=”Yes”> 

When the Valuer is indicating that the Security is not an acceptable security to be considered for Lending Purposes:

<ValueComponent ... RecommendedSecurity=”No”> 

When the Valuer is not indicating either way (due to the setting being optional in ValEx per client/funder):

<ValueComponent ... >

RecommendedReason

When the Valuer indicates that the Security is not an acceptable security to be considered for Lending Purposes (i.e. RecommendedSecurity="No"), we will require comments to support this, at least 5 words will be required:

<ValueComponent ... RecommendedSecurity="No" RecommendationReason="This is not an acceptable security to be considered">

Environmental & Heritage Issues

As per the new API Rewrite implementation post July 1st 2012, there have been changes in relation to the parsing of the values in Lixi for the Environmental and Heritage Issues under the RiskAnalysis node:

  • //RiskAnalysis[@EnvironmentIssues]
  • //RiskAnalysis[@HeritageIssues]

The following is how the fields are parsed by ValEx from Lixi into the report:

//RiskAnalysis[@EnvironmentIssues=""]
//RiskAnalysis[@HeritageIssues=""]

will simply populate as a blank option in the report.

//RiskAnalysis[@EnvironmentIssues="None"]
//RiskAnalysis[@HeritageIssues="None"]

will indicate as the 'None' option in the report.

On the other hand, if these fields are neither set to blank or None:

//RiskAnalysis[@EnvironmentIssues="There are Environmental Issues"]
//RiskAnalysis[@HeritageIssues="There are Heritage Issues"]

these will basically populates as actual comments in those fields.

Inbound Reject Quote

rejectQuote() is a SOAP operation that may be optionally implemented as part of our LIXI Quote Process.

If the valuation firm decides to reject the quote request, the following SOAP operation should be called:

int rejectQuote(string valuationMessage)

We expect a standard LIXI message containing the following:

  • ValEx VXJ Identifier (VPMAssigned)
  • ValuationTransaction/Message/MessageBody/Status/@Name = Inquiring
  • //Workflow[@Type="FeeNegotiation"]/@FeeNegotiationStatus = Rejected

Inbound Provide Quote

provideQuote() is a SOAP operation that may be optionally implemented as part of our LIXI Quote Process.

If the valuation firm decides to provide a quote, the following SOAP operation should be called:

int provideQuote(string valuationMessage)

We parse required data from the following locations in the LIXI workflow message (valuationMessage).

  • Quote comments: //WorkFlow[@Type="FeeNegotiation" and @FeeNegotiationStatus="Requested"]/Comment
  • Fee amount: //WorkFlow[@Type="FeeNegotiation" and @FeeNegotiationStatus="Requested"]/@NewFeeAmount

    This amount should exclude GST.

  • We will parse the estimated turnaround time (in days) as:

    //WorkFlow[@Type="FeeNegotiation" and @FeeNegotiationStatus="Requested"]/ExpectedValuationDate/Date subtracted by /ValuationTransaction/Date

    (This is basically, "now" minus expected date.)

We also expect:

  • ValEx VXJ Identifier (VPMAssigned)
  • ValuationTransaction/Message/MessageBody/Status/@Name = Inquiring
  • //Workflow[@Type="FeeNegotiation"]/@FeeNegotiationStatus = Rejected

Outbound Quote Request

quoteRequest() is a SOAP operation that may be optionally implemented as part of our LIXI Quote Process.

A quote will be sent to the valuation firms’s SOAP service. The following operation signature should be implemented:

int quoteRequest(string valuationMessage, amount)

Where:

  • valuationMessage is a full LIXI request message.
  • amount is for the valuation fee amount (if it is already a set fee ValEx). Note that if the amount passed through is zero, then it indicates that the valfirm that the fee will need to be quoted on.

The /ValuationTransaction/Message/MessageBody/Status/@Name will be set to Inquiring status to indicate that it is a quote.

TitleSearched vs TitleSighted

The ValEx system was designed some time ago based on a version of Property Pro available at the time as a representation of the valuation standards.
Since then; the API Valuation Standards guidelines have been updated in a few simple areas.

One of these is the question “Has the title search been sighted?” replacing “Title searched?”

ValEx will be updating its user interface & output reports; as well as it’s LIXI parsing...

Instead of looking at:

//SiteDetailResponse[@TitleSearched] (Yes/No)

ValEx will look at:
//SiteDetailResponse[@TitleSighted] (Yes/No)

We are asking all LIXI valuation firms to investigate their current user interfaces and LIXI rendering behavior; to confirm that

  • The question is worded as per the API Valuation Standards
  • Both fields are populated with a yes/no dependent on the valuer input
  • This will allow ValEx to swap the basis LIXI parsing in regards to this area with no disruption to your end users.

    ValEx will be making the change during August 2011

Title Details

Title Details appears under the Property Summary on the Summary Tab.

Below are some LIXI mappings for Title details:

Field LIXI Mapping
Title Type RealEstate/Location/Title/@TenureType
Further Detail RealEstate/Location/Title/@OtherTitleDescription
Lot/Unit No RealEstate/Location/Title/@TorrensLot
Plan No RealEstate/Location/Title/@TorrensPlan
Volume RealEstate/Location/Title/@TorrensVolume
Folio No RealEstate/Location/Title/@TorrensFolio

Contact us for more information.

Syndicate content