Valuation Firm Guide

WorkFlow supported in ValEx

We currently require Valuation Firms to be able to send us core workflow (status update) types done through hitting statusUpdate() method on ValEx's endpoint:

  1. Accepted (optional)
  2. Assigned
  3. Delayed
  4. Inspected
  5. Declined
  6. In Progress (optional at this time)
  7. There are more under discussion

Here are some of the required features of each packet type below:

General

In the related party section. You must define your Valfirm with it's Valex id in a VPMAssigned identifier in the format of VXV-00XXXX. If you don't know your Valex valfirm id email us.

Assigned

Any valuer you assign a job to must be in the ValEx system. There way the ValEx requires valfirms to identify valuers in the valuer related party segment.

Valex does this by using their Valex valuer id as a VPMAssigned identifier. This requires you to store your all the Valex id's of your Valuers.

You can find the valuer IDs from the Valfirm Realm, Management, Valuers menu; then Export CSV.

We accept these in the format of VXVLR-00XXXX. Read more about Identifiers.

You should pay attention to Valex's response to assigned. If it's not 0, it's possible the job has been reassigned to another valuation firm. In most cases this shouldn't be an issue, but just make sure your system checks the result.

Assigned is also how you set the appointment time. You can resend an assigned with an appointment time once that's set.

Please be aware that some business rules apply.

Delayed

A delayed workflow must include a non empty comment node. Hence you'll have to take and store a comment in your system.

The Delayed date must be in future. If you send us a date without a time, Valex assumes the date starts at midnight (2007-01-01 0:00:00) - this will cause errors at our end.

See more about Delay Reasons and How do Delays work in Valex?

Inspected

Please set both the workflow date and the actual inspected date to the date of the inspection.

Accepted

We also support accepted workflow; and recommend its implementation - however it will not block your system from working.

This status will cause ValEx to assign your default valuer.

Declined

We now support declined workflow. A comment about the reason declined must be in the packet. ValEx enforces a 10 character minimum rule for comments about why you are declining a job. For valuation firms, we strongly suggest you enforce similar provisions in your user interfaces.

InProgress

We now support inprogress workflow. We can optionally take an appointment time, and this workflow will remove all Delays on a job.

This will also add a note to the job.

Resources

There are sample packets at the bottom of this article.

We will try to continue to update this article with issues Valfirms come up with. If you have issues with workflows, please recheck this article.

Sample Packet XPath

Assigned

VPMAssigned identifier
/ValuationTransaction/RelatedPartySegment/RelatedParty/Identifier
Valuer name
/ValuationTransaction/RelatedPartySegment/RelatedParty/PersonName
Valuer work phone
/ValuationTransaction/RelatedPartySegment/RelatedParty/WorkPhone

Delayed

Delay Status
/ValuationTransaction/Message/MessageBody/Status
Comment
/ValuationTransaction/Message/ValuationType/WorkFlow/Comment

Inspected

Actual Inspection Date
/ValuationTransaction/Message/ValuationType/WorkFlow/ActualInspectionDate
Workflow Date
/ValuationTransaction/Message/MessageBody/Status/Date

Declined

Comment
/ValuationTransaction/Message/ValuationType/WorkFlow/Comment

InProgress

Date Of Inspection
/ValuationTransaction/Message/ValuationType/WorkFlow/DateOfInspection
Comment
/ValuationTransaction/Message/ValuationType/WorkFlow/Comment

Accepted

Accepted Status
/ValuationTransaction/Message/MessageBody/Status

What about cancellations?

At the moment, ValEx only supports outbound cancellation requests.

Recommended network setup

We recommend two separate setups for valuation firms and clients beginning work with webservices.

The first is to set up a private, secure VPN with us - we use a product called Hamachi to quickly and easily set that up.

The second is a formal production and test environment, exposed to the public internet.

Under the first scenario, the private VPN and internal development machines will typically have IP addresses like:

  • 192.168.1.2
  • 5.148.41.7

We'll typically never need to know these addresses - we'll easily be able to see them via the VPN client, once it is set up.

The private VPN allows you to get access to our bleeding edge code, and changes can happen very rapidly; which is very useful for development. Get in contact with us for more information.

The second scenario is where we need to know the public web address (test.yoursite.com, production.yoursite.com); or the IP address.
This will typically be something like 203.221.5.1.

This is the environment we'll use for formal testing, and the rate of change is a lot slower.

Sequential Identifiers

Quite often, jobs are related to each other. For a couple of different job types, it's important to be able to list previous related jobs.

Two examples of this include progress inspections, where all of the jobs are related to one property; and certain types of business rules managed valuations - where a job can be 'escalated' from a reduced valuation to a more detailed one. The way we model this is sequential identifiers.

In the near future, we'll use //@Identifier[Type="Sequential"] to list every job related to this one, in order, up to to current one.

For example, say the current job is 50000, and it's the second stage of a progress inspection, the first being 49613. We'd send through the following on the packet:

<Identifier Description="VPMAssigned"Type="Sequential"UniqueID="VXJ-000000049613" />
<Identifier Description="VPMAssigned"Type="Sequential"UniqueID="VXJ-000000050000" />

This is not a requirement for either clients or valuation firms to implement; however its highly recommended.

Sample packets and much more are available on request.

Loan Information

In schema 1.3.4 we're adding a new node, called Loan. We will be using this to send Loan information for AVM and Desktop Valuations. It is also where we'd expect to capture this information from clients.

Loan will go just under Full Registered /ValuationTransaction/Message/ValuationType/FullRegistered/Loan

Note this information will not be rendered out on Full Valuations.

Also we've added three new service types (ValSubType):
1) "AVM" - An Automatic Valuation
2) "Desktop Valuation" - A desktop valuation

The new schema is attached to this document; and will be published to our production environment shortly.

We would expect these changes not to affect the majority of valfirms or clients, as we'll never render them to clients, nor to valfirms unless doing a Desktop or AVM valuation. Hence we won't break any schema validation.

XSD Published - 1.3.3 Changes

We've made a number of changes to our xsd so that we can accept new data for populating the report. This should fix up a number of fields that valuation firms we're not previously able to populate via LIXI. Check out the attached schema below.

Property Identification

XPATH:
/ValuationTransaction/Message/ValuationType/FullRegistered/SalesEvidence/Location/@PropertyIdentification

Details:
This sotres how the valuer identified the property. If it is blank it will default too "The property has been identified with reference to street address only"

We've altered our XSD to add in a number of fields that are needed on the valuation report but are not currently catered for by the LIXI standard. Detailed below are the changes

Interest In Property

XPATH:
/ValuationTransaction/Message/ValuationType/FullRegistered/@InterestInProperty

Details:
We've now reverted back to the lixi standard of having an enumerated list except with the addition of "CrownLeashold and Subject to long term lease"
Currently we convert just the following types

  • FeeSimpleInPossession
  • CrownLeasehold
  • SubjectToLongTermLease
  • SharesInCompany

Attachment

XPath:
/ValuationTransaction/Message/ValuationType/FullRegistered/SiteDetailResponse/PropertyCharacteristics/@Attachment

Description
We need to be able to describe whether the house is semi-attached, detached or attached.

Style Description

XPath:
/ValuationTransaction/Message/ValuationType/FullRegistered/SiteDetailResponse/PropertyCharacteristics/@StyleDescription

Details:
Stores information to be appended to the property description. Examples could be "Low Set", "High Set", "High Set, Two story", "22nd Floor Appartment", "Three Story".

The other following minor changes we're changed:
InterestInProperty is changed to match LIXI Standard, but this should not affect the parsing or validation of any packets.

Interest in property (Interest Valued)

In the 1.3.2 schema we have InterestInProperty defined as a string. As of 1.3.3 we'll be reverting this closer to lixi standard:

<xs:attribute name="InterestInProperty">
    <xs:simpleType>
        <xs:restriction base="xs:NMTOKEN">
            <xs:enumeration value="FeeSimpleInPossession" />
            <xs:enumeration value="Lessors" />
            <xs:enumeration value="Lessees" />
            <xs:enumeration value="SharesInCompany" />
            <xs:enumeration value="Timeshare" />
            <xs:enumeration value="UnitsInTrust" />
            <xs:enumeration value="CrownLeasehold" />
            <xs:enumeration value="SubjectToLongTermLease" />
            <xs:enumeration value="Other" />
        xs:restriction>
    xs:simpleType>
xs:attribute>

The default for most properties is FeeSimpleInPossession. Since we can't map 'Other' to anything, we assume FeeSimpleVacantPossession.

This maps to the Interest Valued field on the Summary tab.

We support the following values:

  • FeeSimpleInPossession
  • SharesInCompany
  • CrownLeasehold
  • SubjectToLongTermLease
  • ACTLeasehold
  • LeaseholdInterest

Attachments (Reports, Images, Title Details etc)

Documents make up one of the important components of the lixi data transfer both for clients and valfirms. Clients need to be able to send title details, additional documentation and valfirms need to be able to send multiple photographs of the property & their own valuation report.

Sending an attachment via lixi consists of two parts:
a) ResponseSupportingDoc (or RequestSupportingDoc) which contains metadata about the attachment and
b) AttachmentSegment which contains the actual encoded attachment or links to it.

Meta data

First of we create the ResponseSupportingDoc node under FullRegistered as follows:

<ResponseSupportingDoc DocAttached="Yes"
DocType="Image"
RequestorToSight="No">
<Identifier Type="ValfirmAssigned"
UniqueID="IMAGE_12234" />
<Description>This is a picture of the ceiling</Description>
</ResponseSupportingDoc>

(or RequestSupportingDoc)

There are several important components of ResponseSupportingDoc, they are:

  • DocAttached="Yes" - This specifies whether an attachment exists in the packet for this supporting documentation. It must be set to yes otherwise ValEx will not pick up the attachment
  • DocType="" Valex Specifically recognises the following types
    • Image - For images of the property etc
    • TitleSearch - For a file containing the title search
    • Report - For the completed valuation report
    • BuildingContract
    • BuildingSpecification - building plan
    • PlanOfSubdivision
    • TitleSearch
    • Other
  • In addition to the above doc types we may render in our outbound packets any of the following
    • Plans - For building plans
    • Contract - For contracts
    • PlanOfSubdivision - For sub division plans
    • Other - For just about everything else
  • The Identifier links the ResponseSupportingDoc with the Attachment in the packet. This must match up with the RelatedEntityRef in the attachment. They must be also unique.
    i.e.
    <RelatedEntityRef RelatedID="IMAGE_12234" />
  • Description - This will display on the description in the documents section in ValEx

The attachment

There are two methods for attaching documents in LIXI. The first is 'inline', the other is to provide a link. We strongly recommend the latter approach.

Inline

In the attachment segment we need:

  • Filename - A descriptive filename for the file with the extension (.jpg,.pdf etc)
  • RelatedID in RelatedEntiryRef to be the same as the matching ResponseSupportingDoc
  • The base64 encoded string containing the filename. Details can be found on wikipedia.
<AttachmentSegment>
<Attachment Filename="ceiling.jpg">
<Identifier Type="ValfirmAssigned"
UniqueID="Dummy_Value" />
<RelatedEntityRef RelatedID="IMAGE_12234" />
<InlineAttachment>JVBERi0xLjQNCg0KMTEgMCInlineAttachment>
<Attachment>
<AttachmentSegment>

For inline attachments, there is a MAXIMUM packet size of 10mb.

Links

We recommend a different approach to large attachments.

Delay Reasons: How our internal types map to LIXI types

We send Delay Workflow packets to clients. We require that Valuation Firms send back a Delay Reason and Delay Comment to enable reporting to our clients.

Important Warning: ValEx will not accept Delay Reasons for issues where an internal Valuation Firm issue prevents timely completion of a report. Such issues should be managed via an IT solution or via process within each individual Valuation Firm. Be aware that ValEx audit delay use regularly.

User Interface

Below is a quick summary of our UI, and how that relates to the LIXI standard. Please ensure that your interpretations of the LIXI Delay Reasons map correctly to our interpretations.

Current Delay Reasons in ValEx

LIXI Mappings: Parsing from Valuation Firms

IncorrectContactDetails
Contact numbers supplied are incorrect or not answering. Please provide ValEx with new contact numbers.
Other
Other - No longer supported
AtCustomersRequest
We have contacted the Customer and they are unable to make an appointment time, they have advised for us to contact them again on
TenantDeniedAccess
The Tenant/Letting Agent/Selling Agent has not been able to secure access. We have been advised to contact them again on
IsolatedLocation
Next visit to this location is
IncorrectAccessDetails
Address of property to be valued appears to be incomplete or incorrect. Please confirm from source documents and phone ValEx with correct details.
WaitingForCall
WaitingForAgent
Contact numbers supplied are incorrect or not answering. Please provide ValEx with new contact numbers.
AwaitingAuthorisation
AwaitingBuildingInformation
AwaitingFeeChange
Insufficient documentation provided by the Bank. Please provide the following documentation.
ValExContactingDifficulties (new)
Client/Tenant has requested that Inspection be conducted on
ValExOutsideAgreements (new)
Request outside ValEx agreeements.

LIXI Mappings: Rendering to Clients

Client/Tenant/Agent has requested that Inspection be conducted on
We have contacted the Customer and they are unable to make an appointment time, they have advised for us to contact them again on
AtCustomersRequest
Contact numbers supplied are incorrect or not answering. Please provide ValEx with new contact numbers.
Customer/tenant/agent will not return calls. Please resolve with customer and contact ValEx to advise.
IncorrectContactDetails
The Tenant/Letting Agent/Selling Agent has not been able to secure access. We have been advised to contact them again on
Client/Tenant/Agent has denied access to property. Please resolve with Customer and Phone ValEx to confirm.
TenantDeniedAccess
Next visit to this location is
IsolatedLocation
Address of property to be valued appears to be incomplete or incorrect. Please confirm from source documents and phone ValEx with correct details.
IncorrectAccessDetails
Insufficient construction documentation provided. Please provide the following documentation.
AwaitingBuildingInformation
Insufficient documentation provided by the Bank. Please provide the following documentation.
AwaitingBuildingInformation
Request is outside Valex agreements.
Other
Other - No longer supported

Securitisation, and specific comments

Our system now captures specific comments around Securitisation issues.

Previously, we required one Securitisation comment and had Yes/No enumerations for the assorted securitisation attributes.

We've now swapped to allowing an xs:string for those attributes, and will use that as the specific securitisation comment. We assume that empty or omitted means 'No securitisation issue, or comment'.

We've also removed the general securitisation comment.

This change will occur July 1.

In the future we will be drafting something very similar to RiskRatings/RiskAnalysis, with individual items and explicit comment fields; and will submit this back to standard body.

RiskAnalysis and RiskRatings, and Compliance Rules

Our system now captures individual comments for specific risk ratings.

For clients - we previously did not render anything particularly useful in the comment fields when returning a response, however we will now include the full comments as entered by the valuer.

For valuation firms - now that we capture specific risk comments, we have some additional rules about when a comment is required.

In general:

  • If any risk rating is 3-Medium or higher, a specific comment is required (RiskRating/Comment)
  • If three or more risk ratings are 3-Medium or higher, the overall risk analysis comment is required (RiskAnalysis/@OverallRiskAnalysis).
  • If one or more risk ratings are 4-MediumToHigh or higher, the overall generic risk comment is required (RiskAnalysis/@OverallRiskAnalysis).

When it doubt, it's best to provide more risk comments than less.

Syndicate content